* [REGRESSION] amd-pstate doesn't work since v5.18.11 @ 2022-07-12 17:40 Oleksandr Natalenko 2022-07-12 17:49 ` Yuan, Perry 0 siblings, 1 reply; 8+ messages in thread From: Oleksandr Natalenko @ 2022-07-12 17:40 UTC (permalink / raw) To: Mario Limonciello, linux-kernel Cc: Perry Yuan, Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 2022-07-12 17:40 [REGRESSION] amd-pstate doesn't work since v5.18.11 Oleksandr Natalenko @ 2022-07-12 17:49 ` Yuan, Perry 2022-07-12 17:50 ` Limonciello, Mario 0 siblings, 1 reply; 8+ messages in thread From: Yuan, Perry @ 2022-07-12 17:49 UTC (permalink / raw) To: Oleksandr Natalenko, Limonciello, Mario, linux-kernel Cc: Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman [AMD Official Use Only - General] Hi Oleksandr: > -----Original Message----- > From: Oleksandr Natalenko <oleksandr@natalenko.name> > Sent: Wednesday, July 13, 2022 1:40 AM > To: Limonciello, Mario <Mario.Limonciello@amd.com>; linux- > kernel@vger.kernel.org > Cc: Yuan, Perry <Perry.Yuan@amd.com>; Rafael J. Wysocki > <rafael.j.wysocki@intel.com>; Sasha Levin <sashal@kernel.org>; > x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Greg Kroah-Hartman > <gregkh@linuxfoundation.org> > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 2022-07-12 17:49 ` Yuan, Perry @ 2022-07-12 17:50 ` Limonciello, Mario 2022-07-12 17:54 ` Oleksandr Natalenko 0 siblings, 1 reply; 8+ messages in thread From: Limonciello, Mario @ 2022-07-12 17:50 UTC (permalink / raw) To: Yuan, Perry, Oleksandr Natalenko, linux-kernel, Huang, Ray Cc: Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman [Public] + Ray > -----Original Message----- > From: Yuan, Perry <Perry.Yuan@amd.com> > Sent: Tuesday, July 12, 2022 12:50 > To: Oleksandr Natalenko <oleksandr@natalenko.name>; Limonciello, Mario > <Mario.Limonciello@amd.com>; linux-kernel@vger.kernel.org > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Sasha Levin > <sashal@kernel.org>; x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; > Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 > > [AMD Official Use Only - General] > > Hi Oleksandr: > > > -----Original Message----- > > From: Oleksandr Natalenko <oleksandr@natalenko.name> > > Sent: Wednesday, July 13, 2022 1:40 AM > > To: Limonciello, Mario <Mario.Limonciello@amd.com>; linux- > > kernel@vger.kernel.org > > Cc: Yuan, Perry <Perry.Yuan@amd.com>; Rafael J. Wysocki > > <rafael.j.wysocki@intel.com>; Sasha Levin <sashal@kernel.org>; > > x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> > > 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [REGRESSION] amd-pstate doesn't work since v5.18.11 2022-07-12 17:50 ` Limonciello, Mario @ 2022-07-12 17:54 ` Oleksandr Natalenko 2022-07-12 20:07 ` Limonciello, Mario 0 siblings, 1 reply; 8+ messages in thread From: Oleksandr Natalenko @ 2022-07-12 17:54 UTC (permalink / raw) To: Yuan, Perry, linux-kernel, Huang, Ray, Limonciello, Mario Cc: Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman Hello. On úterý 12. července 2022 19:50:33 CEST Limonciello, Mario wrote: > [Public] > > + Ray > > > -----Original Message----- > > From: Yuan, Perry <Perry.Yuan@amd.com> > > Sent: Tuesday, July 12, 2022 12:50 > > To: Oleksandr Natalenko <oleksandr@natalenko.name>; Limonciello, Mario > > <Mario.Limonciello@amd.com>; linux-kernel@vger.kernel.org > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Sasha Levin > > <sashal@kernel.org>; x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 > > > > [AMD Official Use Only - General] > > > > Hi Oleksandr: > > > > > -----Original Message----- > > > From: Oleksandr Natalenko <oleksandr@natalenko.name> > > > Sent: Wednesday, July 13, 2022 1:40 AM > > > To: Limonciello, Mario <Mario.Limonciello@amd.com>; linux- > > > kernel@vger.kernel.org > > > Cc: Yuan, Perry <Perry.Yuan@amd.com>; Rafael J. Wysocki > > > <rafael.j.wysocki@intel.com>; Sasha Levin <sashal@kernel.org>; > > > x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Greg Kroah-Hartman > > > <gregkh@linuxfoundation.org> > > > 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [REGRESSION] amd-pstate doesn't work since v5.18.11 2022-07-12 17:54 ` Oleksandr Natalenko @ 2022-07-12 20:07 ` Limonciello, Mario 2022-07-12 21:55 ` Oleksandr Natalenko 2022-07-13 2:40 ` Yuan, Perry 0 siblings, 2 replies; 8+ messages in thread From: Limonciello, Mario @ 2022-07-12 20:07 UTC (permalink / raw) To: Oleksandr Natalenko, Yuan, Perry, linux-kernel, Huang, Ray Cc: Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman 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 <Perry.Yuan@amd.com> >>> Sent: Tuesday, July 12, 2022 12:50 >>> To: Oleksandr Natalenko <oleksandr@natalenko.name>; Limonciello, Mario >>> <Mario.Limonciello@amd.com>; linux-kernel@vger.kernel.org >>> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Sasha Levin >>> <sashal@kernel.org>; x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; >>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> >>> Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 >>> >>> [AMD Official Use Only - General] >>> >>> Hi Oleksandr: >>> >>>> -----Original Message----- >>>> From: Oleksandr Natalenko <oleksandr@natalenko.name> >>>> Sent: Wednesday, July 13, 2022 1:40 AM >>>> To: Limonciello, Mario <Mario.Limonciello@amd.com>; linux- >>>> kernel@vger.kernel.org >>>> Cc: Yuan, Perry <Perry.Yuan@amd.com>; Rafael J. Wysocki >>>> <rafael.j.wysocki@intel.com>; Sasha Levin <sashal@kernel.org>; >>>> x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Greg Kroah-Hartman >>>> <gregkh@linuxfoundation.org> >>>> 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. ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [REGRESSION] amd-pstate doesn't work since v5.18.11 2022-07-12 20:07 ` Limonciello, Mario @ 2022-07-12 21:55 ` Oleksandr Natalenko 2022-07-13 2:40 ` Yuan, Perry 1 sibling, 0 replies; 8+ messages in thread From: Oleksandr Natalenko @ 2022-07-12 21:55 UTC (permalink / raw) To: Yuan, Perry, linux-kernel, Huang, Ray, Limonciello, Mario Cc: Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 2022-07-12 20:07 ` Limonciello, Mario 2022-07-12 21:55 ` Oleksandr Natalenko @ 2022-07-13 2:40 ` Yuan, Perry 2022-07-13 3:10 ` Mario Limonciello 1 sibling, 1 reply; 8+ messages in thread From: Yuan, Perry @ 2022-07-13 2:40 UTC (permalink / raw) To: Limonciello, Mario, Oleksandr Natalenko, linux-kernel, Huang, Ray Cc: Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman [AMD Official Use Only - General] Hi Mario. > -----Original Message----- > From: Limonciello, Mario <Mario.Limonciello@amd.com> > Sent: Wednesday, July 13, 2022 4:07 AM > To: Oleksandr Natalenko <oleksandr@natalenko.name>; Yuan, Perry > <Perry.Yuan@amd.com>; linux-kernel@vger.kernel.org; Huang, Ray > <Ray.Huang@amd.com> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Sasha Levin > <sashal@kernel.org>; x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; > Greg Kroah-Hartman <gregkh@linuxfoundation.org> > 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 <Perry.Yuan@amd.com> > >>> Sent: Tuesday, July 12, 2022 12:50 > >>> To: Oleksandr Natalenko <oleksandr@natalenko.name>; Limonciello, > >>> Mario <Mario.Limonciello@amd.com>; linux-kernel@vger.kernel.org > >>> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Sasha Levin > >>> <sashal@kernel.org>; x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; > >>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> > >>> Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 > >>> > >>> [AMD Official Use Only - General] > >>> > >>> Hi Oleksandr: > >>> > >>>> -----Original Message----- > >>>> From: Oleksandr Natalenko <oleksandr@natalenko.name> > >>>> Sent: Wednesday, July 13, 2022 1:40 AM > >>>> To: Limonciello, Mario <Mario.Limonciello@amd.com>; linux- > >>>> kernel@vger.kernel.org > >>>> Cc: Yuan, Perry <Perry.Yuan@amd.com>; Rafael J. Wysocki > >>>> <rafael.j.wysocki@intel.com>; Sasha Levin <sashal@kernel.org>; > >>>> x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Greg Kroah-Hartman > >>>> <gregkh@linuxfoundation.org> > >>>> 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [REGRESSION] amd-pstate doesn't work since v5.18.11 2022-07-13 2:40 ` Yuan, Perry @ 2022-07-13 3:10 ` Mario Limonciello 0 siblings, 0 replies; 8+ messages in thread From: Mario Limonciello @ 2022-07-13 3:10 UTC (permalink / raw) To: Yuan, Perry, Oleksandr Natalenko, linux-kernel, Huang, Ray Cc: Rafael J. Wysocki, Sasha Levin, x86, H. Peter Anvin, Greg Kroah-Hartman On 7/12/22 21:40, Yuan, Perry wrote: > [AMD Official Use Only - General] > > Hi Mario. > >> -----Original Message----- >> From: Limonciello, Mario <Mario.Limonciello@amd.com> >> Sent: Wednesday, July 13, 2022 4:07 AM >> To: Oleksandr Natalenko <oleksandr@natalenko.name>; Yuan, Perry >> <Perry.Yuan@amd.com>; linux-kernel@vger.kernel.org; Huang, Ray >> <Ray.Huang@amd.com> >> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Sasha Levin >> <sashal@kernel.org>; x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; >> Greg Kroah-Hartman <gregkh@linuxfoundation.org> >> 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 <Perry.Yuan@amd.com> >>>>> Sent: Tuesday, July 12, 2022 12:50 >>>>> To: Oleksandr Natalenko <oleksandr@natalenko.name>; Limonciello, >>>>> Mario <Mario.Limonciello@amd.com>; linux-kernel@vger.kernel.org >>>>> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Sasha Levin >>>>> <sashal@kernel.org>; x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; >>>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> >>>>> Subject: RE: [REGRESSION] amd-pstate doesn't work since v5.18.11 >>>>> >>>>> [AMD Official Use Only - General] >>>>> >>>>> Hi Oleksandr: >>>>> >>>>>> -----Original Message----- >>>>>> From: Oleksandr Natalenko <oleksandr@natalenko.name> >>>>>> Sent: Wednesday, July 13, 2022 1:40 AM >>>>>> To: Limonciello, Mario <Mario.Limonciello@amd.com>; linux- >>>>>> kernel@vger.kernel.org >>>>>> Cc: Yuan, Perry <Perry.Yuan@amd.com>; Rafael J. Wysocki >>>>>> <rafael.j.wysocki@intel.com>; Sasha Levin <sashal@kernel.org>; >>>>>> x86@kernel.org; H. Peter Anvin <hpa@zytor.com>; Greg Kroah-Hartman >>>>>> <gregkh@linuxfoundation.org> >>>>>> 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. > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-07-13 3:10 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-07-12 17:40 [REGRESSION] amd-pstate doesn't work since v5.18.11 Oleksandr Natalenko 2022-07-12 17:49 ` Yuan, Perry 2022-07-12 17:50 ` Limonciello, Mario 2022-07-12 17:54 ` Oleksandr Natalenko 2022-07-12 20:07 ` Limonciello, Mario 2022-07-12 21:55 ` Oleksandr Natalenko 2022-07-13 2:40 ` Yuan, Perry 2022-07-13 3:10 ` Mario Limonciello
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.