linux-kernel - Re: [RFC 0/2] "custom" ACPI platform profile 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] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <CAGwozwFW-YfVb-CW0uVuZ4wG+Kw9oZaRNkMAZfjvQC98BYxp8Q@mail.gmail.com>
Date: Thu, 26 Sep 2024 10:40:11 +0200
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Mario Limonciello <superm1@...nel.org>
Cc: Shyam Sundar S K <Shyam-sundar.S-k@....com>,
 "Rafael J . Wysocki" <rafael@...nel.org>,
	Hans de Goede <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	"Luke D . Jones" <luke@...nes.dev>, Mark Pearson <mpearson-lenovo@...ebb.ca>,
	"open list:AMD PMF DRIVER" <platform-driver-x86@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:ACPI" <linux-acpi@...r.kernel.org>,
 "Derek J . Clark" <derekjohn.clark@...il.com>,
	me@...egospodneti.ch, Denis Benato <benato.denis96@...il.com>,
	Mario Limonciello <mario.limonciello@....com>
Subject: Re: [RFC 0/2] "custom" ACPI platform profile support

Hi Mario,
Indeed, the proposal looks good but has a few rough edges that would
make it unsuitable to use currently. Well, for the handheld use-case
at least.

This relates to issues of auto-discovery and how the kernel taint is
applied. For the kernel taint, see my comments on patch 2.

> There are two major ways to tune platform performance in Linux:
>  * ACPI platform profile
>  * Manually tuning APU performance
>
> Changing the ACPI platform profile is a "one stop shop" to change
> performance limits and fan curves all at the same time.

For laptops. A majority of users of handhelds find 3 settings too limiting.

> On AMD systems the manual tuning methods typically involve changing
> values of settings such as fPPT, sPPT or SPL.

Those names are amd-pmf specific and this proposal does not allow for
auto-discovery.

Instead, expose attributes `custom_mode` and `custom_mode_choices`,
that allow for querying the system for available custom modes and
whether userspace can use them.

In this case, the modes for amd-pmf could be `amd-pmf-spl` and `amd-pmf-user`.

`amd-pmf-spl` could export the attrs {spl_min, spl_max, spl} and allow
setting TDP using a slider a la Steam Deck. Here, manufacturers should
be given complete control, e.g., with a LUT and the kernel should not
taint.

`amd-pmf-user` would expose what is shown in this proposal and taint
the kernel. Unfortunately, without manufacturer intervention, this
would be the default for the foreseeable future for boutique devices
(e.g., GPD, OneXPlayer, Ayaneo).

> The problem with changing these settings manually is that the definition
> of the ACPI platform profile if supported by the hardware is no longer
> accurate.  At best this can cause misrepresenting the state of the
> platform to userspace and at worst can cause the state machine into an
> invalid state.
>
> The existence and continued development of projects such as ryzenadj which
> manipulate debugging interfaces show there is a demand for manually tuning
> performance.

-demand- -> requirement. Over 90% of handheld users will end up using a slider.

> Furthermore some systems (such as ASUS and Lenovo handhelds) offer an
> ACPI-WMI interface for changing these settings. If using anything outside
> that WMI interface the state will be wrong.  If using that WMI interface
> the platform profile will be wrong.
>
> This series introduces a "custom" ACPI platform profile and adds support
> for the AMD PMF driver to use it when a user has enabled manual
> adjustments.
>
> If agreeable a similar change should be made to asus-armoury and any other
> drivers that export the ability to change these settings but also a
> platform profile.

Indeed, it would be nice if such a change could be made for all
manufacturer drivers. Much of this proposal would lower the need for
something like asus-armoury, as asus-wmi would be fully capable of
supporting this with few changes and around 70% of the asus-armoury
attrs would then live under /sys/platform.

This also gives us the opportunity for a much needed rename of the variables.

I can speak with the out-of-tree Lenovo Legion Linux's maintainers and
see if they would like to collaborate on this as well.

Antheas