linux-kernel - Using SCMI driver to prepare data for controlling cores via ACPI CPPC (

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 21 Feb 2022 13:39:56 +0000
From:   Szymon Balcerak <sbalcerak@...vell.com>
To:     Szymon Balcerak <sbalcerak@...vell.com>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Wojciech Bartczak <wbartczak@...vell.com>
Subject: Using SCMI driver to prepare data for controlling cores via ACPI CPPC
 (_CPC) and PCCT.

Hi Folks,

This is a continuation of previously discussed topics:
1. "Mixing SCMI and ACPI" topic discussed here https://lore.kernel.org/linux-arm-kernel/20220207101024.rpcbbhtd6y6g7ykc@bogus/T/
2. "ACPI support for System Control and Management Interface (SCMI)" discussed here https://www.spinics.net/lists/arm-kernel/msg798464.html.

We did further research in regards to ACPI specification, SCMI specification and ARM requirements.
Considering above, in ACPI we defined PCCT table together with PCC subspace type 3, according to SCMI specification ("The SCMI transport is represented as a standard ACPI Platform Communications Channel (PCC) of Type 3").
This PCCT table describes "mailbox" between System Control Processor (SCP) and the Application Processors (AP) on our system (i.e. shared memory area, doorbell register, etc.).
As a result PCC kernel driver (drivers/mailbox/pcc.c) was able to gather all required information out of ACPI PCCT table and thus was successfully probed.

We also defined some sample ACPI _CPC objects for each processor core, so that CPPC kernel driver (drivers/cpufreq/cppc_cpufreq.c) could use those information.
Within _CPC object we added specific registers offsets of PCC subspace defined in PCCT (ONLY example: ResourceTemplate(){Register(PCC, 32, 0, 0x124, 0) -> Desired Performance Register})

Having above setup, execution flow for getting desired core performance (drivers/cpufreq/cppc_cpufreq.c -> cppc_get_desired_perf()) would look like:
1. ring the doorbell register (defined in PCCT)
2. wait for command completion indicated within PCC status field (status is part of shared memory defined within PCCT);
3. read the desired performance register (defined in _CPC object as specific PCC register).

Now comes the problem: without preparing valid frame according to SCMI spec we will not get any valid response from SCP, even if we will ring a doorbell.
Considering above, we came to conclusion that existing SCMI kernel driver (drivers/cpufreq/scmi-cpufreq.c) could be used to "prepare" valid SCMI frame and write it to shared memory before ringing the doorbell.
This way SCP could "understand" SCPI request (e.g. get desired performance) and return valid data back within shared memory (within specific offset of PCC subspace).
Do you think it might be a good direction to achieve the goal (monitoring and controlling cores)?

Main problem we currently see is that SCMI kernel driver will never be probed on ACPI systems as first of all arm_scmi (.compatible = "arm,scmi") will never be probed successfully. There is no DT on ACPI system at all.
Do you plan to add ACPI support for arm-scmi, so that it's properly probed on ACPI systems and thus scmi-cpufreq is also probed?

Finally, assuming arm-scmi  and scmi-cpufreq are probed: how could we accomplish preparing SCMI frame before ringing a doorbell?

Thanks,
Szymon