Re: [PATCH 1/1] Disable GUEST_INTR_STATE_STI flag before injecting NMI to guest on VMX

[Jan Kiszka <jan.kiszka@siemens.com>]

Avi Kivity wrote:
>   On 08/27/2010 11:27 AM, Jan Kiszka wrote:
>> Am 26.08.2010 22:06, Jes.Sorensen@redhat.com wrote:
>>> From: Jes Sorensen<Jes.Sorensen@redhat.com>
>>>
>>> Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
>>> which can cause an EXIT with invalid state, resulting in the
>>> guest dieing.
>> Very interesting. Reality obviously doesn't bother about the statement
>> of the vendor [1].
>>
>> Just curious: is this limited to specific CPU models or actually a
>> generic issue?
>>
> 
> The manual states that whether a processor accepts NMIs when 
> blocked-by-STI or not is processor dependent.

Yes, but this is fairly new, and when Gleb asked Intel, the answer was a
clear "no, there is no such requirement". Maybe someone found the
related processor code in the meantime...

> 
>> Thinking about the implications: Independent of virtualization, this
>> means that no code code can in any way rely on the STI shadow if there
>> are NMIs present that could "consume" it. Because after return from
>> those NMIs, interrupts could then be injected on the instruction that
>> was originally under the shadow.
>>
> 
> Wow.  Maybe we should request an interrupt window instead when 
> blocked-by-STI is active instead of clearing it.
> 

Then we are (almost) back in pre-NMI-window times when the guest happens
to spin with IRQs disabled.

What a mess.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux