Re: [PATCH 2/2] KVM: SVM: check for progress after IRET interception

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

On 2011-02-03 16:07, Avi Kivity wrote:
> On 02/03/2011 05:02 PM, Avi Kivity wrote:
>> When we enable an NMI window, we ask for an IRET intercept, since
>> the IRET re-enables NMIs.  However, the IRET intercept happens before
>> the instruction executes, while the NMI window architecturally opens
>> afterwards.
>>
>> To compensate for this mismatch, we only open the NMI window in the
>> following exit, assuming that the IRET has by then executed; however,
>> this assumption is not always correct; we may exit due to a host interrupt
>> or page fault, without having executed the instruction.
>>
>> Fix by checking for forward progress by recording and comparing the IRET's
>> rip.  This is somewhat of a hack, since an unchaging rip does not mean that
>> no forward progress has been made, but is the simplest fix for now.
>>
> 
> So what would be a better fix?  We could unconditionally single step on 
> iret_interception() which would fix the problem at the cost of making 
> NMIs less efficient (three exits instead of two).  We could emulate the 
> IRET (doubling kvm's code and likely slower, and certainly buggier, than 
> the first option).  Alternatively, can anyone think of a reliable way to 
> make sure forward progress has been made?

Joerg and I discussed this a few times, I think last on the KVM forum.
It's really tricky and we found no option without limitations.
Single-stepping, e.g., already pollutes the guest state (if an exception
is taken without prior vmexit).

I don't recall all alternatives, but a vmexit-saving one was (IIRC) to
fall back to an interrupt window without IRET interception, likely
augmented with some break-out timer like we do for oldish, vnmi-lacking
Intels.

Jan

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