Jan Kiszka wrote:
enable_nmi_window() should cause an exit once the interrupt has been
injected (likely before the first interrupt handler instruction was
executed, but after the stack frame was created). So the nmi will not
be delayed.
Right now, you only call enable_nmi_window() if that window is currently
closed - and that's not the common case I'm worried about.
That's a thinko. I'll check if requesting it unconditionally is allowed
and make it unconditional.
But I think I see a bigger issue - if we inject an regular interrupt
while another is pending, then we will encounter this problem. Looks
like we have to enable the interrupt window after injecting an interrupt
if there are still pending interrupts.
Yeah, probably. I'm just wondering now if we can set
exit-on-interrupt-window while the vcpu state is interruptible (ie.
_before_ the injection). There is some entry check like this for NMIs,
but maybe no for interrupts. Need to check.
I think that it is allowed.
The manual says "These VM exits follow event injection if such injection
is specified for VM entry." for both interrupt windows and nmi windows
(22.6.5 and 22.6.6).
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
