Re: VMX: NMI injection without virtual NMI support

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

Avi Kivity wrote:
> Jan Kiszka wrote:
>> Well, I thought in this direction already as well. But I wasn't sure if,
>> while the guest is in NMI context, hard IRQs will also be blocked and
>> won't cause guest exists anymore. Can you comment on this?
>>
>> However, even if that is no issue, I do not really like this workaround.
>> Specifically the need to fiddle with the guest's IDT and, of course,
>> that we may delays host NMIs.
>>
>> I'm now playing with this idea, basically a "light" version of yours:
>> After we injected an NMI, consider the guest being in NMI context until
>> the next IRQ window opens. That may cause lost NMIs if the guest blocks
>> IRQ delivery infinitely, but I would say this is rather untypical and
>> still much better than the current situation (no NMIs at all!). And it
>> is easier to implement. Comments?
>>
>>
>>   
> 
> 
> In some cases misbehaving NMIs are worse than no NMIs.  For example, a
> software watchdog may use NMIs to monitor a system.  But if the guest
> spins with interrupts disabled, the irq window will never open, and NMIs
> will never be delivered, so the watchdog will deliver a false negative.
> 

I fail to see the regression. Currently that watchdog would _always_
deliver false positives and pull the trigger immediately (in fact, this
is precisely the situation we face @work with some special board
emulation where we have to provide an NMI-based watchdog).

Moreover, only the second and succeeding NMIs under the same
interrupts-disabled window need to get lost: Along with injecting the
first NMI we could request the IRQ window unconditionally, using it to
reset the virtual NMI-blocked state.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]