You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we always mask external interrupts in the hypervisor context. This simplifies the design, but can hurt latency characteristics for high priority interrupts. Consider the following situation with our current logic:
Interrupts are not masked in the guest
An external low-priority interrupt arrives triggering a vmexit
As the vmexit occurs, external interrupts are masked
While processing the interrupt, a higher priority interrupt arrives
Because interrupts are masked, nothing happens with this interrupt immediately
After finishing processing the interrupt, it is injected in to the guest and the guest is re-entered
At this point we should get a vmexit for the high-priority interrupt
We process and ultimately inject the high-priority interrupt
Now the guest jumps to the high-priority handler
Having interrupt handling at the hypervisor level would essentially allow us to coalesce interrupt delivery in a single vmexit, which should improve latency properties. However, this would be a significant change to the hypervisor design and should not be done without a lot of planning.
The text was updated successfully, but these errors were encountered:
Currently we always mask external interrupts in the hypervisor context. This simplifies the design, but can hurt latency characteristics for high priority interrupts. Consider the following situation with our current logic:
Having interrupt handling at the hypervisor level would essentially allow us to coalesce interrupt delivery in a single vmexit, which should improve latency properties. However, this would be a significant change to the hypervisor design and should not be done without a lot of planning.
The text was updated successfully, but these errors were encountered: