Re: [PATCH 1/2] KVM: x86 emulator: don't update vcpu state if instruction is restarted.

[Avi Kivity <avi@redhat.com>]

  On 08/02/2010 10:58 AM, Gleb Natapov wrote:
> On Mon, Aug 02, 2010 at 08:04:20AM +0300, Avi Kivity wrote:
>>   On 08/01/2010 04:27 PM, Gleb Natapov wrote:
>>> When we are going to enable e_i_g_s by default?
>> Optimistically, 2.6.37, so six months.
>>
>>> May be we have enough
>>> time to fix userspace?
>> Sure we do, but will users update?
>>
>> 0.12 is mature enough that some users will forget about it and not
>> update it.
>>
> So they will not update kernel too. 0.12/2.6.32 should be mature combo.
> And we can add patch to 0.12/0.13 stable to work on newer kernels.

We don't know what they'll do.  API stability means we only change 
things to fix bugs.

> But
> realistically the problem will occur only if TPR access is done from big
> real mode by Windows XP running on old Intel cpus. What are the chances
> that this will be a problem in practice?

Windows XP does use big real mode (I think unintentionally, some segment 
registers aren't cleared).

>>> Too ancient userspace already does not run on recent
>>> kvm. Or may be we can make userspace enable e_i_g_s per guest. This way
>>> userspace that knows it is OK can tell kernel so.
>> Let's make it the other way round, enable the optimization for
>> userspace that declares that it does not make use of rip during
>> emulation (kvm-tpr-opt can be changed by queueing a signal and
>> re-entering the guest to complete the operation).
>>
>> Later we can make the optimization unconditional.
>>
> What do you call "optimization"? e_i_g_s=1? Isn't it the same as I proposed
> then?

The optimization is your patch.

Step 1: only enable the optimization if userspace indicates it can 
handle it.
<time passes>
Step 2: drop the backwards compatibility code, always enable the 
optimization.

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