linux-kernel - Re: [PATCH] acpi: Allow ignoring _OSC CPPC v2 bit via kernel parameter

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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 18 Jun 2024 13:58:07 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Aaron Rainbolt <arainbolt@...cus.org>
Cc: linux-acpi@...r.kernel.org, rafael@...nel.org, lenb@...nel.org,
 linux-kernel@...r.kernel.org, mmikowski@...cus.org, Perry.Yuan@....com
Subject: Re: [PATCH] acpi: Allow ignoring _OSC CPPC v2 bit via kernel
 parameter

On 6/18/2024 13:52, Aaron Rainbolt wrote:
> On Tue, Jun 18, 2024 at 01:35:57PM -0500, Mario Limonciello wrote:
>> On 6/18/2024 13:30, Aaron Rainbolt wrote:
>>> On Tue, Jun 18, 2024 at 12:09:19PM -0500, Mario Limonciello wrote:
>>>> On 6/17/2024 21:54, Aaron Rainbolt wrote:
>>>>> acpi: Allow ignoring _OSC CPPC v2 bit via kernel parameter
>>>>>
>>>>> The _OSC is supposed to contain a bit indicating whether the hardware
>>>>> supports CPPC v2 or not. This bit is not always set, causing CPPC v2 to
>>>>> be considered absent. This results in severe single-core performance
>>>>> issues with the EEVDF scheduler.
>>>>>
>>>>> To work around this, provide a new kernel parameter,
>>>>> "processor.ignore_osc_cppc_bit", which may be used to ignore the _OSC
>>>>> CPPC v2 bit and act as if the bit was enabled. This allows CPPC to be
>>>>> properly detected even if not "enabled" by _OSC, allowing users with
>>>>> problematic hardware to obtain decent single-core performance.
>>>>>
>>>>> Tested-by: Michael Mikowski <mmikowski@...cus.org>
>>>>> Signed-off-by: Aaron Rainbolt <arainbolt@...cus.org>
>>>>
>>>> This sounds like a platform bug and if we do accept a patch like this I
>>>> think we need a lot more documentation about the situation.
>>>
>>> It is a platform bug, yes. See my previous email,
>>> https://lore.kernel.org/linux-acpi/d01b0a1f-bd33-47fe-ab41-43843d8a374f@kfocus.org/T/#u
>>> (I meant to send this email as a reply to that one, but failed to do so.)
>>>
>>>> Can you please share more information about your hardware:
>>>> 1) Manufacturer?
>>>
>>> Carbon Systems, models Iridium 14 and Iridium 16.
>>>
>>>> 2) CPU?
>>>
>>> Intel Core i5-13500H.
>>>
>>>> 3) Manufacturer firmware version?
>>>
>>> The systems use an AMI BIOS with version N.1.10CAR01 according to
>>> dmidecode. This is the latest BIOS available from the manufacturer.
>>>
>>>> 4) If it's AMD what's the AGESA version?
>>>
>>> Both affected systems are Intel-based and use heterogenous cores, not AMD.
>>>
>>>> And most importantly do you have the latest system firmware version from
>>>> your manufacturer?  If not; please upgrade that first.
>>>
>>> We are using the latest firmware. (We're trying to work with the ODM to
>>> potentially get a firmware update, but since this affects more than just
>>> us and a firmware update may not be possible for everyone, this would
>>> likely be worth providing a kernel-level workaround for.)
>>>
>>> I can easily provide more detailed information - would the full output of
>>> 'dmidecode' and 'acpidump' be useful?
>>
>> Does your BIOS offer any options for these?
>>
>> Intel(R) SpeedStep(TM)
>> Intel Speed Shift Technology(TM)
>>
>> I believe you need those enabled for this to work properly.
> 
> Neither option is available in the BIOS settings UI, however our ODM
> confirmed that both Intel Speed Shift Technology and Intel Turbo Boost Max
> Technology 3.0 are enabled by default. They did not mention SpeedStep,
> but I assume SpeedStep is working since frequency scaling in general
> works and the kernel patch fixes the issue.

Got it.  If those are enabled I think it would be good to get comments 
from Rafael and Srinivas about your specific situation then.

But regarding the patch, if they are agreeable to this "kind" of knob 
for debugging I personally think it's better to have 
cpc_supported_by_cpu() look at the kernel command line than plumb 
arguments from the module down through every function.

> 
> In case it's helpful to know, when booting without the kernel patch or
> without 'processor.ignore_osc_cppc_bit=1' set, neither of
> '/proc/sys/kernel/sched_itmt_enabled' or
> '/sys/devices/system/cpu/cpu*/acpi_cppc/' exist. When booting with the
> patched kernel and with the kernel parameter set, the 'sched_itmt_enabled'
> file appears and the 'acpi_cppc" directory for each CPU appears.