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?
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox