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

[Avi Kivity <avi@redhat.com>]

  On 08/27/2010 07:43 PM, Jan Kiszka wrote:
> 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.

Note we already trap all exceptions on Intel when virtualizing real mode 
via vm86.

> 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.

Doesn't worry me too much.  NMI rate will be limited or 
program-under-test performance will suffer.  10K vs 20K exits/sec is 
substantial, but not worth worrying about for this fairly rare use case.

I'm more concerned that we don't push VMLOAD/VMSAVE to the heavyweight 
exit path, and that we don't use the svm interrupt queue (that could 
reduce 10% of the exits on normal interrupts).


-- 
error compiling committee.c: too many arguments to function