On Wed, Apr 21, 2010 at 05:14:04PM +0200, Jan Kiszka wrote: > > No you don't. I was told that software should be prepared to handle NMI > > after MOV SS. What part of SDM does this contradict? I found nothing in > > latest SDM. > > [ updated to March 2010 version ] > > To sum up the scenario again, I think it started with > > • If the “NMI-window exiting” VM-execution control is 1, a VM exit occurs before > execution of any instruction if there is no virtual-NMI blocking and there is no > blocking of events by MOV SS (see Table 21-3). (A logical processor may also > prevent such a VM exit if there is blocking of events by STI.) Such a VM exit > occurs immediately after VM entry if the above conditions are true (see Section > 23.6.6). > > > We included STI into the NMI shadow, but we /may/ get early exits on > some processors according to the statement above. According to your > latest info, we can also get that when the MOV SS shadow is on!? But > simply allowing NMI injection under MOV SS is not possible: > > 23.3 CHECKING AND LOADING GUEST STATE > 23.3.1.5 Checks on Guest Non-Register State > > • Interruptibility state. > ... > — Bit 1 (blocking by MOV-SS) must be 0 if the valid bit (bit 31) in the VM-entry > interruption-information field is 1 and the interruption type (bits 10:8) in that > field has value 2, indicating non-maskable interrupt (NMI). > > > And doing this for STI sounds risky too: > > — A processor may require bit 0 (blocking by STI) to be 0 if the valid bit (bit 31) > in the VM-entry interruption-information field is 1 and the interruption type > (bits 10:8) in that field has value 2, indicating NMI. Other processors may not > make this requirement. > > > Should we start stepping over the shadow like we do for svm? > Intel's answer is that text above describes model-specific behaviour in bare metal which can block NMI for one instruction after STI/MOV SS, but since software should not rely on model-specific behaviour we can safely inject NMI after STI/MOV SS (clearing "blocked by STI/MOV SS" bit before injecting). -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html