Re: [PATCH 4/5] KVM: Lazify fpu activation and deactivation

[Avi Kivity <avi@redhat.com>]

On 01/06/2010 02:25 AM, Marcelo Tosatti wrote:
> On Wed, Dec 30, 2009 at 06:25:41PM +0200, Avi Kivity wrote:
>    
>> Defer fpu deactivation as much as possible - if the guest fpu is loaded, keep
>> it loaded until the next heavyweight exit (where we are forced to unload it).
>> This reduces unnecessary exits.
>>
>> We also defer fpu activation on clts; while clts signals the intent to use the
>> fpu, we can't be sure the guest will actually use it.
>>
>> Signed-off-by: Avi Kivity<avi@redhat.com>
>>      
>    
>> +static void svm_fpu_deactivate(struct kvm_vcpu *vcpu)
>> +{
>> +	struct vcpu_svm *svm = to_svm(vcpu);
>> +
>> +	if (npt_enabled) {
>> +		/* hack: npt requires active fpu at this time */
>> +		vcpu->fpu_active = 1;
>> +		return;
>> +	}
>>      
> Why is that ?
>    

A guest context switch will involve setting cr0.ts and possibly issuing 
clts after the fpu is first used:

   _switch_to()
      unlazy_fpu()
         stts()

So we will get an exit on cr0 writes on every guest context switch until 
the fpu is loaded.  vmx avoids this by allowing writes that don't change 
important bits to proceed.

Hmm,  I see the write is conditional, so it may not be as bad as that.  
We'll have to test other guests to make sure they all do conditional stts().

Joerg, what was the reason the initial npt implementation did not do 
lazy fpu switching?

>>   void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>>   {
>> -	kvm_x86_ops->vcpu_put(vcpu);
>>   	kvm_put_guest_fpu(vcpu);
>> +	kvm_x86_ops->vcpu_put(vcpu);
>>   }
>>      
> It might be possible to defer host FPU restoration to
> user-return-notifier/kernel_fpu_begin time, so you'd keep the guest FPU
> loaded across qemukvm->kernel task->qemukvm switches. Not sure if its
> worthwhile though.
>    

I have some vague plans to do that, as well as make kernel_fpu_begin() 
preemptable.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.