From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 3/3] KVM: SVM: Lazy fpu for npt Date: Thu, 07 Jan 2010 18:55:31 +0200 Message-ID: <4B461203.9030800@redhat.com> References: <1262866544-4985-1-git-send-email-avi@redhat.com> <1262866544-4985-4-git-send-email-avi@redhat.com> <20100107165204.GA17809@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Joerg Roedel , kvm@vger.kernel.org To: Joerg Roedel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:24868 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752324Ab0AGQze (ORCPT ); Thu, 7 Jan 2010 11:55:34 -0500 In-Reply-To: <20100107165204.GA17809@8bytes.org> Sender: kvm-owner@vger.kernel.org List-ID: On 01/07/2010 06:52 PM, Joerg Roedel wrote: > On Thu, Jan 07, 2010 at 02:15:44PM +0200, Avi Kivity wrote: > >> If two conditions apply: >> - no bits outside TS and EM differ between the host and guest cr0 >> - the fpu is active >> >> then we can activate the selective cr0 write intercept and drop the >> unconditional cr0 read and write intercept, and allow the guest to run >> with the host fpu state. This reduces the heavyweight context switch >> when npt is enabled. >> > > >> - if (npt_enabled) { >> - int mmu_reload = 0; >> - if ((kvm_read_cr0_bits(vcpu, X86_CR0_PG) ^ svm->vmcb->save.cr0) >> - & X86_CR0_PG) { >> - svm_set_cr0(vcpu, svm->vmcb->save.cr0); >> - mmu_reload = 1; >> - } >> + if (!(svm->vmcb->control.intercept_cr_write& INTERCEPT_CR0_MASK)) >> vcpu->arch.cr0 = svm->vmcb->save.cr0; >> + if (npt_enabled) >> vcpu->arch.cr3 = svm->vmcb->save.cr3; >> - if (mmu_reload) { >> - kvm_mmu_reset_context(vcpu); >> - kvm_mmu_load(vcpu); >> - } >> - } >> - >> > Hmm, I think removing this hack is a seperate issue. Should it be a > sepearte patch which enables cr0 intercept for npt and removes these > lines? It makes this change more clear in the logs. > Enabling cr0 intercept without enabling selective cr0 intercept will be a massive performance regression, so performance-wise these two are tied up. But I agree that it would make the patch easier to read, I'll try to split it up. -- error compiling committee.c: too many arguments to function