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 ?
> 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.
--
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
