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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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
