This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Reduced Virtual Interrupt Controller RVIC

Hi everyone,

I just read the draft specification of the Reduced Virtual Interrupt Controller RVIC (developer.arm.com/.../rvic). This specification sounds very interesting for our use case.

However, I have some questions of understanding: (1) Is it a pure software abstraction layer to be implemented by the hypervisor that should hide the underlying hardware component (e.g. GICv2 etc.)? (2) It seems that the implementation of this specification would provide the basis for nested virtualization - is this correct?

If this is the idea of the specification, I have some more questions about the implementation with a GICv2 hardware component. We are currently using the vCPU interface, maintenance interrupts and our own Linux IRQ chip driver. The current implementation reduces the number of guest system - hypervisor - guest system switches to one switch per interrupt at the expense of limited configurability by the guest system and the lack of nested virtualization. (3) Is it correct that the current interrupt handling would have to be changed to a version without using the virtualization extension of the GICv2 to meet the new specification? (4) And wouldn't this increase the number of guest system - hypervisor - guest system switches?

Thanks in advance for your input!

David

Parents
  • You might find some more information about why RVIC was introduced here lists.cs.columbia.edu/.../042227.html

    For a hypervisor such as KVM, the GIC is an
    invasive beast that accounts for a large part of the privileged
    software we run, as it implements the whole of the architecture with
    bells and whistles as it tries to cater for all possible guests.
    
    
    At the same time, we have an ongoing effort to make KVM/arm64 a more
    "verifiable" hypervisor, by allowing only a small amount of code to
    run at EL2. Moving most of the GIC emulation to userspace would
    involve sacrificing performance (the architecture really doesn't lend
    itself to a split model, despite the appearances), and proving that it
    is actually completely safe is almost an impossible task.
    
    
    The result of the above is a specification from ARM [1] that defines
    the RVIC and RVID components that make the interrupt controller. It is
    an *Alpha* spec, to it is very much subject to changes (the hypercall
    numbers have been redacted out to make that explicit).
    
    The result of the above result is this patch series, which provides
    Linux drivers for rVIC and rVID, as well as a KVM implementation that
    can be exposed to guests.
    
    
    As you saw that RVIC does not define any HW interrupt controller registers, but interfaces with HVC or SMC calls, and it is not for nested virtualization 
Reply
  • You might find some more information about why RVIC was introduced here lists.cs.columbia.edu/.../042227.html

    For a hypervisor such as KVM, the GIC is an
    invasive beast that accounts for a large part of the privileged
    software we run, as it implements the whole of the architecture with
    bells and whistles as it tries to cater for all possible guests.
    
    
    At the same time, we have an ongoing effort to make KVM/arm64 a more
    "verifiable" hypervisor, by allowing only a small amount of code to
    run at EL2. Moving most of the GIC emulation to userspace would
    involve sacrificing performance (the architecture really doesn't lend
    itself to a split model, despite the appearances), and proving that it
    is actually completely safe is almost an impossible task.
    
    
    The result of the above is a specification from ARM [1] that defines
    the RVIC and RVID components that make the interrupt controller. It is
    an *Alpha* spec, to it is very much subject to changes (the hypercall
    numbers have been redacted out to make that explicit).
    
    The result of the above result is this patch series, which provides
    Linux drivers for rVIC and rVID, as well as a KVM implementation that
    can be exposed to guests.
    
    
    As you saw that RVIC does not define any HW interrupt controller registers, but interfaces with HVC or SMC calls, and it is not for nested virtualization 
Children
No data