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
Hi David, I just found the draft too, a few months later. I agree with (1), but I don't see any reason for the new spec to be related to nested virtualization.
For (3) if you want to support the RVIC, I believe you will not be able to use the virtualization extension of the GIC(v2,v3,v4). If you currently have only a single exit per interrupt, so yes, it will probably increase that direct cost, but with the benefit of a much simpler code base. Here I believe the idea is to make the hypervisor code easier to pass security certification, and not to be more efficient in all operations.
Cyprien