[v4] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support

[RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node for Xen agent

Posted by Oleksii Moisieiev 5 months, 2 weeks ago

From: Grygorii Strashko <grygorii_strashko@epam.com>

Proposal description to add separate SCMI DT node for Xen management agent
under "chosen" or xen-config node, like Hyperlaunch "xen,config".

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.

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.

Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@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
+
+                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.
+
+
+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

Re: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node for Xen agent

Posted by Stefano Stabellini 5 months, 1 week ago

On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> From: Grygorii Strashko <grygorii_strashko@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.


> 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?


> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com>
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@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?


> +                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".


> +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
>

Re: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node for Xen agent

Posted by Oleksii Moisieiev 4 months, 2 weeks ago

On 23/05/2025 23:19, Stefano Stabellini wrote:
> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>> From: Grygorii Strashko<grygorii_strashko@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_strashko@epam.com>
>> Signed-off-by: Oleksii Moisieiev<oleksii_moisieiev@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

Re: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node for Xen agent

Posted by Stefano Stabellini 4 months, 2 weeks ago

On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
> On 23/05/2025 23:19, Stefano Stabellini wrote:
> > On Mon, 19 May 2025, Oleksii Moisieiev wrote:
> >> From: Grygorii Strashko<grygorii_strashko@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.

I don't think this is a good idea because we end up confusing the data
for Xen and the data for the DomUs/Dom0 in the host device tree.

I think we should follow these very simple guidelines:

- The host DTB (the DTB given to Xen at boot) should be the same for Xen
  and for Linux baremetal (no KVM), with the exception of the data under
  the /chosen node

- We can place Xen specific configurations under the /chosen node in the
  host DTB, both Xen hypervisor configuration and also Dom0/DomU
  configurations

This way, the host information remains generic and the configuration for
Xen the domUs/Dom0 is kept clearly separate from the rest. I don't
think we can break these two assumptions but we have more freedom with
the rest.

If we start with these two simple assumptions, here are the
consequences:

- data under /firmware/scmi should be the same for Xen and baremetal
  Linux, ideally it would describe Xen's agent0 channel in both cases

- We can add as many nodes as we like under /chosen, including a
  xen,config node and also additional nodes for the domains config

- We can define the new nodes under /chosen to be as simple as possible
  for the user to configure them, while also trying to minimize
  complexity in Xen in terms of DT manipulations



If the Xen SCMI configuration data cannot be the same as the Linux
baremetal SCMI configuration (i.e. /firmware/scmi has to be different in
the two cases) I would still suggest to avoid modifying /firmware/scmi
for Xen and instead provide the Xen configuration under /chosen. It is
important to keep everything in the host DTB (except /chosen) the same
between Linux baremetal and Xen.

However, we can add a new node similar to /firmware/scmi under /chosen
specifically for Xen, such as /chosen/xen-config/scmi

The Dom0 configuration cannot be expected to be under /firmware/scmi.
However, it could also be defined under /chosen.

Keep in mind that the more we add to /chosen the more difficult it will
be for the user to configure the system. I think we should plan ahead to
have ImageBuilder be able to generate the DT nodes under /chosen for Xen
starting from the simplest possible configuration format provided by the
user. The more complex and rich are the device tree nodes under /chosen,
the more important is the documentation and ImageBuilder support for it.




> >> 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_strashko@epam.com>
> >> Signed-off-by: Oleksii Moisieiev<oleksii_moisieiev@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