On 04.07.14 09:46, Alexander Graf wrote:
On 03.07.14 17:46, mihai.caraman@xxxxxxxxxxxxx wrote:
-----Original Message-----
From: Alexander Graf [mailto:agraf@xxxxxxx]
Sent: Thursday, July 03, 2014 3:29 PM
To: Caraman Mihai Claudiu-B02008; kvm-ppc@xxxxxxxxxxxxxxx
Cc: kvm@xxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
