public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Schopp <joel.schopp@amd.com>
To: "Radim Krčmář" <rkrcmar@redhat.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] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts
Date: Mon, 16 Mar 2015 11:16:05 -0500	[thread overview]
Message-ID: <550701C5.8050603@amd.com> (raw)
In-Reply-To: <20150312212002.GA1711@potion.brq.redhat.com>



On 03/12/2015 04:20 PM, Radim Krčmář wrote:
> 2015-03-12 15:17-0500, Joel Schopp:
>> There isn't really a valid reason for kvm to intercept cr* reads
>> on svm hardware.  The current kvm code just ends up returning
>> the register
> There is no need to intercept CR* if the value that the guest should see
> is equal to what we set there, but that is not always the case:
> - CR0 might differ from what the guest should see because of lazy fpu
Based on our previous conversations I understand why we have to trap the
write to the CR0 ts bit for lazy fpu, but don't understand why that
should affect a read.  I'll take another look at the code to see what
I'm missing.  You are probably correct in which case I'll modify the
patch to only turn off the read intercepts when lazy fpu isn't active.

> - CR3 isn't intercepted with nested paging and it should differ
>   otherwise
> - CR4 contains PAE bit when run without nested paging
>
> CR2 and CR8 already aren't intercepted, so it looks like only CR0 and
> CR4 could use some optimizations.
I'll send out a v2 with these less aggressive optimizations.

  reply	other threads:[~2015-03-16 16:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12 20:17 [PATCH] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts Joel Schopp
2015-03-12 21:17 ` Bandan Das
2015-04-03 12:19   ` Radim Krčmář
2015-03-12 21:20 ` Radim Krčmář
2015-03-16 16:16   ` Joel Schopp [this message]
2015-03-16 17:34     ` Radim Krčmář

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=550701C5.8050603@amd.com \
    --to=joel.schopp@amd.com \
    --cc=bp@alien8.de \
    --cc=david.kaplan@amd.com \
    --cc=gleb@kernel.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@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