From: Sean Christopherson <seanjc@google.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Kim Phillips <kim.phillips@amd.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, x86@kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Nikunj A Dadhania <nikunj@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Michael Roth <michael.roth@amd.com>,
Naveen Rao <naveen.rao@amd.com>,
David Kaplan <david.kaplan@amd.com>
Subject: Re: [PATCH v2 2/3] KVM: SEV: Add support for IBPB-on-Entry
Date: Mon, 2 Mar 2026 07:10:59 -0800 [thread overview]
Message-ID: <aaWog_UjW-M3412C@google.com> (raw)
In-Reply-To: <20260228165506.GAaaMd6nQ56E7i5Cqg@fat_crate.local>
On Sat, Feb 28, 2026, Borislav Petkov wrote:
> Sean, ack for the KVM bits and me taking them thru tip?
Ya, should be fine for this to go through tip.
> On Tue, Feb 03, 2026 at 04:24:04PM -0600, Kim Phillips wrote:
> > AMD EPYC 5th generation and above processors support IBPB-on-Entry
> > for SNP guests. By invoking an Indirect Branch Prediction Barrier
> > (IBPB) on VMRUN, old indirect branch predictions are prevented
> > from influencing indirect branches within the guest.
> >
> > SNP guests may choose to enable IBPB-on-Entry by setting
> > SEV_FEATURES bit 21 (IbpbOnEntry).
> >
> > Host support for IBPB on Entry is indicated by CPUID
> > Fn8000_001F[IbpbOnEntry], bit 31.
> >
> > If supported, indicate support for IBPB on Entry in
> > sev_supported_vmsa_features bit 23 (IbpbOnEntry).
> >
> > For more info, refer to page 615, Section 15.36.17 "Side-Channel
> > Protection", AMD64 Architecture Programmer's Manual Volume 2: System
> > Programming Part 2, Pub. 24593 Rev. 3.42 - March 2024 (see Link).
> >
> > Link: https://bugzilla.kernel.org/attachment.cgi?id=306250
> > Signed-off-by: Kim Phillips <kim.phillips@amd.com>
> > Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> > ---
...
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > index ea515cf41168..8a6d25db0c00 100644
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> > @@ -3165,8 +3165,15 @@ void __init sev_hardware_setup(void)
> > cpu_feature_enabled(X86_FEATURE_NO_NESTED_DATA_BP))
> > sev_supported_vmsa_features |= SVM_SEV_FEAT_DEBUG_SWAP;
> >
> > - if (sev_snp_enabled && tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
> > + if (!sev_snp_enabled)
> > + return;
> > + /* the following feature bit checks are SNP specific */
> > +
> > + if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
> > sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
> > +
> > + if (cpu_feature_enabled(X86_FEATURE_IBPB_ON_ENTRY))
> > + sev_supported_vmsa_features |= SVM_SEV_FEAT_IBPB_ON_ENTRY;
> > }
I think I'd prefer to nest the if-statement, e.g.
if (sev_snp_enabled) {
if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
if (cpu_feature_enabled(X86_FEATURE_IBPB_ON_ENTRY))
sev_supported_vmsa_features |= SVM_SEV_FEAT_IBPB_ON_ENTRY;
}
I'm mildly concerned that'll we'll overlook the early return and unintentionally
bury common code in the SNP-section tail.
More importantly, this patch is buggy. __sev_guest_init() needs to disallow
setting SVM_SEV_FEAT_IBPB_ON_ENTRY for non-SNP guests.
As a follow-up, I also think we should advertise SVM_SEV_FEAT_SNP_ACTIVE and
allow userspace to set the flag in kvm_sev_init.flags. KVM still needs to set
the flag for backwards compatibility, but disallowing SVM_SEV_FEAT_SNP_ACTIVE
for an SNP guest is bizarre.
E.g. across 2 or 3 patches:
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index edde36097ddc..7db1bfce4cca 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -307,6 +307,10 @@ static_assert((X2AVIC_4K_MAX_PHYSICAL_ID & AVIC_PHYSICAL_MAX_INDEX_MASK) == X2AV
#define SVM_SEV_FEAT_DEBUG_SWAP BIT(5)
#define SVM_SEV_FEAT_SECURE_TSC BIT(9)
+#define SVM_SEV_FEAT_SNP_ONLY_MASK (SVM_SEV_FEAT_SNP_ACTIVE | \
+ SVM_SEV_FEAT_SECURE_TSC | \
+ SVM_SEV_FEAT_IBPB_ON_ENTRY)
+
#define VMCB_ALLOWED_SEV_FEATURES_VALID BIT_ULL(63)
struct vmcb_seg {
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 41385573629e..b2fe0fa11f90 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -500,7 +500,7 @@ static int __sev_guest_init(struct kvm *kvm, struct kvm_sev_cmd *argp,
return -EINVAL;
if (!snp_active)
- valid_vmsa_features &= ~SVM_SEV_FEAT_SECURE_TSC;
+ valid_vmsa_features &= ~SVM_SEV_FEAT_SNP_ONLY_MASK;
if (data->vmsa_features & ~valid_vmsa_features)
return -EINVAL;
@@ -3218,8 +3218,15 @@ void __init sev_hardware_setup(void)
cpu_feature_enabled(X86_FEATURE_NO_NESTED_DATA_BP))
sev_supported_vmsa_features |= SVM_SEV_FEAT_DEBUG_SWAP;
- if (sev_snp_enabled && tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
- sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+ if (sev_snp_enabled) {
+ sev_supported_vmsa_features |= SVM_SEV_FEAT_SNP_ACTIVE;
+
+ if (tsc_khz && cpu_feature_enabled(X86_FEATURE_SNP_SECURE_TSC))
+ sev_supported_vmsa_features |= SVM_SEV_FEAT_SECURE_TSC;
+
+ if (cpu_feature_enabled(X86_FEATURE_IBPB_ON_ENTRY))
+ sev_supported_vmsa_features |= SVM_SEV_FEAT_IBPB_ON_ENTRY;
+ }
}
void sev_hardware_unsetup(void)
next prev parent reply other threads:[~2026-03-02 15:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 22:24 [PATCH v2 0/3] KVM: SEV: Add support for IBPB-on-Entry Kim Phillips
2026-02-03 22:24 ` [PATCH v2 1/3] x86/sev: Allow IBPB-on-Entry feature for SNP guests Kim Phillips
2026-03-02 10:32 ` [tip: x86/urgent] " tip-bot2 for Kim Phillips
2026-02-03 22:24 ` [PATCH v2 2/3] KVM: SEV: Add support for IBPB-on-Entry Kim Phillips
2026-02-28 16:55 ` Borislav Petkov
2026-03-02 15:10 ` Sean Christopherson [this message]
2026-02-03 22:24 ` [PATCH v2 3/3] x86/sev: Rename SNP_FEATURES_PRESENT->SNP_FEATURES_IMPL Kim Phillips
2026-03-16 20:31 ` [tip: x86/sev] x86/sev: Rename SNP_FEATURES_PRESENT to SNP_FEATURES_IMPL tip-bot2 for Kim Phillips
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=aaWog_UjW-M3412C@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=david.kaplan@amd.com \
--cc=kim.phillips@amd.com \
--cc=kprateek.nayak@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=naveen.rao@amd.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=thomas.lendacky@amd.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.