From: Sean Christopherson <seanjc@google.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: John Allen <john.allen@amd.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, pbonzini@redhat.com, dave.hansen@intel.com,
rick.p.edgecombe@intel.com, mlevitsk@redhat.com,
weijiang.yang@intel.com, chao.gao@intel.com, bp@alien8.de,
dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com,
tglx@linutronix.de
Subject: Re: [PATCH v2 2/2] x86/sev-es: Include XSS value in GHCB CPUID request
Date: Tue, 16 Sep 2025 12:44:44 -0700 [thread overview]
Message-ID: <aMm-LMjCeXguOhay@google.com> (raw)
In-Reply-To: <797c84fe-aec7-3e29-a581-d6d1a3878aaa@amd.com>
On Tue, Sep 09, 2025, Tom Lendacky wrote:
> On 9/8/25 15:20, John Allen wrote:
> > When a guest issues a cpuid instruction for Fn0000000D_{x00,x01}, the
> > hypervisor will be intercepting the CPUID instruction and will need to access
> > the guest XSS value. For SEV-ES, the XSS value is encrypted and needs to be
> > included in the GHCB to be visible to the hypervisor.
> >
> > Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> > Signed-off-by: John Allen <john.allen@amd.com>
> > ---
> > arch/x86/coco/sev/vc-shared.c | 11 +++++++++++
> > arch/x86/include/asm/svm.h | 1 +
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/arch/x86/coco/sev/vc-shared.c b/arch/x86/coco/sev/vc-shared.c
> > index 2c0ab0fdc060..079fffdb12c0 100644
> > --- a/arch/x86/coco/sev/vc-shared.c
> > +++ b/arch/x86/coco/sev/vc-shared.c
> > @@ -1,5 +1,9 @@
> > // SPDX-License-Identifier: GPL-2.0
> >
> > +#ifndef __BOOT_COMPRESSED
> > +#define has_cpuflag(f) boot_cpu_has(f)
> > +#endif
> > +
> > static enum es_result vc_check_opcode_bytes(struct es_em_ctxt *ctxt,
> > unsigned long exit_code)
> > {
> > @@ -452,6 +456,13 @@ static enum es_result vc_handle_cpuid(struct ghcb *ghcb,
> > /* xgetbv will cause #GP - use reset value for xcr0 */
> > ghcb_set_xcr0(ghcb, 1);
> >
> > + if (has_cpuflag(X86_FEATURE_SHSTK) && regs->ax == 0xd && regs->cx <= 1) {
Only CPUID.0xD.1 consumes XSS. CPUID.0xD.0 only consumes XCR0. I.e. this could
be "&& regs->cx == 1".
> Just a nit, but I wonder if we should be generic here and just do
> has_cpuflag(X86_FEATURE_XSAVES) since that should be set if shadow stack
> is enabled, right? And when X86_FEATURE_XSAVES is set, we don't
> intercept XSS access (see sev_es_recalc_msr_intercepts()).
On the other hand, by exposing XSS to the host only on CPUID #VCs, you've already
"optimized" this code based on presumed usage of XSS by the hypervisor.
prev parent reply other threads:[~2025-09-16 19:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 20:20 [PATCH v2 0/2] Support for SEV-ES guest shadow stack John Allen
2025-09-08 20:20 ` [PATCH v2 1/2] x86/boot: Move boot_*msr helpers to asm/shared/msr.h John Allen
2025-09-08 20:20 ` [PATCH v2 2/2] x86/sev-es: Include XSS value in GHCB CPUID request John Allen
2025-09-09 20:04 ` Tom Lendacky
2025-09-16 19:44 ` Sean Christopherson [this message]
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=aMm-LMjCeXguOhay@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
/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.