public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Joel Schopp <joel.schopp@amd.com>
Cc: Gleb Natapov <gleb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	Borislav Petkov <bp@alien8.de>,
	linux-kernel@vger.kernel.org, David Kaplan <david.kaplan@amd.com>
Subject: Re: [PATCH] x86: svm: don't intercept CR0 TS or MP bit write
Date: Mon, 23 Feb 2015 20:17:30 +0100	[thread overview]
Message-ID: <20150223191729.GA2186@potion.brq.redhat.com> (raw)
In-Reply-To: <20150220224445.2875.66846.stgit@joelvmguard2.amd.com>

2015-02-20 16:44-0600, Joel Schopp:
> From: David Kaplan <david.kaplan@amd.com>
> 
> Reduce the number of exits by avoiding exiting when the guest writes TS or MP
> bits of CR0.  INTERCEPT_CR0_WRITE intercepts all writes to CR0 including TS and
> MP bits. It intercepts these even if INTERCEPT_SELECTIVE_CR0 is set.  What we
> should be doing is setting INTERCEPT_SELECTIVE_CR0 and not setting
> INTERCEPT_CR0_WRITE.
> 
> Signed-off-by: David Kaplan <david.kaplan@amd.com>
> [added remove of clr_cr_intercept in init_vmcb, fixed check in handle_exit,
> added emulation on interception back in, forward ported, tested]
> Signed-off-by: Joel Schopp <joel.schopp@amd.com>
> ---
>  arch/x86/kvm/svm.c |   13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index d319e0c..55822e5 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1539,10 +1538,8 @@ static void update_cr0_intercept(struct vcpu_svm *svm)
>  
>  	if (gcr0 == *hcr0 && svm->vcpu.fpu_active) {
>  		clr_cr_intercept(svm, INTERCEPT_CR0_READ);


> -		clr_cr_intercept(svm, INTERCEPT_CR0_WRITE);
>  	} else {
>  		set_cr_intercept(svm, INTERCEPT_CR0_READ);

(There is no point in checking fpu_active if cr0s are equal.)

> -		set_cr_intercept(svm, INTERCEPT_CR0_WRITE);

KVM uses lazy FPU and the state is undefined before the first access.
We set cr0.ts when !svm->vcpu.fpu_active to detect the first access, but
if we allow the guest to clear cr0.ts without exiting, it can access FPU
with undefined state.

Is this code failing to disable the intercept when FPU is active?

> @@ -2940,7 +2937,11 @@ static int cr_interception(struct vcpu_svm *svm)
> +	if (svm->vmcb->control.exit_code == SVM_EXIT_CR0_SEL_WRITE)
> +	   cr = 16;
   	^^^

> +	else
> +	   cr = svm->vmcb->control.exit_code - SVM_EXIT_READ_CR0;
   	^^^

Linux uses tabs for indentation.

> @@ -3502,7 +3503,7 @@ static int handle_exit(struct kvm_vcpu *vcpu)
>  	struct kvm_run *kvm_run = vcpu->run;
>  	u32 exit_code = svm->vmcb->control.exit_code;
>  
> -	if (!is_cr_intercept(svm, INTERCEPT_CR0_WRITE))
> +	if (!is_cr_intercept(svm, INTERCEPT_SELECTIVE_CR0))
>  		vcpu->arch.cr0 = svm->vmcb->save.cr0;

I think the purpose of this code is to get changes that happened while
we weren't monitoring CR0, and we introduce a bug here ... MP and TS can
change, but those changes are lost to arch.cr0 now.

(The original code was also suspicious -- we propagate changes of
 vmcb->save.cr0.  I don't think we want to clear guest's CD and NW /
 set MP and TS, which is the result of what we do in svm_set_cr0() /
 update_cr0_intercept() ...)

  reply	other threads:[~2015-02-23 19:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20 22:44 [PATCH] x86: svm: don't intercept CR0 TS or MP bit write Joel Schopp
2015-02-23 19:17 ` Radim Krčmář [this message]
2015-02-24 21:25   ` Joel Schopp
2015-02-25 20:26     ` Radim Krčmář
2015-02-25 22:39       ` Joel Schopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150223191729.GA2186@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=bp@alien8.de \
    --cc=david.kaplan@amd.com \
    --cc=gleb@kernel.org \
    --cc=joel.schopp@amd.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox