Gleb Natapov wrote:
> On Wed, Apr 21, 2010 at 04:41:38PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> On Wed, Apr 21, 2010 at 04:17:03PM +0200, Jan Kiszka wrote:
>>>> Gleb Natapov wrote:
>>>>> On Tue, Feb 16, 2010 at 11:37:15AM +0100, Jan Kiszka wrote:
>>>>>> Gleb Natapov wrote:
>>>>>>> On Tue, Feb 16, 2010 at 11:27:07AM +0100, Jan Kiszka wrote:
>>>>>>>> Gleb Natapov wrote:
>>>>>>>>> On Tue, Feb 16, 2010 at 11:14:45AM +0100, Jan Kiszka wrote:
>>>>>>>>>> Gleb Natapov wrote:
>>>>>>>>>>> On Tue, Feb 16, 2010 at 11:04:10AM +0100, Jan Kiszka wrote:
>>>>>>>>>>>> Gleb Natapov wrote:
>>>>>>>>>>>>> On Tue, Feb 16, 2010 at 10:16:12AM +0100, Jan Kiszka wrote:
>>>>>>>>>>>>>> Found while browsing Xen code: While we assume that the STI interrupt
>>>>>>>>>>>>>> shadow also inplies virtual NMI blocking, some processors may have a
>>>>>>>>>>>>>> different opinion (SDM 3: 22.3). To avoid misunderstandings that would
>>>>>>>>>>>>>> cause endless VM entry attempts, translate STI into MOV SS blocking when
>>>>>>>>>>>>>> requesting the NMI window.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Why not just remove "block by STI" check in vmx_nmi_allowed()? IIRC this
>>>>>>>>>>>>> is documented that on some CPUs STI does not block NMI.
>>>>>>>>>>>>>
>>>>>>>>>>>> Probably because we will stumble and fall on those CPUs that do care.
>>>>>>>>>>>>
>>>>>>>>>>> But this defines behaviour of cpu _we_ emulate. So on _our_ cpu NMI will
>>>>>>>>>>> not be blocked by STI.
>>>>>>>>>> The host CPU decides if it accepts an NMI injections while
>>>>>>>>> Are you sure? I haven't found such check during VMENTRY.
>>>>>>>> I also only find the explicitly stated exclusion of MOV SS blocking vs.
>>>>>>>> NMI injection. If we can rely on this, removing STI blocking from
>>>>>>>> vmx_nmi_allowed should suffice. Or, better, can we get an official
>>>>>>>> confirmation from Intel?
>>>>>>>>
>>>>>>> SDM 2b says about STI instruction:
>>>>>>> The IF flag and the STI and CLI instructions do not prohibit the
>>>>>>> generation of exceptions and NMI interrupts. NMI interrupts (and SMIs)
>>>>>>> may be blocked for one macroinstruction following an STI.
>>>>>> Yes, it's likely that this is the architectural reason for the delayed
>>>>>> NMI window signaling after STI. Still, we are looking for the
>>>>>> entry-check logic.
>>>>>>
>>>>> Will ask Intel.
>>>>>
>>>> Just remembered that there was some open topic... Did your ask? Any answer?
>>>>
>>> I did and got answer last week :) The answer is that NMI is blocked only
>>> if GUEST_INTR_STATE_NMI flag is set. MOV SS and STI shouldn't block NMI,
>>> so vmx_nmi_allowed() should check only GUEST_INTR_STATE_NMI flag.
>> Cool, that's now increasing my level of confusion again: :(
>>
>> Thought we only wanted to confirm that it's still safe to inject NMIs
>> when blocked-by-STI is set. Now we hear that it's also safe when MOV SS
>> is active? That would directly contradict the SDM (at least the version
>> I have at hand: June 2009). Or did I misunderstand the answer?
>>
> 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?
[ There should be a law that requires hardware builders to write
software according to their own manuals... ]
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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
