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 14:27:57 -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 14:25, Aaron Rainbolt wrote:
> On Tue, Jun 18, 2024 at 01:58:07PM -0500, Mario Limonciello wrote:
>> 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.
> 
> Just to be clear since I'm not all too familiar with how kernel params work,
> should core_param be used here? Or is there a variable that allows
> accessing the entire command line to look through it? I don't think I can
> use module_param in 'arch/x86/kernel/acpi/cppc.c', core_param has a
> comment over it describing it as "historical" so I don't think I should
> use it, and early_param looks like something one is only supposed to use
> in code that runs very early at kernel startup. I can probably figure it
> out on my own, but a quick pointer would be helpful.

early_param is how I would do it.

You can save it to a static boolean global variable in that file.  Make 
sure that you update documentation about the new early_param though too.