Re: [PATCH 3/6 v2] KVM: PPC: Book3E: Increase FPU laziness

[Alexander Graf <agraf@suse.de>]

On 04.07.14 09:46, Alexander Graf wrote:
>
> On 03.07.14 17:46, mihai.caraman@freescale.com wrote:
>>> -----Original Message-----
>>> From: Alexander Graf [mailto:agraf@suse.de]
>>> Sent: Thursday, July 03, 2014 3:29 PM
>>> To: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org
>>> Cc: kvm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>>> Subject: Re: [PATCH 3/6 v2] KVM: PPC: Book3E: Increase FPU laziness
>>>
>>>
>>> On 30.06.14 17:34, Mihai Caraman wrote:
>>>> Increase FPU laziness by calling kvmppc_load_guest_fp() just before
>>>> returning to guest instead of each sched in. Without this improvement
>>>> an interrupt may also claim floting point corrupting guest state.
>>> How do you handle context switching with this patch applied? During 
>>> most
>>> of the guest's lifetime we never exit kvmppc_vcpu_run(), so when the
>>> guest gets switched out all FPU state gets lost?
>> No, we had this discussion in ver 1. The FP/VMX/VSX is implemented 
>> lazy in
>> the kernel i.e. the unit state is not saved/restored until another 
>> thread
>> that once claimed the unit is sched in.
>>
>> Since FP/VMX/VSX can be activated by the guest independent of the 
>> host, the
>> vcpu thread is always using the unit (even if it did not claimed it 
>> once).
>>
>> Now, this patch optimize the sched in flow. Instead of checking on 
>> each vcpu
>> sched in if the kernel unloaded unit's guest state for another 
>> competing host
>> process we do this when we enter the guest.
>
> But we only do it when we enter the guest from QEMU, not when we enter 
> the guest after a context switch on cond_resched(), no?

Ah, I missed the call to the load function in handle_exit(). Ok, I think 
that approach should work.


Alex