On Thursday 11 September 2008 23:11:14 Jan Kiszka wrote: > Hi Sheng, > > we had parts of this discussion privately a while back, but now I need > to dig deeper. I finally have to complete and push out user space NMI > injection that bitrots over and over again in my queue. > > Intel CPUs with virtual NMI support can easily be programmed to inject > NMIs only when the guest CPU is ready or tell the guest to exit as soon > as it changes its NMI readiness. But we are also facing a lot of CPUs > that were produced without this feature, and we need to find some way to > achieve virtual NMI support for them, even if the interruptibility of > the guest is not as good as with true virtual NMIs. > > Now my questions to you or anyone else with VMX expert knowledge: > > The System Programming Guide, Volume 3B, 27.2 says that "Without > NMI-window exiting support, the VMM will need to poll and check the > interruptibility state of the guest to deliver virtual NMIs." > Interruptibility involves, besides "blocked by MOV SS" and "blocked by > STI", the NMI nesting. So, how can the VMM track if the guest is still > inside its NMI handler after event injection?
I think, we have no direct idea about that... > According to 22.6.1, NMI blocking is active as long as the guest runs if > the "NMI-exiting" control bit is 1 (and setting it appears to be > required to avoid that the guest can block NMIs for the host, right?). Yes. > But what does this mean for bit 3 of the interruptibility state? Can I > still use it after some guest exit for whatever reason (like a hard IRQ) > to poll if the guest can now accept pending virtual NMIs? No. Though the public spec is a little ambiguous, I just checked some document and found that, if "virtual NMI" is not enabled, "Block by NMI" just indicated block *host physical* NMI rather than virtual NMI. > In that case, virtual NMI injections would only be delayed a bit on older >CPUs, but could still work reliably, right? Or is there some other way to >track the NMI interruptibility on such CPUs? I hope so, but sadly seems we can't know if we can inject NMI to guest without enable "virtual NMI". After some brainstorming with my colleague Haitao, we found one way *may* can work on non-virtual nmi supported hardware, but it's very tricky and untested(just a theoretical idea), also sacrifice host physical NMI, and depends on guest NMI implement. The basic idea is: 1. Disable "NMI Exiting" feature, so that guest would handle any host physical NMI. 2. Set "Blocking by NMI" to true. So if guest execute "iret", this bit should be cleaned. This also block physical NMIs. 3. Enable "IRQ Window" and ensure IDT vector 2 is a interrupt gate(so that IF bit is cleared when executing the handler). So we use IRQ window to replace NMI window here, otherwise for the period between IRET and VMEXIT, host physical NMIs would be handled by guest handler. 4. Check "IRQ Window" exit, if "Blocking by NMI" is cleared(also STI and SS), we can inject NMI. It's just untested idea, and I think it's quite tricky. If you still have interest, you may try it, but I can't guarantee the result... Thanks. -- regards Yang, Sheng > > TiA, > Jan -- 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
