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

On Tue, 4 Aug 2026 at 19:49, Borislav Petkov <[email protected]> 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 <[email protected]>
> > Signed-off-by: Sean Rhodes <[email protected]>
> > ---
>
> <-- 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