[AMD Official Use Only - General]
Hi Oleksandr:
> -----Original Message-----
> From: Oleksandr Natalenko <[email protected]>
> Sent: Wednesday, July 13, 2022 1:40 AM
> To: Limonciello, Mario <[email protected]>; linux-
> [email protected]
> Cc: Yuan, Perry <[email protected]>; Rafael J. Wysocki
> <[email protected]>; Sasha Levin <[email protected]>;
> [email protected]; H. Peter Anvin <[email protected]>; Greg Kroah-Hartman
> <[email protected]>
> Subject: [REGRESSION] amd-pstate doesn't work since v5.18.11
>
> [CAUTION: External Email]
>
> Hello Mario.
>
> The following commits were pulled into v5.18.11:
>
> ```
> $ git log --oneline --no-merges v5.18.10..v5.18.11 | grep ACPI
> 2783414e6ef7 ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is
> supported
> 3068cfeca3b5 ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
> 8beb71759cc8 ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is
> supported
> 13bb696dd2f3 ACPI: CPPC: Check _OSC for flexible address space ```
>
> and now this happens:
>
> ```
> $ sudo modprobe amd-pstate shared_mem=1
> modprobe: ERROR: could not insert 'amd_pstate': No such device ```
>
> With v5.18.10 this worked just fine.
>
> In your upstream commit 8b356e536e69f3a4d6778ae9f0858a1beadabb1f
> you write:
>
> ```
> If there is additional breakage on the shared memory designs also missing
> this _OSC, additional follow up changes may be needed.
> ```
>
> So the question is what else should be pulled into the stable tree to
> unbreak amd-pstate?
>
> Thanks.
>
> --
> Oleksandr Natalenko (post-factum)
>
Could you share the lscpu output ?
Perry.
[Public]
+ Ray
> -----Original Message-----
> From: Yuan, Perry <[email protected]>
> Sent: Tuesday, July 12, 2022 12:50
> To: Oleksandr Natalenko <[email protected]>; Limonciello, Mario
> <[email protected]>; [email protected]
> Cc: Rafael J. Wysocki <[email protected]>; Sasha Levin
> <[email protected]>; [email protected]; H. Peter Anvin <[email protected]>;
> Greg Kroah-Hartman <[email protected]>
> Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11
>
> [AMD Official Use Only - General]
>
> Hi Oleksandr:
>
> > -----Original Message-----
> > From: Oleksandr Natalenko <[email protected]>
> > Sent: Wednesday, July 13, 2022 1:40 AM
> > To: Limonciello, Mario <[email protected]>; linux-
> > [email protected]
> > Cc: Yuan, Perry <[email protected]>; Rafael J. Wysocki
> > <[email protected]>; Sasha Levin <[email protected]>;
> > [email protected]; H. Peter Anvin <[email protected]>; Greg Kroah-Hartman
> > <[email protected]>
> > Subject: [REGRESSION] amd-pstate doesn't work since v5.18.11
> >
> > [CAUTION: External Email]
> >
> > Hello Mario.
> >
> > The following commits were pulled into v5.18.11:
> >
> > ```
> > $ git log --oneline --no-merges v5.18.10..v5.18.11 | grep ACPI
> > 2783414e6ef7 ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is
> > supported
> > 3068cfeca3b5 ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
> > 8beb71759cc8 ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is
> > supported
> > 13bb696dd2f3 ACPI: CPPC: Check _OSC for flexible address space ```
> >
> > and now this happens:
> >
> > ```
> > $ sudo modprobe amd-pstate shared_mem=1
> > modprobe: ERROR: could not insert 'amd_pstate': No such device ```
> >
> > With v5.18.10 this worked just fine.
> >
> > In your upstream commit 8b356e536e69f3a4d6778ae9f0858a1beadabb1f
> > you write:
> >
> > ```
> > If there is additional breakage on the shared memory designs also missing
> > this _OSC, additional follow up changes may be needed.
> > ```
> >
> > So the question is what else should be pulled into the stable tree to
> > unbreak amd-pstate?
> >
> > Thanks.
> >
> > --
> > Oleksandr Natalenko (post-factum)
> >
>
> Could you share the lscpu output ?
>
> Perry.
Thanks this is the sort of thing I was worried might happen as a result of requiring
the _OSC. It was introduced as part of that commit 8beb71759cc8.
To solve it I think we need to add more things to cpc_supported_by_cpu
(https://github.com/torvalds/linux/blob/525496a030de4ae64bb9e1d6bfc88eec6f5fe6e2/arch/x86/kernel/acpi/cppc.c#L19)
The question is how do we safely detect the shared memory designs?
These are a fixed quantity as newer designs /should/ be using the MSR.
I am tending to thing that unfortunately we need to have an allow-list of shared
memory design here unless someone has other ideas.
Hello.
On úterý 12. července 2022 19:50:33 CEST Limonciello, Mario wrote:
> [Public]
>
> + Ray
>
> > -----Original Message-----
> > From: Yuan, Perry <[email protected]>
> > Sent: Tuesday, July 12, 2022 12:50
> > To: Oleksandr Natalenko <[email protected]>; Limonciello, Mario
> > <[email protected]>; [email protected]
> > Cc: Rafael J. Wysocki <[email protected]>; Sasha Levin
> > <[email protected]>; [email protected]; H. Peter Anvin <[email protected]>;
> > Greg Kroah-Hartman <[email protected]>
> > Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11
> >
> > [AMD Official Use Only - General]
> >
> > Hi Oleksandr:
> >
> > > -----Original Message-----
> > > From: Oleksandr Natalenko <[email protected]>
> > > Sent: Wednesday, July 13, 2022 1:40 AM
> > > To: Limonciello, Mario <[email protected]>; linux-
> > > [email protected]
> > > Cc: Yuan, Perry <[email protected]>; Rafael J. Wysocki
> > > <[email protected]>; Sasha Levin <[email protected]>;
> > > [email protected]; H. Peter Anvin <[email protected]>; Greg Kroah-Hartman
> > > <[email protected]>
> > > Subject: [REGRESSION] amd-pstate doesn't work since v5.18.11
> > >
> > > [CAUTION: External Email]
> > >
> > > Hello Mario.
> > >
> > > The following commits were pulled into v5.18.11:
> > >
> > > ```
> > > $ git log --oneline --no-merges v5.18.10..v5.18.11 | grep ACPI
> > > 2783414e6ef7 ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is
> > > supported
> > > 3068cfeca3b5 ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
> > > 8beb71759cc8 ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is
> > > supported
> > > 13bb696dd2f3 ACPI: CPPC: Check _OSC for flexible address space ```
> > >
> > > and now this happens:
> > >
> > > ```
> > > $ sudo modprobe amd-pstate shared_mem=1
> > > modprobe: ERROR: could not insert 'amd_pstate': No such device ```
> > >
> > > With v5.18.10 this worked just fine.
> > >
> > > In your upstream commit 8b356e536e69f3a4d6778ae9f0858a1beadabb1f
> > > you write:
> > >
> > > ```
> > > If there is additional breakage on the shared memory designs also missing
> > > this _OSC, additional follow up changes may be needed.
> > > ```
> > >
> > > So the question is what else should be pulled into the stable tree to
> > > unbreak amd-pstate?
> > >
> > > Thanks.
> > >
> > > --
> > > Oleksandr Natalenko (post-factum)
> > >
> >
> > Could you share the lscpu output ?
Here's my `lscpu`:
```
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 43 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 24
On-line CPU(s) list: 0-23
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 9 3900XT 12-Core Processor
CPU family: 23
Model: 113
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 1
Stepping: 0
Frequency boost: enabled
CPU(s) scaling MHz: 59%
CPU max MHz: 3800,0000
CPU min MHz: 2200,0000
BogoMIPS: 7589.71
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sev sev_es
Virtualization: AMD-V
L1d cache: 384 KiB (12 instances)
L1i cache: 384 KiB (12 instances)
L2 cache: 6 MiB (12 instances)
L3 cache: 64 MiB (4 instances)
NUMA node(s): 1
NUMA node0 CPU(s): 0-23
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP conditional, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
```
> > Perry.
>
> Thanks this is the sort of thing I was worried might happen as a result of requiring
> the _OSC. It was introduced as part of that commit 8beb71759cc8.
>
> To solve it I think we need to add more things to cpc_supported_by_cpu
> (https://github.com/torvalds/linux/blob/525496a030de4ae64bb9e1d6bfc88eec6f5fe6e2/arch/x86/kernel/acpi/cppc.c#L19)
>
> The question is how do we safely detect the shared memory designs?
> These are a fixed quantity as newer designs /should/ be using the MSR.
>
> I am tending to thing that unfortunately we need to have an allow-list of shared
> memory design here unless someone has other ideas.
Happy to test any patches as needed.
--
Oleksandr Natalenko (post-factum)
On 7/12/2022 12:54, Oleksandr Natalenko wrote:
> Hello.
>
> On úterý 12. července 2022 19:50:33 CEST Limonciello, Mario wrote:
>> [Public]
>>
>> + Ray
>>
>>> -----Original Message-----
>>> From: Yuan, Perry <[email protected]>
>>> Sent: Tuesday, July 12, 2022 12:50
>>> To: Oleksandr Natalenko <[email protected]>; Limonciello, Mario
>>> <[email protected]>; [email protected]
>>> Cc: Rafael J. Wysocki <[email protected]>; Sasha Levin
>>> <[email protected]>; [email protected]; H. Peter Anvin <[email protected]>;
>>> Greg Kroah-Hartman <[email protected]>
>>> Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11
>>>
>>> [AMD Official Use Only - General]
>>>
>>> Hi Oleksandr:
>>>
>>>> -----Original Message-----
>>>> From: Oleksandr Natalenko <[email protected]>
>>>> Sent: Wednesday, July 13, 2022 1:40 AM
>>>> To: Limonciello, Mario <[email protected]>; linux-
>>>> [email protected]
>>>> Cc: Yuan, Perry <[email protected]>; Rafael J. Wysocki
>>>> <[email protected]>; Sasha Levin <[email protected]>;
>>>> [email protected]; H. Peter Anvin <[email protected]>; Greg Kroah-Hartman
>>>> <[email protected]>
>>>> Subject: [REGRESSION] amd-pstate doesn't work since v5.18.11
>>>>
>>>> [CAUTION: External Email]
>>>>
>>>> Hello Mario.
>>>>
>>>> The following commits were pulled into v5.18.11:
>>>>
>>>> ```
>>>> $ git log --oneline --no-merges v5.18.10..v5.18.11 | grep ACPI
>>>> 2783414e6ef7 ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is
>>>> supported
>>>> 3068cfeca3b5 ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
>>>> 8beb71759cc8 ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is
>>>> supported
>>>> 13bb696dd2f3 ACPI: CPPC: Check _OSC for flexible address space ```
>>>>
>>>> and now this happens:
>>>>
>>>> ```
>>>> $ sudo modprobe amd-pstate shared_mem=1
>>>> modprobe: ERROR: could not insert 'amd_pstate': No such device ```
>>>>
>>>> With v5.18.10 this worked just fine.
>>>>
>>>> In your upstream commit 8b356e536e69f3a4d6778ae9f0858a1beadabb1f
>>>> you write:
>>>>
>>>> ```
>>>> If there is additional breakage on the shared memory designs also missing
>>>> this _OSC, additional follow up changes may be needed.
>>>> ```
>>>>
>>>> So the question is what else should be pulled into the stable tree to
>>>> unbreak amd-pstate?
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> Oleksandr Natalenko (post-factum)
>>>>
>>>
>>> Could you share the lscpu output ?
>
> Here's my `lscpu`:
>
> ```
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Address sizes: 43 bits physical, 48 bits virtual
> Byte Order: Little Endian
> CPU(s): 24
> On-line CPU(s) list: 0-23
> Vendor ID: AuthenticAMD
> Model name: AMD Ryzen 9 3900XT 12-Core Processor
> CPU family: 23
> Model: 113
> Thread(s) per core: 2
> Core(s) per socket: 12
> Socket(s): 1
> Stepping: 0
> Frequency boost: enabled
> CPU(s) scaling MHz: 59%
> CPU max MHz: 3800,0000
> CPU min MHz: 2200,0000
> BogoMIPS: 7589.71
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sev sev_es
> Virtualization: AMD-V
> L1d cache: 384 KiB (12 instances)
> L1i cache: 384 KiB (12 instances)
> L2 cache: 6 MiB (12 instances)
> L3 cache: 64 MiB (4 instances)
> NUMA node(s): 1
> NUMA node0 CPU(s): 0-23
> Vulnerability Itlb multihit: Not affected
> Vulnerability L1tf: Not affected
> Vulnerability Mds: Not affected
> Vulnerability Meltdown: Not affected
> Vulnerability Mmio stale data: Not affected
> Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
> Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
> Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP conditional, RSB filling
> Vulnerability Srbds: Not affected
> Vulnerability Tsx async abort: Not affected
>
> ```
>
>>> Perry.
>>
>> Thanks this is the sort of thing I was worried might happen as a result of requiring
>> the _OSC. It was introduced as part of that commit 8beb71759cc8.
>>
>> To solve it I think we need to add more things to cpc_supported_by_cpu
>> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2F525496a030de4ae64bb9e1d6bfc88eec6f5fe6e2%2Farch%2Fx86%2Fkernel%2Facpi%2Fcppc.c%23L19&data=05%7C01%7CMario.Limonciello%40amd.com%7C96addaab0edc4e22779908da642f84ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637932453099304670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4KHD3UUlfDJEmpTpqDCmuV1x%2F7nj%2F0iuhwdnhJqtQeU%3D&reserved=0)
>>
>> The question is how do we safely detect the shared memory designs?
>> These are a fixed quantity as newer designs /should/ be using the MSR.
>>
>> I am tending to thing that unfortunately we need to have an allow-list of shared
>> memory design here unless someone has other ideas.
>
> Happy to test any patches as needed.
>
See if this helps out:
diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
index 734b96454896..88a81e6b9228 100644
--- a/arch/x86/kernel/acpi/cppc.c
+++ b/arch/x86/kernel/acpi/cppc.c
@@ -16,6 +16,13 @@ bool cpc_supported_by_cpu(void)
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_AMD:
case X86_VENDOR_HYGON:
+ if (boot_cpu_data.x86 == 0x19 &&
+ ((boot_cpu_data.x86_model >= 0x00 &&
boot_cpu_data.x86_model <= 0x0f) ||
+ (boot_cpu_data.x86_model >= 0x20 &&
boot_cpu_data.x86_model <= 0x2f)))
+ return true;
+ else if (boot_cpu_data.x86 == 0x17 &&
+ boot_cpu_data.x86_model >= 0x70 &&
boot_cpu_data.x86_model <= 0x7f)
+ return true;
return boot_cpu_has(X86_FEATURE_CPPC);
}
return false;
If that works and no one has a better idea how to do it for these
systems I'll send out a proper proper patch tomorrow.
Hello.
On úterý 12. července 2022 22:07:15 CEST Limonciello, Mario wrote:
> See if this helps out:
>
> diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c
> index 734b96454896..88a81e6b9228 100644
> --- a/arch/x86/kernel/acpi/cppc.c
> +++ b/arch/x86/kernel/acpi/cppc.c
> @@ -16,6 +16,13 @@ bool cpc_supported_by_cpu(void)
> switch (boot_cpu_data.x86_vendor) {
> case X86_VENDOR_AMD:
> case X86_VENDOR_HYGON:
> + if (boot_cpu_data.x86 == 0x19 &&
> + ((boot_cpu_data.x86_model >= 0x00 &&
> boot_cpu_data.x86_model <= 0x0f) ||
> + (boot_cpu_data.x86_model >= 0x20 &&
> boot_cpu_data.x86_model <= 0x2f)))
> + return true;
> + else if (boot_cpu_data.x86 == 0x17 &&
> + boot_cpu_data.x86_model >= 0x70 &&
> boot_cpu_data.x86_model <= 0x7f)
> + return true;
> return boot_cpu_has(X86_FEATURE_CPPC);
> }
> return false;
>
> If that works and no one has a better idea how to do it for these
> systems I'll send out a proper proper patch tomorrow.
This patch (also mirrored here [1]) works for me, thanks.
[1] https://codeberg.org/pf-kernel/linux/commit/cc5c57b8c349c85b81b44cf5fe2d2577b947a7de
--
Oleksandr Natalenko (post-factum)
[AMD Official Use Only - General]
Hi Mario.
> -----Original Message-----
> From: Limonciello, Mario <[email protected]>
> Sent: Wednesday, July 13, 2022 4:07 AM
> To: Oleksandr Natalenko <[email protected]>; Yuan, Perry
> <[email protected]>; [email protected]; Huang, Ray
> <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>; Sasha Levin
> <[email protected]>; [email protected]; H. Peter Anvin <[email protected]>;
> Greg Kroah-Hartman <[email protected]>
> Subject: Re: [REGRESSION] amd-pstate doesn't work since v5.18.11
>
> On 7/12/2022 12:54, Oleksandr Natalenko wrote:
> > Hello.
> >
> > On úterý 12. července 2022 19:50:33 CEST Limonciello, Mario wrote:
> >> [Public]
> >>
> >> + Ray
> >>
> >>> -----Original Message-----
> >>> From: Yuan, Perry <[email protected]>
> >>> Sent: Tuesday, July 12, 2022 12:50
> >>> To: Oleksandr Natalenko <[email protected]>; Limonciello,
> >>> Mario <[email protected]>; [email protected]
> >>> Cc: Rafael J. Wysocki <[email protected]>; Sasha Levin
> >>> <[email protected]>; [email protected]; H. Peter Anvin <[email protected]>;
> >>> Greg Kroah-Hartman <[email protected]>
> >>> Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11
> >>>
> >>> [AMD Official Use Only - General]
> >>>
> >>> Hi Oleksandr:
> >>>
> >>>> -----Original Message-----
> >>>> From: Oleksandr Natalenko <[email protected]>
> >>>> Sent: Wednesday, July 13, 2022 1:40 AM
> >>>> To: Limonciello, Mario <[email protected]>; linux-
> >>>> [email protected]
> >>>> Cc: Yuan, Perry <[email protected]>; Rafael J. Wysocki
> >>>> <[email protected]>; Sasha Levin <[email protected]>;
> >>>> [email protected]; H. Peter Anvin <[email protected]>; Greg Kroah-Hartman
> >>>> <[email protected]>
> >>>> Subject: [REGRESSION] amd-pstate doesn't work since v5.18.11
> >>>>
> >>>> [CAUTION: External Email]
> >>>>
> >>>> Hello Mario.
> >>>>
> >>>> The following commits were pulled into v5.18.11:
> >>>>
> >>>> ```
> >>>> $ git log --oneline --no-merges v5.18.10..v5.18.11 | grep ACPI
> >>>> 2783414e6ef7 ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is
> >>>> supported
> >>>> 3068cfeca3b5 ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
> >>>> 8beb71759cc8 ACPI: bus: Set CPPC _OSC bits for all and when
> >>>> CPPC_LIB is supported
> >>>> 13bb696dd2f3 ACPI: CPPC: Check _OSC for flexible address space ```
> >>>>
> >>>> and now this happens:
> >>>>
> >>>> ```
> >>>> $ sudo modprobe amd-pstate shared_mem=1
> >>>> modprobe: ERROR: could not insert 'amd_pstate': No such device ```
> >>>>
> >>>> With v5.18.10 this worked just fine.
> >>>>
> >>>> In your upstream commit
> 8b356e536e69f3a4d6778ae9f0858a1beadabb1f
> >>>> you write:
> >>>>
> >>>> ```
> >>>> If there is additional breakage on the shared memory designs also
> >>>> missing this _OSC, additional follow up changes may be needed.
> >>>> ```
> >>>>
> >>>> So the question is what else should be pulled into the stable tree
> >>>> to unbreak amd-pstate?
> >>>>
> >>>> Thanks.
> >>>>
> >>>> --
> >>>> Oleksandr Natalenko (post-factum)
> >>>>
> >>>
> >>> Could you share the lscpu output ?
> >
> > Here's my `lscpu`:
> >
> > ```
> > Architecture: x86_64
> > CPU op-mode(s): 32-bit, 64-bit
> > Address sizes: 43 bits physical, 48 bits virtual
> > Byte Order: Little Endian
> > CPU(s): 24
> > On-line CPU(s) list: 0-23
> > Vendor ID: AuthenticAMD
> > Model name: AMD Ryzen 9 3900XT 12-Core Processor
> > CPU family: 23
> > Model: 113
> > Thread(s) per core: 2
> > Core(s) per socket: 12
> > Socket(s): 1
> > Stepping: 0
> > Frequency boost: enabled
> > CPU(s) scaling MHz: 59%
> > CPU max MHz: 3800,0000
> > CPU min MHz: 2200,0000
> > BogoMIPS: 7589.71
> > Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
> aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic
> movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic
> cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce
> topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3
> hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm
> rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves
> cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf
> xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale
> vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic
> v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca
> sev sev_es
> > Virtualization: AMD-V
> > L1d cache: 384 KiB (12 instances)
> > L1i cache: 384 KiB (12 instances)
> > L2 cache: 6 MiB (12 instances)
> > L3 cache: 64 MiB (4 instances)
> > NUMA node(s): 1
> > NUMA node0 CPU(s): 0-23
> > Vulnerability Itlb multihit: Not affected
> > Vulnerability L1tf: Not affected
> > Vulnerability Mds: Not affected
> > Vulnerability Meltdown: Not affected
> > Vulnerability Mmio stale data: Not affected
> > Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass
> disabled via prctl
> > Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and
> __user pointer sanitization
> > Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP
> conditional, RSB filling
> > Vulnerability Srbds: Not affected
> > Vulnerability Tsx async abort: Not affected
> >
> > ```
> >
> >>> Perry.
> >>
> >> Thanks this is the sort of thing I was worried might happen as a
> >> result of requiring the _OSC. It was introduced as part of that commit
> 8beb71759cc8.
> >>
> >> To solve it I think we need to add more things to
> >> cpc_supported_by_cpu
> >> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> >>
> thub.com%2Ftorvalds%2Flinux%2Fblob%2F525496a030de4ae64bb9e1d6bfc8
> 8eec
> >>
> 6f5fe6e2%2Farch%2Fx86%2Fkernel%2Facpi%2Fcppc.c%23L19&data=05
> %7C01
> >> %7CMario.Limonciello%40amd.com%7C96addaab0edc4e22779908da642f
> 84ac%7C3
> >>
> dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637932453099304670
> %7CUnknow
> >>
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiL
> >>
> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4KHD3UUlfDJEmpTpqDC
> muV1x%2F7n
> >> j%2F0iuhwdnhJqtQeU%3D&reserved=0)
> >>
> >> The question is how do we safely detect the shared memory designs?
> >> These are a fixed quantity as newer designs /should/ be using the MSR.
> >>
> >> I am tending to thing that unfortunately we need to have an
> >> allow-list of shared memory design here unless someone has other ideas.
> >
> > Happy to test any patches as needed.
> >
>
> See if this helps out:
>
> diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c index
> 734b96454896..88a81e6b9228 100644
> --- a/arch/x86/kernel/acpi/cppc.c
> +++ b/arch/x86/kernel/acpi/cppc.c
> @@ -16,6 +16,13 @@ bool cpc_supported_by_cpu(void)
> switch (boot_cpu_data.x86_vendor) {
> case X86_VENDOR_AMD:
> case X86_VENDOR_HYGON:
> + if (boot_cpu_data.x86 == 0x19 &&
> + ((boot_cpu_data.x86_model >= 0x00 &&
> boot_cpu_data.x86_model <= 0x0f) ||
> + (boot_cpu_data.x86_model >= 0x20 &&
> boot_cpu_data.x86_model <= 0x2f)))
> + return true;
> + else if (boot_cpu_data.x86 == 0x17 &&
> + boot_cpu_data.x86_model >= 0x70 &&
> boot_cpu_data.x86_model <= 0x7f)
> + return true;
> return boot_cpu_has(X86_FEATURE_CPPC);
> }
> return false;
>
> If that works and no one has a better idea how to do it for these systems I'll
> send out a proper proper patch tomorrow.
This could be a short-term solution, I would prefer to add CPU Ids check and we can maintain that list for
all the model info including MSRs and Shared mem types.
Meanwhile I have the similar issues concern for the coming EPP driver, some systems don`t support EPP and we cannot identify that without IDs list.
Perry.
On 7/12/22 21:40, Yuan, Perry wrote:
> [AMD Official Use Only - General]
>
> Hi Mario.
>
>> -----Original Message-----
>> From: Limonciello, Mario <[email protected]>
>> Sent: Wednesday, July 13, 2022 4:07 AM
>> To: Oleksandr Natalenko <[email protected]>; Yuan, Perry
>> <[email protected]>; [email protected]; Huang, Ray
>> <[email protected]>
>> Cc: Rafael J. Wysocki <[email protected]>; Sasha Levin
>> <[email protected]>; [email protected]; H. Peter Anvin <[email protected]>;
>> Greg Kroah-Hartman <[email protected]>
>> Subject: Re: [REGRESSION] amd-pstate doesn't work since v5.18.11
>>
>> On 7/12/2022 12:54, Oleksandr Natalenko wrote:
>>> Hello.
>>>
>>> On úterý 12. července 2022 19:50:33 CEST Limonciello, Mario wrote:
>>>> [Public]
>>>>
>>>> + Ray
>>>>
>>>>> -----Original Message-----
>>>>> From: Yuan, Perry <[email protected]>
>>>>> Sent: Tuesday, July 12, 2022 12:50
>>>>> To: Oleksandr Natalenko <[email protected]>; Limonciello,
>>>>> Mario <[email protected]>; [email protected]
>>>>> Cc: Rafael J. Wysocki <[email protected]>; Sasha Levin
>>>>> <[email protected]>; [email protected]; H. Peter Anvin <[email protected]>;
>>>>> Greg Kroah-Hartman <[email protected]>
>>>>> Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11
>>>>>
>>>>> [AMD Official Use Only - General]
>>>>>
>>>>> Hi Oleksandr:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Oleksandr Natalenko <[email protected]>
>>>>>> Sent: Wednesday, July 13, 2022 1:40 AM
>>>>>> To: Limonciello, Mario <[email protected]>; linux-
>>>>>> [email protected]
>>>>>> Cc: Yuan, Perry <[email protected]>; Rafael J. Wysocki
>>>>>> <[email protected]>; Sasha Levin <[email protected]>;
>>>>>> [email protected]; H. Peter Anvin <[email protected]>; Greg Kroah-Hartman
>>>>>> <[email protected]>
>>>>>> Subject: [REGRESSION] amd-pstate doesn't work since v5.18.11
>>>>>>
>>>>>> [CAUTION: External Email]
>>>>>>
>>>>>> Hello Mario.
>>>>>>
>>>>>> The following commits were pulled into v5.18.11:
>>>>>>
>>>>>> ```
>>>>>> $ git log --oneline --no-merges v5.18.10..v5.18.11 | grep ACPI
>>>>>> 2783414e6ef7 ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is
>>>>>> supported
>>>>>> 3068cfeca3b5 ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked
>>>>>> 8beb71759cc8 ACPI: bus: Set CPPC _OSC bits for all and when
>>>>>> CPPC_LIB is supported
>>>>>> 13bb696dd2f3 ACPI: CPPC: Check _OSC for flexible address space ```
>>>>>>
>>>>>> and now this happens:
>>>>>>
>>>>>> ```
>>>>>> $ sudo modprobe amd-pstate shared_mem=1
>>>>>> modprobe: ERROR: could not insert 'amd_pstate': No such device ```
>>>>>>
>>>>>> With v5.18.10 this worked just fine.
>>>>>>
>>>>>> In your upstream commit
>> 8b356e536e69f3a4d6778ae9f0858a1beadabb1f
>>>>>> you write:
>>>>>>
>>>>>> ```
>>>>>> If there is additional breakage on the shared memory designs also
>>>>>> missing this _OSC, additional follow up changes may be needed.
>>>>>> ```
>>>>>>
>>>>>> So the question is what else should be pulled into the stable tree
>>>>>> to unbreak amd-pstate?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> --
>>>>>> Oleksandr Natalenko (post-factum)
>>>>>>
>>>>>
>>>>> Could you share the lscpu output ?
>>>
>>> Here's my `lscpu`:
>>>
>>> ```
>>> Architecture: x86_64
>>> CPU op-mode(s): 32-bit, 64-bit
>>> Address sizes: 43 bits physical, 48 bits virtual
>>> Byte Order: Little Endian
>>> CPU(s): 24
>>> On-line CPU(s) list: 0-23
>>> Vendor ID: AuthenticAMD
>>> Model name: AMD Ryzen 9 3900XT 12-Core Processor
>>> CPU family: 23
>>> Model: 113
>>> Thread(s) per core: 2
>>> Core(s) per socket: 12
>>> Socket(s): 1
>>> Stepping: 0
>>> Frequency boost: enabled
>>> CPU(s) scaling MHz: 59%
>>> CPU max MHz: 3800,0000
>>> CPU min MHz: 2200,0000
>>> BogoMIPS: 7589.71
>>> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
>> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid
>> aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic
>> movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic
>> cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce
>> topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3
>> hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm
>> rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves
>> cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf
>> xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale
>> vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic
>> v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca
>> sev sev_es
>>> Virtualization: AMD-V
>>> L1d cache: 384 KiB (12 instances)
>>> L1i cache: 384 KiB (12 instances)
>>> L2 cache: 6 MiB (12 instances)
>>> L3 cache: 64 MiB (4 instances)
>>> NUMA node(s): 1
>>> NUMA node0 CPU(s): 0-23
>>> Vulnerability Itlb multihit: Not affected
>>> Vulnerability L1tf: Not affected
>>> Vulnerability Mds: Not affected
>>> Vulnerability Meltdown: Not affected
>>> Vulnerability Mmio stale data: Not affected
>>> Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass
>> disabled via prctl
>>> Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and
>> __user pointer sanitization
>>> Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, STIBP
>> conditional, RSB filling
>>> Vulnerability Srbds: Not affected
>>> Vulnerability Tsx async abort: Not affected
>>>
>>> ```
>>>
>>>>> Perry.
>>>>
>>>> Thanks this is the sort of thing I was worried might happen as a
>>>> result of requiring the _OSC. It was introduced as part of that commit
>> 8beb71759cc8.
>>>>
>>>> To solve it I think we need to add more things to
>>>> cpc_supported_by_cpu
>>>> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
>>>>
>> thub.com%2Ftorvalds%2Flinux%2Fblob%2F525496a030de4ae64bb9e1d6bfc8
>> 8eec
>>>>
>> 6f5fe6e2%2Farch%2Fx86%2Fkernel%2Facpi%2Fcppc.c%23L19&data=05
>> %7C01
>>>> %7CMario.Limonciello%40amd.com%7C96addaab0edc4e22779908da642f
>> 84ac%7C3
>>>>
>> dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637932453099304670
>> %7CUnknow
>>>>
>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>> WwiL
>>>>
>> CJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4KHD3UUlfDJEmpTpqDC
>> muV1x%2F7n
>>>> j%2F0iuhwdnhJqtQeU%3D&reserved=0)
>>>>
>>>> The question is how do we safely detect the shared memory designs?
>>>> These are a fixed quantity as newer designs /should/ be using the MSR.
>>>>
>>>> I am tending to thing that unfortunately we need to have an
>>>> allow-list of shared memory design here unless someone has other ideas.
>>>
>>> Happy to test any patches as needed.
>>>
>>
>> See if this helps out:
>>
>> diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c index
>> 734b96454896..88a81e6b9228 100644
>> --- a/arch/x86/kernel/acpi/cppc.c
>> +++ b/arch/x86/kernel/acpi/cppc.c
>> @@ -16,6 +16,13 @@ bool cpc_supported_by_cpu(void)
>> switch (boot_cpu_data.x86_vendor) {
>> case X86_VENDOR_AMD:
>> case X86_VENDOR_HYGON:
>> + if (boot_cpu_data.x86 == 0x19 &&
>> + ((boot_cpu_data.x86_model >= 0x00 &&
>> boot_cpu_data.x86_model <= 0x0f) ||
>> + (boot_cpu_data.x86_model >= 0x20 &&
>> boot_cpu_data.x86_model <= 0x2f)))
>> + return true;
>> + else if (boot_cpu_data.x86 == 0x17 &&
>> + boot_cpu_data.x86_model >= 0x70 &&
>> boot_cpu_data.x86_model <= 0x7f)
>> + return true;
>> return boot_cpu_has(X86_FEATURE_CPPC);
>> }
>> return false;
>>
>> If that works and no one has a better idea how to do it for these systems I'll
>> send out a proper proper patch tomorrow.
>
> This could be a short-term solution, I would prefer to add CPU Ids check and we can maintain that list for
> all the model info including MSRs and Shared mem types.
What's longer term solution when it comes to shared mem? It seems like
it's either a list of IDs or a heuristic. Given it's a fixed list and
new designs take MSR, I would think the list of IDs is preferable.
Furthermore; I would argue that if there was another design introduced
for some reason that takes shared mem instead of MSR it should be using
_OSC to indicate CPPCv2 support not this list. This list only needs to
exist because the requirement for CPPC support in the _OSC is very
recent to the kernel.
Regarding MSR -
boot_cpu_has(X86_FEATURE_CPPC) indicates the MSR support. There
shouldn't be any need to maintain a list in this _OSC override check here.
>
> Meanwhile I have the similar issues concern for the coming EPP driver, some systems don`t support EPP and we cannot identify that without IDs list.
That will be localized into the EPP driver source at least.
>
> Perry.
>