The SEV-SNP IBPB-on-Entry feature does not require a guest-side
implementation. The feature was added in Zen5 h/w, after the first
SNP Zen implementation, and thus was not accounted for when the
initial set of SNP features were added to the kernel.
In its abundant precaution, commit 8c29f0165405 ("x86/sev: Add SEV-SNP
guest feature negotiation support") included SEV_STATUS' IBPB-on-Entry
bit as a reserved bit, thereby masking guests from using the feature.
Unmask the bit, to allow guests to take advantage of the feature on
hypervisor kernel versions that support it: Amend the SEV_STATUS MSR
SNP_RESERVED_MASK to exclude bit 23 (IbpbOnEntry).
Fixes: 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support")
Cc: Nikunj A Dadhania <nikunj@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
CC: Borislav Petkov (AMD) <bp@alien8.de>
CC: Michael Roth <michael.roth@amd.com>
Cc: stable@kernel.org
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
---
arch/x86/boot/compressed/sev.c | 1 +
arch/x86/coco/sev/core.c | 1 +
arch/x86/include/asm/msr-index.h | 5 ++++-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index c8c1464b3a56..2b639703b8dd 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -188,6 +188,7 @@ bool sev_es_check_ghcb_fault(unsigned long address)
MSR_AMD64_SNP_RESERVED_BIT13 | \
MSR_AMD64_SNP_RESERVED_BIT15 | \
MSR_AMD64_SNP_SECURE_AVIC | \
+ MSR_AMD64_SNP_RESERVED_BITS19_22 | \
MSR_AMD64_SNP_RESERVED_MASK)
#ifdef CONFIG_AMD_SECURE_AVIC
diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
index 9ae3b11754e6..13f608117411 100644
--- a/arch/x86/coco/sev/core.c
+++ b/arch/x86/coco/sev/core.c
@@ -122,6 +122,7 @@ static const char * const sev_status_feat_names[] = {
[MSR_AMD64_SNP_VMSA_REG_PROT_BIT] = "VMSARegProt",
[MSR_AMD64_SNP_SMT_PROT_BIT] = "SMTProt",
[MSR_AMD64_SNP_SECURE_AVIC_BIT] = "SecureAVIC",
+ [MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT] = "IBPBOnEntry",
};
/*
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 4d3566bb1a93..9016a6b00bc7 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -735,7 +735,10 @@
#define MSR_AMD64_SNP_SMT_PROT BIT_ULL(MSR_AMD64_SNP_SMT_PROT_BIT)
#define MSR_AMD64_SNP_SECURE_AVIC_BIT 18
#define MSR_AMD64_SNP_SECURE_AVIC BIT_ULL(MSR_AMD64_SNP_SECURE_AVIC_BIT)
-#define MSR_AMD64_SNP_RESV_BIT 19
+#define MSR_AMD64_SNP_RESERVED_BITS19_22 GENMASK_ULL(22, 19)
+#define MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT 23
+#define MSR_AMD64_SNP_IBPB_ON_ENTRY BIT_ULL(MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT)
+#define MSR_AMD64_SNP_RESV_BIT 24
#define MSR_AMD64_SNP_RESERVED_MASK GENMASK_ULL(63, MSR_AMD64_SNP_RESV_BIT)
#define MSR_AMD64_SAVIC_CONTROL 0xc0010138
#define MSR_AMD64_SAVIC_EN_BIT 0
--
2.43.0On Mon, Jan 26, 2026 at 04:42:04PM -0600, Kim Phillips wrote:
> The SEV-SNP IBPB-on-Entry feature does not require a guest-side
> implementation. The feature was added in Zen5 h/w, after the first
> SNP Zen implementation, and thus was not accounted for when the
> initial set of SNP features were added to the kernel.
>
> In its abundant precaution, commit 8c29f0165405 ("x86/sev: Add SEV-SNP
> guest feature negotiation support") included SEV_STATUS' IBPB-on-Entry
> bit as a reserved bit, thereby masking guests from using the feature.
>
> Unmask the bit, to allow guests to take advantage of the feature on
> hypervisor kernel versions that support it: Amend the SEV_STATUS MSR
> SNP_RESERVED_MASK to exclude bit 23 (IbpbOnEntry).
Do not explain what the patch does.
> Fixes: 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support")
> Cc: Nikunj A Dadhania <nikunj@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> CC: Borislav Petkov (AMD) <bp@alien8.de>
> CC: Michael Roth <michael.roth@amd.com>
> Cc: stable@kernel.org
I guess...
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 4d3566bb1a93..9016a6b00bc7 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -735,7 +735,10 @@
> #define MSR_AMD64_SNP_SMT_PROT BIT_ULL(MSR_AMD64_SNP_SMT_PROT_BIT)
> #define MSR_AMD64_SNP_SECURE_AVIC_BIT 18
> #define MSR_AMD64_SNP_SECURE_AVIC BIT_ULL(MSR_AMD64_SNP_SECURE_AVIC_BIT)
> -#define MSR_AMD64_SNP_RESV_BIT 19
> +#define MSR_AMD64_SNP_RESERVED_BITS19_22 GENMASK_ULL(22, 19)
> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT 23
> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY BIT_ULL(MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT)
Why isn't this part of SNP_FEATURES_PRESENT?
If this feature doesn't require guest-side support, then it is trivially
present, no?
> +#define MSR_AMD64_SNP_RESV_BIT 24
> #define MSR_AMD64_SNP_RESERVED_MASK GENMASK_ULL(63, MSR_AMD64_SNP_RESV_BIT)
> #define MSR_AMD64_SAVIC_CONTROL 0xc0010138
> #define MSR_AMD64_SAVIC_EN_BIT 0
> --
I guess this is a fix of sorts and I could take it in now once all review
comments have been addressed...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi Boris,
On 1/28/26 1:23 PM, Borislav Petkov wrote:
> On Mon, Jan 26, 2026 at 04:42:04PM -0600, Kim Phillips wrote:
>> The SEV-SNP IBPB-on-Entry feature does not require a guest-side
>> implementation. The feature was added in Zen5 h/w, after the first
>> SNP Zen implementation, and thus was not accounted for when the
>> initial set of SNP features were added to the kernel.
>>
>> In its abundant precaution, commit 8c29f0165405 ("x86/sev: Add SEV-SNP
>> guest feature negotiation support") included SEV_STATUS' IBPB-on-Entry
>> bit as a reserved bit, thereby masking guests from using the feature.
>>
>> Unmask the bit, to allow guests to take advantage of the feature on
>> hypervisor kernel versions that support it: Amend the SEV_STATUS MSR
>> SNP_RESERVED_MASK to exclude bit 23 (IbpbOnEntry).
> Do not explain what the patch does.
For that last paragraph, how about:
"Allow guests to make use of IBPB-on-Entry when supported by the
hypervisor, as the bit is now architecturally defined and safe to
expose."
?
>> Fixes: 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support")
>> Cc: Nikunj A Dadhania <nikunj@amd.com>
>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>> CC: Borislav Petkov (AMD) <bp@alien8.de>
>> CC: Michael Roth <michael.roth@amd.com>
>> Cc: stable@kernel.org
> I guess...
Hopefully a bitfield will be carved out for these
no-explicit-guest-implementation-required bits by hardware such that we
won't need to do this again.
>> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
>> index 4d3566bb1a93..9016a6b00bc7 100644
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -735,7 +735,10 @@
>> #define MSR_AMD64_SNP_SMT_PROT BIT_ULL(MSR_AMD64_SNP_SMT_PROT_BIT)
>> #define MSR_AMD64_SNP_SECURE_AVIC_BIT 18
>> #define MSR_AMD64_SNP_SECURE_AVIC BIT_ULL(MSR_AMD64_SNP_SECURE_AVIC_BIT)
>> -#define MSR_AMD64_SNP_RESV_BIT 19
>> +#define MSR_AMD64_SNP_RESERVED_BITS19_22 GENMASK_ULL(22, 19)
>> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT 23
>> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY BIT_ULL(MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT)
> Why isn't this part of SNP_FEATURES_PRESENT?
>
> If this feature doesn't require guest-side support, then it is trivially
> present, no?
SNP_FEATURES_PRESENT is for the non-trivial variety: Its bits get set as
part of the patchseries that add the explicit guest support *code*.
I believe 'features' like PREVENT_HOST_IBS are similar in this regard.
>> +#define MSR_AMD64_SNP_RESV_BIT 24
>> #define MSR_AMD64_SNP_RESERVED_MASK GENMASK_ULL(63, MSR_AMD64_SNP_RESV_BIT)
>> #define MSR_AMD64_SAVIC_CONTROL 0xc0010138
>> #define MSR_AMD64_SAVIC_EN_BIT 0
>> --
> I guess this is a fix of sorts and I could take it in now once all review
> comments have been addressed...
Cool, thanks.
Kim
On Wed, Jan 28, 2026 at 06:38:29PM -0600, Kim Phillips wrote:
> For that last paragraph, how about:
>
> "Allow guests to make use of IBPB-on-Entry when supported by the
> hypervisor, as the bit is now architecturally defined and safe to
> expose."
Better.
> SNP_FEATURES_PRESENT is for the non-trivial variety: Its bits get set as
> part of the patchseries that add the explicit guest support *code*.
Yes, and I'm asking why can't SNP_FEATURES_PRESENT contain *all* SNP features?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 1/29/26 4:51 AM, Borislav Petkov wrote: > On Wed, Jan 28, 2026 at 06:38:29PM -0600, Kim Phillips wrote: >> SNP_FEATURES_PRESENT is for the non-trivial variety: Its bits get set as >> part of the patchseries that add the explicit guest support *code*. > Yes, and I'm asking why can't SNP_FEATURES_PRESENT contain *all* SNP features? Not *all* SNP features are implemented in all guest kernel versions, and, well, for those that don't require explicit guest code support, perhaps it's because they aren't necessarily well defined and validated in all hardware versions... Kim
On Thu, Jan 29, 2026 at 04:32:49PM -0600, Kim Phillips wrote:
> Not *all* SNP features are implemented in all guest kernel versions, and,
> well, for those that don't require explicit guest code support, perhaps it's
> because they aren't necessarily well defined and validated in all hardware
> versions...
Ok, can you add *this* feature to SNP_FEATURES_PRESENT? If not, why not?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 1/30/26 06:32, Borislav Petkov wrote: > On Thu, Jan 29, 2026 at 04:32:49PM -0600, Kim Phillips wrote: >> Not *all* SNP features are implemented in all guest kernel versions, and, >> well, for those that don't require explicit guest code support, perhaps it's >> because they aren't necessarily well defined and validated in all hardware >> versions... > > Ok, can you add *this* feature to SNP_FEATURES_PRESENT? If not, why not? It can be added. Any of the features added to SNP_FEATURES_PRESENT that aren't set in the SNP_FEATURES_IMPL_REQ bitmap are really a no-op. The SNP_FEATURES_PRESENT bitmap is meant to contain whatever bits are set in SNP_FEATURES_IMPL_REQ when an implementation has been implemented for the guest. But, yeah, we could add all the bits that aren't set in SNP_FEATURES_IMPL_REQ to SNP_FEATURES_PRESENT if it makes it clearer. If we do that, it should probably be a separate patch (?) that also rewords the comment above SNP_FEATURES_PRESENT Thanks, Tom >
On Fri, Jan 30, 2026 at 08:56:07AM -0600, Tom Lendacky wrote:
> It can be added. Any of the features added to SNP_FEATURES_PRESENT that
> aren't set in the SNP_FEATURES_IMPL_REQ bitmap are really a no-op. The
> SNP_FEATURES_PRESENT bitmap is meant to contain whatever bits are set in
> SNP_FEATURES_IMPL_REQ when an implementation has been implemented for the
> guest.
>
> But, yeah, we could add all the bits that aren't set in
> SNP_FEATURES_IMPL_REQ to SNP_FEATURES_PRESENT if it makes it clearer.
Right, that's the question. SNP_FEATURES_PRESENT is used in the masking
operation to get the unsupported features.
But when we say a SNP feature is present, then, even if it doesn't need guest
implementation, that feature is still present nonetheless.
So our nomenclature is kinda imprecise here.
I'd say, we can always rename SNP_FEATURES_PRESENT to denote what it is there
for, i.e., the narrower functionality of the masking.
Or, if we want to gather there *all* features that are present, then we can
start adding them...
> If we do that, it should probably be a separate patch (?) that also
> rewords the comment above SNP_FEATURES_PRESENT
... yes, as a separate patch.
Question is, what do we really wanna do here?
Does it make sense and is it useful to have SNP_FEATURES_PRESENT contain *all*
guest SNP features...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 1/30/26 09:45, Borislav Petkov wrote: > On Fri, Jan 30, 2026 at 08:56:07AM -0600, Tom Lendacky wrote: >> It can be added. Any of the features added to SNP_FEATURES_PRESENT that >> aren't set in the SNP_FEATURES_IMPL_REQ bitmap are really a no-op. The >> SNP_FEATURES_PRESENT bitmap is meant to contain whatever bits are set in >> SNP_FEATURES_IMPL_REQ when an implementation has been implemented for the >> guest. >> >> But, yeah, we could add all the bits that aren't set in >> SNP_FEATURES_IMPL_REQ to SNP_FEATURES_PRESENT if it makes it clearer. > > Right, that's the question. SNP_FEATURES_PRESENT is used in the masking > operation to get the unsupported features. > > But when we say a SNP feature is present, then, even if it doesn't need guest > implementation, that feature is still present nonetheless. > > So our nomenclature is kinda imprecise here. > > I'd say, we can always rename SNP_FEATURES_PRESENT to denote what it is there > for, i.e., the narrower functionality of the masking. > > Or, if we want to gather there *all* features that are present, then we can > start adding them... > >> If we do that, it should probably be a separate patch (?) that also >> rewords the comment above SNP_FEATURES_PRESENT > > ... yes, as a separate patch. > > Question is, what do we really wanna do here? > > Does it make sense and is it useful to have SNP_FEATURES_PRESENT contain *all* > guest SNP features... I guess it really depends on the persons point of view. I agree that renaming the SNP_FEATURES_PRESENT to SNP_FEATURES_IMPL(EMENTED) would match up nicely with SNP_FEATURES_IMPL_REQ. Maybe that's all that is needed... Thanks, Tom > > Thx. >
On Mon, Feb 02, 2026 at 09:38:50AM -0600, Tom Lendacky wrote:
> I guess it really depends on the persons point of view. I agree that
> renaming the SNP_FEATURES_PRESENT to SNP_FEATURES_IMPL(EMENTED) would
> match up nicely with SNP_FEATURES_IMPL_REQ. Maybe that's all that is
> needed...
I guess...
I still think it would be useful to have a common place that says which things
in SEV_STATUS are supported and present in a guest, no?
Or are we going to dump that MSR like Joerg's patch from a while ago and
that'll tell us what the guest supports?
Hmm.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2/2/26 09:49, Borislav Petkov wrote: > On Mon, Feb 02, 2026 at 09:38:50AM -0600, Tom Lendacky wrote: >> I guess it really depends on the persons point of view. I agree that >> renaming the SNP_FEATURES_PRESENT to SNP_FEATURES_IMPL(EMENTED) would >> match up nicely with SNP_FEATURES_IMPL_REQ. Maybe that's all that is >> needed... > > I guess... > > I still think it would be useful to have a common place that says which things > in SEV_STATUS are supported and present in a guest, no? But I can see that getting stale because it isn't required to be updated for features that don't require an implementation in order for the guest to boot successfully. Whereas the SNP_FEATURES_IMPL_REQ is set with known values that require an implementation and all the reserved bits set. So it takes actual updating to get one of those features to work that are represented in that bitmap. > > Or are we going to dump that MSR like Joerg's patch from a while ago and > that'll tell us what the guest supports? That will tell us what the guest is running with, not what it can run with. Thanks, Tom > > Hmm. >
On Mon, Feb 02, 2026 at 10:09:19AM -0600, Tom Lendacky wrote:
> But I can see that getting stale because it isn't required to be updated
> for features that don't require an implementation in order for the guest
> to boot successfully. Whereas the SNP_FEATURES_IMPL_REQ is set with
> known values that require an implementation and all the reserved bits
> set. So it takes actual updating to get one of those features to work
> that are represented in that bitmap.
Ok, I guess we can rename that define SNP_FEATURES_IMPL to denote is the
counterpart of SNP_FEATURES_IMPL_REQ, so to speak.
@Kim, you can send a new version with the define renamed.
Due to it being too close to the merge window, it'll wait for after and then
it can go to stable later but I don't think that's a problem.
> That will tell us what the guest is running with, not what it can run with.
hm, ok, let's think about this more then. I don't have a clear use case for
a this-is-what-a-SNP-guest-can-run-with so let's deal with that later...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 1/26/26 16:42, Kim Phillips wrote:
> The SEV-SNP IBPB-on-Entry feature does not require a guest-side
> implementation. The feature was added in Zen5 h/w, after the first
> SNP Zen implementation, and thus was not accounted for when the
> initial set of SNP features were added to the kernel.
>
> In its abundant precaution, commit 8c29f0165405 ("x86/sev: Add SEV-SNP
> guest feature negotiation support") included SEV_STATUS' IBPB-on-Entry
> bit as a reserved bit, thereby masking guests from using the feature.
>
> Unmask the bit, to allow guests to take advantage of the feature on
> hypervisor kernel versions that support it: Amend the SEV_STATUS MSR
> SNP_RESERVED_MASK to exclude bit 23 (IbpbOnEntry).
>
> Fixes: 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support")
> Cc: Nikunj A Dadhania <nikunj@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> CC: Borislav Petkov (AMD) <bp@alien8.de>
> CC: Michael Roth <michael.roth@amd.com>
> Cc: stable@kernel.org
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>
With the change to the subject line...
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/boot/compressed/sev.c | 1 +
> arch/x86/coco/sev/core.c | 1 +
> arch/x86/include/asm/msr-index.h | 5 ++++-
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index c8c1464b3a56..2b639703b8dd 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -188,6 +188,7 @@ bool sev_es_check_ghcb_fault(unsigned long address)
> MSR_AMD64_SNP_RESERVED_BIT13 | \
> MSR_AMD64_SNP_RESERVED_BIT15 | \
> MSR_AMD64_SNP_SECURE_AVIC | \
> + MSR_AMD64_SNP_RESERVED_BITS19_22 | \
> MSR_AMD64_SNP_RESERVED_MASK)
>
> #ifdef CONFIG_AMD_SECURE_AVIC
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index 9ae3b11754e6..13f608117411 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -122,6 +122,7 @@ static const char * const sev_status_feat_names[] = {
> [MSR_AMD64_SNP_VMSA_REG_PROT_BIT] = "VMSARegProt",
> [MSR_AMD64_SNP_SMT_PROT_BIT] = "SMTProt",
> [MSR_AMD64_SNP_SECURE_AVIC_BIT] = "SecureAVIC",
> + [MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT] = "IBPBOnEntry",
> };
>
> /*
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 4d3566bb1a93..9016a6b00bc7 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -735,7 +735,10 @@
> #define MSR_AMD64_SNP_SMT_PROT BIT_ULL(MSR_AMD64_SNP_SMT_PROT_BIT)
> #define MSR_AMD64_SNP_SECURE_AVIC_BIT 18
> #define MSR_AMD64_SNP_SECURE_AVIC BIT_ULL(MSR_AMD64_SNP_SECURE_AVIC_BIT)
> -#define MSR_AMD64_SNP_RESV_BIT 19
> +#define MSR_AMD64_SNP_RESERVED_BITS19_22 GENMASK_ULL(22, 19)
> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT 23
> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY BIT_ULL(MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT)
> +#define MSR_AMD64_SNP_RESV_BIT 24
> #define MSR_AMD64_SNP_RESERVED_MASK GENMASK_ULL(63, MSR_AMD64_SNP_RESV_BIT)
> #define MSR_AMD64_SAVIC_CONTROL 0xc0010138
> #define MSR_AMD64_SAVIC_EN_BIT 0
On 1/27/2026 4:12 AM, Kim Phillips wrote:
> KVM: SEV: IBPB-on-Entry guest support
The subject line should have the prefix "x86/sev" instead
of "KVM: SEV". The below subject line would be more appropriate:
x86/sev: Allow IBPB-on-Entry feature for SNP guests
> The SEV-SNP IBPB-on-Entry feature does not require a guest-side
> implementation. The feature was added in Zen5 h/w, after the first
> SNP Zen implementation, and thus was not accounted for when the
> initial set of SNP features were added to the kernel.
>
> In its abundant precaution, commit 8c29f0165405 ("x86/sev: Add SEV-SNP
> guest feature negotiation support") included SEV_STATUS' IBPB-on-Entry
> bit as a reserved bit, thereby masking guests from using the feature.
>
> Unmask the bit, to allow guests to take advantage of the feature on
> hypervisor kernel versions that support it: Amend the SEV_STATUS MSR
> SNP_RESERVED_MASK to exclude bit 23 (IbpbOnEntry).
>
> Fixes: 8c29f0165405 ("x86/sev: Add SEV-SNP guest feature negotiation support")> Cc: Nikunj A Dadhania <nikunj@amd.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> CC: Borislav Petkov (AMD) <bp@alien8.de>
> CC: Michael Roth <michael.roth@amd.com>
> Cc: stable@kernel.org
> Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Apart from the above comments:
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
> ---
> arch/x86/boot/compressed/sev.c | 1 +
> arch/x86/coco/sev/core.c | 1 +
> arch/x86/include/asm/msr-index.h | 5 ++++-
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index c8c1464b3a56..2b639703b8dd 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -188,6 +188,7 @@ bool sev_es_check_ghcb_fault(unsigned long address)
> MSR_AMD64_SNP_RESERVED_BIT13 | \
> MSR_AMD64_SNP_RESERVED_BIT15 | \
> MSR_AMD64_SNP_SECURE_AVIC | \
> + MSR_AMD64_SNP_RESERVED_BITS19_22 | \
> MSR_AMD64_SNP_RESERVED_MASK)
>
> #ifdef CONFIG_AMD_SECURE_AVIC
> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
> index 9ae3b11754e6..13f608117411 100644
> --- a/arch/x86/coco/sev/core.c
> +++ b/arch/x86/coco/sev/core.c
> @@ -122,6 +122,7 @@ static const char * const sev_status_feat_names[] = {
> [MSR_AMD64_SNP_VMSA_REG_PROT_BIT] = "VMSARegProt",
> [MSR_AMD64_SNP_SMT_PROT_BIT] = "SMTProt",
> [MSR_AMD64_SNP_SECURE_AVIC_BIT] = "SecureAVIC",
> + [MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT] = "IBPBOnEntry",
> };
>
> /*
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 4d3566bb1a93..9016a6b00bc7 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -735,7 +735,10 @@
> #define MSR_AMD64_SNP_SMT_PROT BIT_ULL(MSR_AMD64_SNP_SMT_PROT_BIT)
> #define MSR_AMD64_SNP_SECURE_AVIC_BIT 18
> #define MSR_AMD64_SNP_SECURE_AVIC BIT_ULL(MSR_AMD64_SNP_SECURE_AVIC_BIT)
> -#define MSR_AMD64_SNP_RESV_BIT 19
> +#define MSR_AMD64_SNP_RESERVED_BITS19_22 GENMASK_ULL(22, 19)
> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT 23
> +#define MSR_AMD64_SNP_IBPB_ON_ENTRY BIT_ULL(MSR_AMD64_SNP_IBPB_ON_ENTRY_BIT)
> +#define MSR_AMD64_SNP_RESV_BIT 24
> #define MSR_AMD64_SNP_RESERVED_MASK GENMASK_ULL(63, MSR_AMD64_SNP_RESV_BIT)
> #define MSR_AMD64_SAVIC_CONTROL 0xc0010138
> #define MSR_AMD64_SAVIC_EN_BIT 0
© 2016 - 2026 Red Hat, Inc.