Hi Everyone,
Its true that Hypervisor inserts interrupt in the virtual machine.
But, GICv4 also tells that it supports direct injection of virtual interrupts which means that, interrupt can be inserted directly to VM from Redistributor without involvement of Hypervisor.
Indicated by Register : ICH_VTR_EL2
Field : nV4
If this field bit is:
0 - Supports Direct Injection of Virtual Interrupts
1 - Does not Support Direct Injection of Virtual Interrupts.
So, from above statement can you please help me in understanding about,
- In what scenarios does this direct injection of Virtual Interrupts happen..?
- Is that okay, if Hypervisor is not updated about the virtual interrupt and virtual interrupt is directly inserted from Redistributor to VM.
- Can you also please tell me what is the advantage of having this feature.
Above doubts arose as per my understanding on reading GICv4 Document. If i am missing any clarity please excuse & suggest me. I am happy to take anything.
Thanks in advance,
Rakesh.
GICv4 adds support for Directly Injected Virtual LPIs (DIVL).
DIVL only works for interrupts that come via the ITS. It works by the Hypervisor describing to the ITS in advance how physical events map to virtual interrupts. If the target vCPU is running when the interrupt occurs, the virtual interrupt gets inserted without any additional Hypervisor involvement. If not, the virtual interrupt gets recorded as being pending for next time the vCPU is run.
To understand the benefit, you have to think would happen without DIVL.
DIVL removes steps 2-4, reducing the run-time overhead associated with passing the interrupt to the vCPU.
DIVL isn't free. It takes some extra logic to implement, it requires additional set up (telling the ITS about the mappings) and adds some work to context switching (telling the GIC which vCPU is now running). So as with all processor features, you have to weigh the cost against the benefits.
For the basics of the ITS works try this application note:
GICv3 Software Overview
Note: We are currently working on updating the GICv3 application note to also cover virtualization and GICv4.
Thanks a lot Martin. This info is very clear and quite helpful.
Will be waiting for the updated GICv3 Document. Please, drop small message once this document is available if possible.
Thanks,
Hi Martin,
I do have a very small doubt regarding this same topic.
As you said above--
" If the target vCPU is running when the interrupt occurs, the virtual interrupt gets inserted without any additional Hypervisor involvement. If not, the virtual interrupt gets recorded as being pending for next time the vCPU is run."
From this i can understand that during DIVL HYPERVISOR is not at all involved.
- But, my doubt is that, do we need to update any of the hypervisor registers during DIVL.
- This question arose as I have gone through the below descriptions in ARM GICv4 Doc.
============================================================
8.4.8 ICH_VMCR_EL2, Interrupt Controller Virtual Machine Control Register
The ICH_VMCR_EL2 characteristics are:
Purpose
Enables the hypervisor to save and restore the virtual machine view of the GIC state.
- It is said that, Register Fields of this register are ALIAS of the Respective Register field bits ICV_*_EL1.
- Does this mean that Hypervisor registers are always updated.?
Please correct me if I wrong.
Just for clarity, DIVL doesn't remove the hypervisor entirely. It's the hypervisor which sets up the mapping between physical events and virtual interrupts, and handles scheduling. DIVL means we don't need to re-enter the hypervisor to forward a virtual interrupt.
- But, my doubt is that, do we need to update any of the hypervisor registers during DIVL.- This question arose as I have gone through the below descriptions in ARM GICv4 Doc.============================================================8.4.8 ICH_VMCR_EL2, Interrupt Controller Virtual Machine Control RegisterThe ICH_VMCR_EL2 characteristics are:PurposeEnables the hypervisor to save and restore the virtual machine view of the GIC state.============================================================- It is said that, Register Fields of this register are ALIAS of the Respective Register field bits ICV_*_EL1.
In order to context switch between vCPUs, the hypervisor needs to be able save/restore vCPU state. This includes the state of the virtual CPU Interface (ICV registers).
The way this is done is by having aliasing between the ICV (vCPU view) and ICH (Hypervisor).
It depends on how you think about it. You could think of it as a write to ICV updating ICH, or a read/write to ICH accessing the state of ICV. But either way, at the point you enter the hypervisor the ICH registers will have an up to date view of the vCPU state.
This makes me clear.
Thanks alot martin for sparing your valuable time for me.
The updated GICv3/v3 software overview application note is now live. The update adds two extra chapters, covering virtualization and direct injections:
GICv3 and GICv4 Software Overview
Thanks for the information......
After this you'll want all your devices to support parcelling out their resources to virtual machines so the hypervisor hardly ever becomes involved except as a resource controller.