On 23/05/2025 23:19, Stefano Stabellini wrote:
> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>> From: Grygorii Strashko<grygorii_stras...@epam.com>
>>
>> Proposal description to add separate SCMI DT node for Xen management agent
>> under "chosen" or xen-config node, like Hyperlaunch "xen,config".
> I think it is OK to place a larger "xen,config" node under /chosen with
> more information for Xen to setup SCMI more easily.
>
>
>> This proposal introduces a new approach to the Xen multi-domain
>> configuration, where all Xen-specific configuration has been moved
>> under the "/chosen" node. This requires less Dom0 device tree
>> manipulation and isolates Xen configuration from domain configuration.
>>
>> This approach provides the following device tree (DT) parameters:
>>
>> - "xen,scmi-secondary-agents": A Xen-specific parameter under the
>> "/chosen" node, which describes the SCMI agent configuration for
>> the domains.
>> - the SCMI configuration for Xen (privileged agent) and the shared
>> memory configuration for all agents are provided under the "/chosen"
>> node and are used strictly by Xen for its initial configuration.
>> - the scmi_shm and SCMI configuration for Dom0 are placed in the
>> "/firmware/scmi" node so that they can be moved to Dom0 without
>> any changes.
> Isn't the SCMI configuration present in /firmware/scmi referring to the
> privileged agent=0 meant to be used by Xen?
>
> I certainly see benefits in simplifying the configuration and especially
> reducing the amount of changes a user might have to make on the
> underlying device tree, but if the user needs to change /firmware/scmi
> with the Dom0 information, it seems more dangerous and error prone than
> the previous approach.
>
The idea is to move the privileged agent=0 configuration to the /chosen
node and
assign agent=1 to the Dom0 node under /firmware/scmi.
Benefits of This Approach:
- No Modification of the Xen DT Node Required
This eliminates the need to modify the Xen Device Tree (DT) node
before creating Dom0 in
order to set the correct shared memory (shmem).
-Consistent SCMI Configuration Format
The Dom0 DT will have the same SCMI configuration format as other
domains, simplifying the
overall configuration process.
- Unified SCMI Configuration Method
There will no longer be a need to use a different approach for SCMI
configuration in Dom0
compared to other domains.
- Separation Between Dom0 and Privileged Node
This provides a clear separation between the Dom0 node and the
privileged node.
For example:
If Dom0 only requires the clock protocol, but the Xen SCMI
configuration requires additional protocols,
this approach allows Dom0 to receive only the necessary
protocol configuration.
>> This configuration allows the use of Xen-specific nodes to provide
>> information strictly needed by Xen while using the default SCMI
>> configuration for Dom0 and other domains. As a result, no additional
>> bindings need to be introduced to the device tree.
> This is not actually implemented by this patch series, right?
It is not. Just posted this document as a proposal.
>> Signed-off-by: Grygorii Strashko<grygorii_stras...@epam.com>
>> Signed-off-by: Oleksii Moisieiev<oleksii_moisie...@epam.com>
>> ---
>>
>>
>>
>> .../arm/firmware/arm-scmi-proposal.rst | 224 ++++++++++++++++++
>> 1 file changed, 224 insertions(+)
>> create mode 100644 docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
>>
>> diff --git a/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
>> b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
>> new file mode 100644
>> index 0000000000..fcc2ed2b65
>> --- /dev/null
>> +++ b/docs/hypervisor-guide/arm/firmware/arm-scmi-proposal.rst
>> @@ -0,0 +1,224 @@
>> +
>> +Proposal for SCMI multi-agent driver bindings
>> +=============================================
>> +
>> +Now the Xen configuration for SCMI multi-agent support is done in a bit
>> complicated way, especially
>> +from SCMI multi-agent driver initialization and Dom0 DT manipulation point
>> of view.
>> +Also it does not take into account future requirements to support SCP SCMI
>> FW.
>> +
>> +To enable SCMI multi-agent user need:
>> +
>> +* take host DT with basic SCMI enabled
>> +* add SCMI shared-memory nodes for all agents
>> +* update SCMI node to point on SCMI Xen management channel (``[smc-id,
>> shmem]``)
>> +* add "xen,scmi-secondary-agents" property to the "\chosen" node
>> +
>> +.. code::
>> +
>> + chosen {
>> + xen,scmi-secondary-agents = <
>> + 1 0x82000003 &scmi_shm_1
>> + 2 0x82000004 &scmi_shm_2
>> + 3 0x82000005 &scmi_shm_3
>> + 4 0x82000006 &scmi_shm_4>;
>> + }
>> +
>> + /{
>> + // SCMI shared-memory nodes for all agents
>> + scmi_shm_0 : sram@47ff0000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff0000 0x0 0x1000>;
>> + };
>> + scmi_shm_1: sram@47ff1000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff1000 0x0 0x1000>;
>> + };
>> + scmi_shm_2: sram@47ff2000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff2000 0x0 0x1000>;
>> + };
>> + scmi_shm_3: sram@47ff3000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff3000 0x0 0x1000>;
>> + };
>> + scmi_shm_4: sram@47ff4000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff4000 0x0 0x1000>;
>> + };
>> +
>> + firmware {
>> + scmi: scmi {
>> + compatible = "arm,scmi-smc";
>> + arm, smc - id = <0x82000002>; <--- Xen management agent
>> channel "smc-id"
>> + #address-cells = < 1>;
>> + #size-cells = < 0>;
>> + #access-controller-cells = < 1>;
>> + shmem = <&scmi_shm_0>; <--- Xen management agent
>> channel "shmem"
>> +
>> + protocol@X{
>> + };
>> + };
>> + };
>> + }
>> +
>> +Important thing to note is that all information about multi-channel support
>> is strictly Xen specific.
>> +
>> +During initialization the SCMI multi-agent driver uses Host DT SCMI node and
>> +"xen,scmi-secondary-agents" property to init itself and then, during Dom0
>> creation, manipulates
>> +Dom0 DT to remove Xen specific SCMI info and update dom0 SCMI nodes with
>> Dom0 SCMI agent specific
>> +information.
>> +
>> +There are two negative points:
>> +
>> +1) Double DT modification - one is user to set up SCMI Xen support in Host
>> DT, second -
>> + Dom0 DT manipulation.
>> +2) In case of future support of mailbox shared-memory transport there could
>> be up to 4 mailboxes and
>> + up to 2 shared-memories per SCMI agent channel.
>> +
>> +Hence SCMI multi-agent support is Xen specific knowledge there is a
>> proposal to add it as Xen
>> +specific DT definitions and so minimize Host and Dom0 DT manipulations.
>> +Those definitions can be added in "/chosen" or, ideally, in "xen,config"
>> node (like in Hyperlaunch design).
>> +
>> +The SCMI binding stays generic, just two SCMI nodes defined - one for Xen
>> management channel and
>> +one for Host Dom0 OSPM.
>> +
>> +Example of using "chosen" for configuration:
>> +
>> +.. code::
>> +
>> + /{
>> +
>> + chosen {
>> + ...
>> +
>> + // Xen SCMI management channel
>> + scmi_shm_0 : sram@47ff0000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff0000 0x0 0x1000>;
>> + };
>> + scmi_xen: scmi {
>> + compatible = "arm,scmi-smc";
>> + arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
>> + #address-cells = < 1>;
>> + #size-cells = < 0>;
>> + #access-controller-cells = < 1>;
>> + shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
>> + };
>> +
>> + // SCMI multi-agent configuration
>> + scmi_shm_2: sram@47ff2000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff2000 0x0 0x1000>;
>> + };
>> + scmi_shm_3: sram@47ff3000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff3000 0x0 0x1000>;
>> + };
>> + scmi_shm_4: sram@47ff4000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff4000 0x0 0x1000>;
>> + };
>> + xen,scmi-secondary-agents = <
>> + 1 0x82000003 &scmi_shm
>> + 2 0x82000004 &scmi_shm_2
>> + 3 0x82000005 &scmi_shm_3
>> + 4 0x82000006 &scmi_shm_4>;
>> + };
>> +
>> + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI
>> enabled for it
>> + scmi_shm: sram@47ff1000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff1000 0x0 0x1000>;
>> + };
>> +
>> + firmware {
>> + scmi: scmi {
>> + compatible = "arm,scmi-smc";
>> + arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
>> + #address-cells = < 1>;
>> + #size-cells = < 0>;
>> + shmem = <&scmi_shm>; <--- Host OSPM agent shmem
> By OSPM you mean Dom0 and not Xen? So this is a change compared to a
> device tree for baremetal Linux without Xen?
>
> Let me ask the same question differently. In the case of barematal Linux
> without Xen (no KVM), what would Linux see under /firmware/scmi as
> smc-id and shmem? The same as the one that Xen would use for itself? Or
> the same as the ones that Dom0 would use when Xen is present?
If this DT is used with the baremetal Linux - then the Linux Kernel will
see Dom0 "smc-id" and "shmen" under /firmware/scmi.
>> + protocol@X{
>> + };
>> + };
>> + };
>> + }
>> +
>> +
>> +In the above case:
>> +
>> +1) Xen SCMI multi-agent can be probed with DT configuration from "chosen"
>> (or special "xen,config")
>> + node and all Xen related nodes can be easily dropped from Dom0 DT.
>> +2) Host SCMI OSPM channel DT nodes can be copied to Dom0 DT without changes
>> if SCMI enabled for it.
>> +3) Future support for mailbox shared-memory transport (SCP SCMI FW) can be
>> simplified as no more
>> + manipulation required with Dom0 SCMI "arm,smc-id" and "shmem" DT
>> properties.
> Yes, I can see the benefit if we can arrange it so that the underlying
> host device tree is the same that Linux would use baremetal. And all the
> extra configuration is placed under /chosen in "xen,config" node or
> similar. I would probably call it "xen,scmi".
Personally, I would keep "xen,config" as it leaves room to add additional
configuration nodes in the future.
>> +Example of using "xen,config" for configuration:
>> +
>> +.. code::
>> +
>> + hypervisor {
>> + compatible = “hypervisor,xen”
>> +
>> + // Configuration container
>> + config {
>> + compatible = "xen,config";
>> + ...
>> +
>> + // Xen SCMI management channel
>> + scmi_shm_0 : sram@47ff0000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff0000 0x0 0x1000>;
>> + };
>> + scmi_xen: scmi {
>> + compatible = "arm,scmi-smc";
>> + arm,smc-id = <0x82000002>; <--- Xen manegement agent smc-id
>> + #address-cells = < 1>;
>> + #size-cells = < 0>;
>> + #access-controller-cells = < 1>;
>> + shmem = <&scmi_shm_0>; <--- Xen manegement agent shmem
>> + };
>> +
>> + // SCMI multi-agent configuration
>> + scmi_shm_2: sram@47ff2000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff2000 0x0 0x1000>;
>> + };
>> + scmi_shm_3: sram@47ff3000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff3000 0x0 0x1000>;
>> + };
>> + scmi_shm_4: sram@47ff4000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff4000 0x0 0x1000>;
>> + };
>> + xen,scmi-secondary-agents = <
>> + 1 0x82000003 &scmi_shm
>> + 2 0x82000004 &scmi_shm_2
>> + 3 0x82000005 &scmi_shm_3
>> + 4 0x82000006 &scmi_shm_4>;
>> + };
>> + };
>> +
>> + /{
>> + // Host SCMI OSPM channel - provided to the Dom0 as is if SCMI
>> enabled for it
>> + scmi_shm: sram@47ff1000 {
>> + compatible = "arm,scmi-shmem";
>> + reg = <0x0 0x47ff1000 0x0 0x1000>;
>> + };
>> +
>> + firmware {
>> + scmi: scmi {
>> + compatible = "arm,scmi-smc";
>> + arm,smc-id = <0x82000003>; <--- Host OSPM agent smc-id
>> + #address-cells = < 1>;
>> + #size-cells = < 0>;
>> + shmem = <&scmi_shm>; <--- Host OSPM agent shmem
>> +
>> + protocol@X{
>> + };
>> + };
>> + };
>> + }
>> --
>> 2.34.1
