linux-kernel - Re: [PATCH v2 2/2] ACPI: processor: idle: Replace single idle driver with per-CPU model for better hybrid CPU support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a369a7a9-9132-4b37-8ba2-501503477bb8@kylinos.cn>
Date: Wed, 27 Aug 2025 15:52:46 +0800
From: Yaxiong Tian <tianyaxiong@...inos.cn>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: daniel.lezcano@...aro.org, lenb@...nel.org, robert.moore@...el.com,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-acpi@...r.kernel.org, acpica-devel@...ts.linux.dev,
 Shaobo Huang <huangshaobo2075@...tium.com.cn>,
 Yinfeng Wang <wangyinfeng@...tium.com.cn>, Xu Wang <wangxu@...tium.com.cn>
Subject: Re: [PATCH v2 2/2] ACPI: processor: idle: Replace single idle driver
 with per-CPU model for better hybrid CPU support

在 2025/8/25 22:56, Rafael J. Wysocki 写道:
> On Thu, Aug 14, 2025 at 9:32 AM Yaxiong Tian <tianyaxiong@...inos.cn> wrote:
>> Current implementations of hybrid architectures (e.g., ARM64 big.LITTLE
>> and Intel Alder Lake) feature CPU cores with different exit latencies.
> This is not true for Intel platforms, all of the CPUs in there have
> the same set of C-states.
Yes,it is.
>
>> Using a single driver to describe_LPI states for all core types is
>> therefore suboptimal. This is further supported by ACPI specification
>> 8.4.4.1 which states: "In a processor hierarchy, each node has its
>> own _LPI low-power states specific to that node."
>>
>> To address these limitations, we replace the monolithic idle driver
> It cannot be replaced or you potentially open a Pandora's box of
> regressions on old systems in the field.
I agree with this point. Regarding the potential risk, does it
make sense to  mitigate it through the following two approaches?

1) Restrict the usage of this multiple driver functionality to
the ARM64 platform only.
2) Use a mutex-protected global variable to indicate whether
the platform utilizes _LPI instead of C-states. This variable
would be determined during initialization via
acpi_has_method(handle, "_LPI"), and the multiple driver
would only be used if the platform employs _LPI.

Alternatively, the other option is to let users implement their
own drivers. Although many ARM64 users still initialize their
systems using the ACPI method rather than the traditional
device tree approach, and they hope to reuse the ACPI idle driver.
>
>> with a per-CPU model. This approach enables accurate idle state representation
>> for each core type
> The per-CPU model can be used instead of the "monolithic idle driver"
> only if the platform is actually known to be hybrid.
Yes,select CPU_IDLE_MULTIPLE_DRIVERS if ARM64  can  resolve this issue.
>
>> Tested-by: Shaobo Huang <huangshaobo2075@...tium.com.cn>
>> Signed-off-by: Yaxiong Tian <tianyaxiong@...inos.cn>
>> Signed-off-by: Shaobo Huang <huangshaobo2075@...tium.com.cn>
>> Signed-off-by: Yinfeng Wang <wangyinfeng@...tium.com.cn>
>> Signed-off-by: Xu Wang<wangxu@...tium.com.cn>
> What do all of the above S-o-b mean?  Are these people involved in the
> development of the code?  In that case Co-developed-by is also needed.
>
> Thanks!
Thank you for your response. If it makes sense, continue to follow up,
I will address both the issues mentioned above and the problem
in the previous patch.