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 05:13 PM, Jan Kiszka wrote:
>>> I forgot them already.  What was that, exception during IRET?
>> Exception during IRET or any instruction under the interrupt shadow will
>> push the TF we set to step over this issue on the guest stack. We do not
>> intercept all the possible exceptions, so we can leak TF. Moreover,
>> multiplexing TF users is currently imperfect on AMD but, before fixing
>> that, we have to think about the approach in general.
> 
> Thanks.  I think those are all solvable.  The key IMO is to take a state 
> based approach to host bits - instead of setting or clearing a bit in 
> response to an event, use the event as a trigger for recalculation of 
> the bit's value.  This works for bits which have multiple uses, and for 
> recovery from KVM_SET_*.  For guest bits which are needed by the host we 
> also have a working approach - when the bit is overloaded, trap all 
> instructions that can see it, as in CR0.TS.
> 
> It may take some work but I think we can achieve 100% accuracy without 
> making the code unmaintainable.

Besides making TF usage robust against multiple users, including the
guest itself, my complexity concern is first of all about preventing its
leakage. We will have to trap _all_ exceptions and properly remove TF
from the guest state.

And then there is a potential performance price to pay (yes, accuracy
should come first): If the guest uses NMIs for profiles, thus at a
significant rate, AMD processors force us to exit twice per NMI return -
independent of the fact if there is another NMI pending or not.

> 
>>> I'd really like to avoid the timer.  But I forgot all the details around
>>> this, I'll have to re-learn them so I can actually compare the two options.
>>>
>> Hope the above helps you to get on track, otherwise drop more questions.
>> Also putting Joerg on CC (in the futile hope that the longer the CC list
>> is, the lesser the pain becomes for each individual).
> 
> I think I got it.  And I also think we need to start documenting these 
> invariants, to make it easier for people to see the method in all that 
> chaos.

Agreed.

Jan

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