From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 4/5] KVM: Lazify fpu activation and deactivation Date: Wed, 06 Jan 2010 05:18:13 +0200 Message-ID: <4B4400F5.2010309@redhat.com> References: <1262190342-18611-1-git-send-email-avi@redhat.com> <1262190342-18611-5-git-send-email-avi@redhat.com> <20100106002529.GA11233@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sheng Yang , Joerg Roedel , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:29169 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754877Ab0AFDSW (ORCPT ); Tue, 5 Jan 2010 22:18:22 -0500 In-Reply-To: <20100106002529.GA11233@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: 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 >> > >> +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.