All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"jmattson@google.com" <jmattson@google.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"vkuznets@redhat.com" <vkuznets@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"wanpengli@tencent.com" <wanpengli@tencent.com>,
	"brijesh.singh@amd.com" <brijesh.singh@amd.com>
Subject: Re: [PATCH 07/12] KVM: x86: SEV: Treat C-bit as legal GPA bit regardless of vCPU mode
Date: Thu, 4 Feb 2021 09:52:43 -0800	[thread overview]
Message-ID: <YBw0a5fFvtOrDwOR@google.com> (raw)
In-Reply-To: <e68beed4c536712ddf28cdd8296050222731415e.camel@intel.com>

On Thu, Feb 04, 2021, Edgecombe, Rick P wrote:
> On Thu, 2021-02-04 at 11:34 +0100, Paolo Bonzini wrote:
> > On 04/02/21 03:19, Sean Christopherson wrote:
> > > Ah, took me a few minutes, but I see what you're saying.  LAM will
> > > introduce
> > > bits that are repurposed for CR3, but not generic GPAs.  And, the
> > > behavior is
> > > based on CPU support, so it'd make sense to have a mask cached in
> > > vcpu->arch
> > > as opposed to constantly generating it on the fly.
> > > 
> > > Definitely agree that having a separate cr3_lm_rsvd_bits or
> > > whatever is the
> > > right way to go when LAM comes along.  Not sure it's worth keeping
> > > a duplicate
> > > field in the meantime, though it would avoid a small amount of
> > > thrash.
> > 
> > We don't even know if the cr3_lm_rsvd_bits would be a field in 
> > vcpu->arch, or rather computed on the fly.  So renaming the field in 
> > vcpu->arch seems like the simplest thing to do now.
> 
> Fair enough. But just to clarify, I meant that I thought the code would
> be more confusing to use illegal gpa bit checks for checking cr3. It
> seems they are only incidentally the same value.

Hmm, yeah, bits 63:52 are incidental.  Bits 52:M are not, though.  If/when we
need to special case CR3, I would like to take a similar approach to
__reset_rsvds_bits_mask(), where the high reserved bits start from
reserved_gpa_bits and mask off the bits that can't be encoded into a PxE.

> Alternatively there could be something like a is_rsvd_cr3_bits() helper that
> just uses reserved_gpa_bits for now. Probably put the comment in the wrong
> place.  It's a minor point in any case.

That thought crossed my mind, too.  Maybe kvm_vcpu_is_illegal_cr3() to match
the gpa helpers?

  reply	other threads:[~2021-02-04 17:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04  0:01 [PATCH 00/12] KVM: x86: Legal GPA fixes and cleanups Sean Christopherson
2021-02-04  0:01 ` [PATCH 01/12] KVM: x86: Set so called 'reserved CR3 bits in LM mask' at vCPU reset Sean Christopherson
2021-02-04  0:01 ` [PATCH 02/12] KVM: nSVM: Don't strip host's C-bit from guest's CR3 when reading PDPTRs Sean Christopherson
2021-02-04  0:01 ` [PATCH 03/12] KVM: x86: Add a helper to check for a legal GPA Sean Christopherson
2021-02-04  0:01 ` [PATCH 04/12] KVM: x86: Add a helper to handle legal GPA with an alignment requirement Sean Christopherson
2021-02-04  0:01 ` [PATCH 05/12] KVM: VMX: Use GPA legality helpers to replace open coded equivalents Sean Christopherson
2021-02-04  0:01 ` [PATCH 06/12] KVM: nSVM: Use common GPA helper to check for illegal CR3 Sean Christopherson
2021-02-04  0:01 ` [PATCH 07/12] KVM: x86: SEV: Treat C-bit as legal GPA bit regardless of vCPU mode Sean Christopherson
2021-02-04  2:03   ` Edgecombe, Rick P
2021-02-04  2:19     ` Sean Christopherson
2021-02-04 10:34       ` Paolo Bonzini
2021-02-04 17:31         ` Edgecombe, Rick P
2021-02-04 17:52           ` Sean Christopherson [this message]
2021-02-04 17:56             ` Paolo Bonzini
2021-02-04 18:01               ` Sean Christopherson
2021-02-04  0:01 ` [PATCH 08/12] KVM: x86: Use reserved_gpa_bits to calculate reserved PxE bits Sean Christopherson
2021-02-04  0:01 ` [PATCH 09/12] KVM: x86/mmu: Add helper to generate mask of reserved HPA bits Sean Christopherson
2021-02-04  0:01 ` [PATCH 10/12] KVM: x86: Add helper to consolidate "raw" reserved GPA mask calculations Sean Christopherson
2021-02-04  0:01 ` [PATCH 11/12] KVM: x86: Move nVMX's consistency check macro to common code Sean Christopherson
2021-02-04  0:01 ` [PATCH 12/12] KVM: nSVM: Trace VM-Enter consistency check failures Sean Christopherson
2021-02-04 10:44 ` [PATCH 00/12] KVM: x86: Legal GPA fixes and cleanups Paolo Bonzini

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=YBw0a5fFvtOrDwOR@google.com \
    --to=seanjc@google.com \
    --cc=brijesh.singh@amd.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.