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
signature.asc
Description: OpenPGP digital signature
