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@xxxxxxxxxx>
+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.
--
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
