[PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Sean Rhodes]

Some AMD systems return from S3 with the boot CPU CPUID leaf 7
override MSR reset. On Byte/Cezanne, CPUID leaf 7 EBX becomes
0x219c9fb9 on CPU0 after S3 even though XTEST still raises #UD.
Userspace can then select RTM-optimised glibc paths and fault after
resume.

The x86 suspend code already has a small MSR save/restore list for
firmware-modified MSRs and restores it after resume microcode has been
loaded. Add MSR_AMD64_CPUID_FN_7 for the AMD families that can modify
this MSR during CPU init so the pre-suspend CPUID mask is restored
before tasks are thawed.

This covers family 17h, 19h, and 1Ah: family 17h has the Cyan Skillfish
RDSEED leaf-7 quirk, family 19h covers the observed Cezanne issue, and
family 1Ah has the Zen5 RDSEED leaf-7 quirk.

Tested on StarBook Mk V (Byte/Cezanne, 26.07 firmware):
- without this restore, dmesg showed "ACPI: PM: Low-level resume complete"
  and "PM: suspend exit"; the post-S3 CPUID probe showed CPU0 leaf 7 EBX
  0x219c9fb9 with hle=1 rtm=1 while XTEST still raised #UD.
- a temporary PM resume hook clearing the same MSR logged
  "CPU0 MSR_AMD64_CPUID_FN_7 0x219c9fb9 -> 0x219c97a9"; the post-S3 probe
  showed hle=0 rtm=0 on all CPUs.
- this patch booted on Byte and registered the MSR save path; dmesg showed
  "x86/pm: AMD family 0x19 CPU detected"; pm_test freezer/devices/platform/
  processors/core passed with the same boot ID.

Tested-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
---
 arch/x86/power/cpu.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 702f30eaf9c4..b85061f4cee4 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -467,9 +467,24 @@ static int msr_save_cpuid_features(const struct x86_cpu_id *c)
 	return msr_build_context(cpuid_msr_id, ARRAY_SIZE(cpuid_msr_id));
 }
 
+static int msr_save_amd_leaf7_cpuid_features(const struct x86_cpu_id *c)
+{
+	u32 cpuid_msr_id[] = {
+		MSR_AMD64_CPUID_FN_7,
+	};
+
+	pr_info("x86/pm: AMD family %#x CPU detected, saving CPUID leaf 7 MSR across suspend.\n",
+		c->family);
+
+	return msr_build_context(cpuid_msr_id, ARRAY_SIZE(cpuid_msr_id));
+}
+
 static const struct x86_cpu_id msr_save_cpu_table[] = {
 	X86_MATCH_VENDOR_FAM(AMD, 0x15, &msr_save_cpuid_features),
 	X86_MATCH_VENDOR_FAM(AMD, 0x16, &msr_save_cpuid_features),
+	X86_MATCH_VENDOR_FAM(AMD, 0x17, &msr_save_amd_leaf7_cpuid_features),
+	X86_MATCH_VENDOR_FAM(AMD, 0x19, &msr_save_amd_leaf7_cpuid_features),
+	X86_MATCH_VENDOR_FAM(AMD, 0x1a, &msr_save_amd_leaf7_cpuid_features),
 	{}
 };
 

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Borislav Petkov]

+ Mario.

On Tue, Aug 04, 2026 at 11:13:41AM +0100, Sean Rhodes wrote:
> Some AMD systems return from S3 with the boot CPU CPUID leaf 7
> override MSR reset. On Byte/Cezanne, CPUID leaf 7 EBX becomes
> 0x219c9fb9 on CPU0 after S3 even though XTEST still raises #UD.
> Userspace can then select RTM-optimised glibc paths and fault after
> resume.

Do you have the latest BIOS on that machine?

> The x86 suspend code already has a small MSR save/restore list for
> firmware-modified MSRs and restores it after resume microcode has been
> loaded. Add MSR_AMD64_CPUID_FN_7 for the AMD families that can modify
> this MSR during CPU init so the pre-suspend CPUID mask is restored
> before tasks are thawed.
> 
> This covers family 17h, 19h, and 1Ah:

Why?

> family 17h has the Cyan Skillfish
> RDSEED leaf-7 quirk, family 19h covers the observed Cezanne issue, and
> family 1Ah has the Zen5 RDSEED leaf-7 quirk.

Those RDSEED quirks need more details as to why they need to be applied here.

> Tested on StarBook Mk V (Byte/Cezanne, 26.07 firmware):
> - without this restore, dmesg showed "ACPI: PM: Low-level resume complete"
>   and "PM: suspend exit"; the post-S3 CPUID probe showed CPU0 leaf 7 EBX
>   0x219c9fb9 with hle=1 rtm=1 while XTEST still raised #UD.
> - a temporary PM resume hook clearing the same MSR logged
>   "CPU0 MSR_AMD64_CPUID_FN_7 0x219c9fb9 -> 0x219c97a9"; the post-S3 probe
>   showed hle=0 rtm=0 on all CPUs.
> - this patch booted on Byte and registered the MSR save path; dmesg showed
>   "x86/pm: AMD family 0x19 CPU detected"; pm_test freezer/devices/platform/
>   processors/core passed with the same boot ID.

For future patches: testing goes...

> 
> Tested-by: Sean Rhodes <sean@starlabs.systems>
> Signed-off-by: Sean Rhodes <sean@starlabs.systems>
> ---

<-- here, under that line.

>  arch/x86/power/cpu.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> index 702f30eaf9c4..b85061f4cee4 100644
> --- a/arch/x86/power/cpu.c
> +++ b/arch/x86/power/cpu.c
> @@ -467,9 +467,24 @@ static int msr_save_cpuid_features(const struct x86_cpu_id *c)
>  	return msr_build_context(cpuid_msr_id, ARRAY_SIZE(cpuid_msr_id));
>  }
>  
> +static int msr_save_amd_leaf7_cpuid_features(const struct x86_cpu_id *c)
> +{
> +	u32 cpuid_msr_id[] = {
> +		MSR_AMD64_CPUID_FN_7,
> +	};
> +
> +	pr_info("x86/pm: AMD family %#x CPU detected, saving CPUID leaf 7 MSR across suspend.\n",

I guess pr_info_once() is fine here.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Sean Rhodes]

On Tue, 4 Aug 2026 at 19:49, Borislav Petkov <bp@alien8.de> wrote:
>
> + Mario.
>
> On Tue, Aug 04, 2026 at 11:13:41AM +0100, Sean Rhodes wrote:
> > Some AMD systems return from S3 with the boot CPU CPUID leaf 7
> > override MSR reset. On Byte/Cezanne, CPUID leaf 7 EBX becomes
> > 0x219c9fb9 on CPU0 after S3 even though XTEST still raises #UD.
> > Userspace can then select RTM-optimised glibc paths and fault after
> > resume.
>
> Do you have the latest BIOS on that machine?

If you're saying that because there might be a firmware solution, I am
all ears, but this issue is present with AMI CRB and coreboot+FSP -
hit a wall trying to fix it there.

>
> > The x86 suspend code already has a small MSR save/restore list for
> > firmware-modified MSRs and restores it after resume microcode has been
> > loaded. Add MSR_AMD64_CPUID_FN_7 for the AMD families that can modify
> > this MSR during CPU init so the pre-suspend CPUID mask is restored
> > before tasks are thawed.
> >
> > This covers family 17h, 19h, and 1Ah:
>
> Why?

Why not?

>
> > family 17h has the Cyan Skillfish
> > RDSEED leaf-7 quirk, family 19h covers the observed Cezanne issue, and
> > family 1Ah has the Zen5 RDSEED leaf-7 quirk.
>
> Those RDSEED quirks need more details as to why they need to be applied here.
>
> > Tested on StarBook Mk V (Byte/Cezanne, 26.07 firmware):
> > - without this restore, dmesg showed "ACPI: PM: Low-level resume complete"
> >   and "PM: suspend exit"; the post-S3 CPUID probe showed CPU0 leaf 7 EBX
> >   0x219c9fb9 with hle=1 rtm=1 while XTEST still raised #UD.
> > - a temporary PM resume hook clearing the same MSR logged
> >   "CPU0 MSR_AMD64_CPUID_FN_7 0x219c9fb9 -> 0x219c97a9"; the post-S3 probe
> >   showed hle=0 rtm=0 on all CPUs.
> > - this patch booted on Byte and registered the MSR save path; dmesg showed
> >   "x86/pm: AMD family 0x19 CPU detected"; pm_test freezer/devices/platform/
> >   processors/core passed with the same boot ID.
>
> For future patches: testing goes...

Ack :)

>
> >
> > Tested-by: Sean Rhodes <sean@starlabs.systems>
> > Signed-off-by: Sean Rhodes <sean@starlabs.systems>
> > ---
>
> <-- here, under that line.
>
> >  arch/x86/power/cpu.c | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> > index 702f30eaf9c4..b85061f4cee4 100644
> > --- a/arch/x86/power/cpu.c
> > +++ b/arch/x86/power/cpu.c
> > @@ -467,9 +467,24 @@ static int msr_save_cpuid_features(const struct x86_cpu_id *c)
> >       return msr_build_context(cpuid_msr_id, ARRAY_SIZE(cpuid_msr_id));
> >  }
> >
> > +static int msr_save_amd_leaf7_cpuid_features(const struct x86_cpu_id *c)
> > +{
> > +     u32 cpuid_msr_id[] = {
> > +             MSR_AMD64_CPUID_FN_7,
> > +     };
> > +
> > +     pr_info("x86/pm: AMD family %#x CPU detected, saving CPUID leaf 7 MSR across suspend.\n",
>
> I guess pr_info_once() is fine here.
>
> Thx.
>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Borislav Petkov]

On Tue, Aug 04, 2026 at 08:22:36PM +0100, Sean Rhodes wrote:
> If you're saying that because there might be a firmware solution, I am
> all ears, but this issue is present with AMI CRB and coreboot+FSP -
> hit a wall trying to fix it there.

I'm making sure you're using the latest one which might potentially have
a fix...

> Why not?

Because we're not fixing three things with one patch and without a proper
justification for the other two.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Mario Limonciello]

On 8/5/26 20:29, Borislav Petkov wrote:
> On Tue, Aug 04, 2026 at 08:22:36PM +0100, Sean Rhodes wrote:
>> If you're saying that because there might be a firmware solution, I am
>> all ears, but this issue is present with AMI CRB and coreboot+FSP -
>> hit a wall trying to fix it there.
> 

Does this only happen in coreboot + FSP?  Or it also happens in latest UEFI?

Does it only happen in S3 or also S0i3?
How about S4?

> I'm making sure you're using the latest one which might potentially have
> a fix...
> 
>> Why not?
> 
> Because we're not fixing three things with one patch and without a proper
> justification for the other two.
> 

I would expect the restore of this register to be the platform 
firmware's responsibility.

I don't know right now if this a BIOS bug, an suspend/resume bug, or how 
wide of an impact it is.

Your fix might make sense for "this single platform", but we don't have 
any evidence it's needed for any other one just yet.

We shouldn't make changes because there "might" be a problem.  We need 
affirmation from testing or an assertion from the BIOS team.

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Sean Rhodes]

On Mon, 10 Aug 2026 at 19:31, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 8/5/26 20:29, Borislav Petkov wrote:
> > On Tue, Aug 04, 2026 at 08:22:36PM +0100, Sean Rhodes wrote:
> >> If you're saying that because there might be a firmware solution, I am
> >> all ears, but this issue is present with AMI CRB and coreboot+FSP -
> >> hit a wall trying to fix it there.
> >
>
> Does this only happen in coreboot + FSP?  Or it also happens in latest UEFI?

Also UEFI

>
> Does it only happen in S3 or also S0i3?
> How about S4?

Only S3

>
> > I'm making sure you're using the latest one which might potentially have
> > a fix...
> >
> >> Why not?
> >
> > Because we're not fixing three things with one patch and without a proper
> > justification for the other two.
> >
>
> I would expect the restore of this register to be the platform
> firmware's responsibility.
>
> I don't know right now if this a BIOS bug, an suspend/resume bug, or how
> wide of an impact it is.
>
> Your fix might make sense for "this single platform", but we don't have
> any evidence it's needed for any other one just yet.
>
> We shouldn't make changes because there "might" be a problem.  We need
> affirmation from testing or an assertion from the BIOS team.

Ack

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Mario Limonciello]

On 8/10/26 14:42, Sean Rhodes wrote:
> On Mon, 10 Aug 2026 at 19:31, Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>
>>
>> On 8/5/26 20:29, Borislav Petkov wrote:
>>> On Tue, Aug 04, 2026 at 08:22:36PM +0100, Sean Rhodes wrote:
>>>> If you're saying that because there might be a firmware solution, I am
>>>> all ears, but this issue is present with AMI CRB and coreboot+FSP -
>>>> hit a wall trying to fix it there.
>>>
>>
>> Does this only happen in coreboot + FSP?  Or it also happens in latest UEFI?
> 
> Also UEFI

Can you confirm the version you tested?  Is it the latest one?

> 
>>
>> Does it only happen in S3 or also S0i3?
>> How about S4?
> 
> Only S3

OK if it's only S3 it's unlikely that this problem exists on the newer 
systems.  They have switched to only supporting S0i3.

I think you should narrow down your proposed quirk to the single 
affected processor.

> 
>>
>>> I'm making sure you're using the latest one which might potentially have
>>> a fix...
>>>
>>>> Why not?
>>>
>>> Because we're not fixing three things with one patch and without a proper
>>> justification for the other two.
>>>
>>
>> I would expect the restore of this register to be the platform
>> firmware's responsibility.
>>
>> I don't know right now if this a BIOS bug, an suspend/resume bug, or how
>> wide of an impact it is.
>>
>> Your fix might make sense for "this single platform", but we don't have
>> any evidence it's needed for any other one just yet.
>>
>> We shouldn't make changes because there "might" be a problem.  We need
>> affirmation from testing or an assertion from the BIOS team.
> 
> Ack

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Borislav Petkov]

On Mon, Aug 10, 2026 at 03:07:05PM -0500, Mario Limonciello wrote:
> I think you should narrow down your proposed quirk to the single affected
> processor.

You mean "platform"?

Looking at
https://us.starlabs.systems/pages/starbook?shpxid=c61652d7-d0de-458c-a7ee-ce809ee0ad2b
it sounds to me like we might fix the fw even...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Mario Limonciello]

On 8/10/26 16:33, Borislav Petkov wrote:
> On Mon, Aug 10, 2026 at 03:07:05PM -0500, Mario Limonciello wrote:
>> I think you should narrow down your proposed quirk to the single affected
>> processor.
> 
> You mean "platform"?
> 

Well the fact that they could also reproduce it on the CRB with UEFI and 
the latest firmware tells me it's most likely any system with this SoC 
and using S3 for suspend is affected.

> Looking at
> https://us.starlabs.systems/pages/starbook?shpxid=c61652d7-d0de-458c-a7ee-ce809ee0ad2b
> it sounds to me like we might fix the fw even...
> 

I guess the same thing might be doable in coreboot ASL handlers for S3, 
but I don't know how well that would go over with coreboot folks.

They might say "It should be fixed in FSP" or "It's the kernel's problem".

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Borislav Petkov]

On Tue, Aug 11, 2026 at 01:25:27PM -0500, Mario Limonciello wrote:
> Well the fact that they could also reproduce it on the CRB with UEFI and the
> latest firmware tells me it's most likely any system with this SoC and using
> S3 for suspend is affected.

So S3 is the problem...

> I guess the same thing might be doable in coreboot ASL handlers for S3, but
> I don't know how well that would go over with coreboot folks.
> 
> They might say "It should be fixed in FSP" or "It's the kernel's problem".

Definitely not the kernel's problem. The kernel gets to fix all the shit all
the others broke.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[Mario Limonciello]

On 8/11/26 13:40, Borislav Petkov wrote:
> On Tue, Aug 11, 2026 at 01:25:27PM -0500, Mario Limonciello wrote:
>> Well the fact that they could also reproduce it on the CRB with UEFI and the
>> latest firmware tells me it's most likely any system with this SoC and using
>> S3 for suspend is affected.
> 
> So S3 is the problem...
> 
>> I guess the same thing might be doable in coreboot ASL handlers for S3, but
>> I don't know how well that would go over with coreboot folks.
>>
>> They might say "It should be fixed in FSP" or "It's the kernel's problem".
> 
> Definitely not the kernel's problem. The kernel gets to fix all the shit all
> the others broke.
> 

Sean - Can you move your system to s0i3?  If not, I suggest you draft a 
coreboot ASL change for S3 handlers, and see how it looks.

Re: [PATCH] x86/pm: Save AMD CPUID leaf 7 across S3

[David Laight]

On Tue, 4 Aug 2026 11:49:20 -0700
Borislav Petkov <bp@alien8.de> wrote:

> + Mario.
> 
> On Tue, Aug 04, 2026 at 11:13:41AM +0100, Sean Rhodes wrote:
> > Some AMD systems return from S3 with the boot CPU CPUID leaf 7
> > override MSR reset. On Byte/Cezanne, CPUID leaf 7 EBX becomes
> > 0x219c9fb9 on CPU0 after S3 even though XTEST still raises #UD.
> > Userspace can then select RTM-optimised glibc paths and fault after
> > resume.  
> 
> Do you have the latest BIOS on that machine?
> 
> > The x86 suspend code already has a small MSR save/restore list for
> > firmware-modified MSRs and restores it after resume microcode has been
> > loaded. Add MSR_AMD64_CPUID_FN_7 for the AMD families that can modify
> > this MSR during CPU init so the pre-suspend CPUID mask is restored
> > before tasks are thawed.
> > 
> > This covers family 17h, 19h, and 1Ah:  
> 
> Why?
> 
> > family 17h has the Cyan Skillfish
> > RDSEED leaf-7 quirk, family 19h covers the observed Cezanne issue, and
> > family 1Ah has the Zen5 RDSEED leaf-7 quirk.  
> 
> Those RDSEED quirks need more details as to why they need to be applied here.
> 
> > Tested on StarBook Mk V (Byte/Cezanne, 26.07 firmware):
> > - without this restore, dmesg showed "ACPI: PM: Low-level resume complete"
> >   and "PM: suspend exit"; the post-S3 CPUID probe showed CPU0 leaf 7 EBX
> >   0x219c9fb9 with hle=1 rtm=1 while XTEST still raised #UD.
> > - a temporary PM resume hook clearing the same MSR logged
> >   "CPU0 MSR_AMD64_CPUID_FN_7 0x219c9fb9 -> 0x219c97a9"; the post-S3 probe
> >   showed hle=0 rtm=0 on all CPUs.
> > - this patch booted on Byte and registered the MSR save path; dmesg showed
> >   "x86/pm: AMD family 0x19 CPU detected"; pm_test freezer/devices/platform/
> >   processors/core passed with the same boot ID.  
> 
> For future patches: testing goes...
> 
> > 
> > Tested-by: Sean Rhodes <sean@starlabs.systems>
> > Signed-off-by: Sean Rhodes <sean@starlabs.systems>
> > ---  
> 
> <-- here, under that line.
> 
> >  arch/x86/power/cpu.c | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
> > index 702f30eaf9c4..b85061f4cee4 100644
> > --- a/arch/x86/power/cpu.c
> > +++ b/arch/x86/power/cpu.c
> > @@ -467,9 +467,24 @@ static int msr_save_cpuid_features(const struct x86_cpu_id *c)
> >  	return msr_build_context(cpuid_msr_id, ARRAY_SIZE(cpuid_msr_id));
> >  }
> >  
> > +static int msr_save_amd_leaf7_cpuid_features(const struct x86_cpu_id *c)
> > +{
> > +	u32 cpuid_msr_id[] = {
> > +		MSR_AMD64_CPUID_FN_7,
> > +	};
> > +
> > +	pr_info("x86/pm: AMD family %#x CPU detected, saving CPUID leaf 7 MSR across suspend.\n",  
> 
> I guess pr_info_once() is fine here.

Would be more informative in the restore path if the value is wrong.

	David

> 
> Thx.
>