|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node for Xen agent
On 18/06/2025 03:35, Stefano Stabellini wrote:
> 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@xxxxxxxx>
>>>>
>>>> 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
According to the proposal:
The data under the Host DT /firmware/scmi node will always point to the
default OSPM agent, which will remain
the same (smc-id and shmem) for both the BSP case (no Xen) and the Xen
case (Dom0 domain).
Meanwhile, the Xen management agent's SCMI node and configuration are
expected to be placed under /chosen.
This approach ensures that the Host DT remains as unchanged as possible.
Currently:
The Host DT /firmware/scmi node requires modification to point to the
Xen management agent by changing
the smc-id and shmem values.
At boot time, during Dom0 creation, the SCMI multi-agent driver reverts
these changes.
> - 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.
No. The idea is to keep it and provide unchanged, but with possibility
to "disable SCMI for Dom0"
- now with Xen bootarg parameter.
> 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.
>
>
Regarding all the other points you’ve mentioned – this is exactly what
we are trying to achieve
with this proposal.
We are proposing the following changes to the approach so that all
requirements are met, and the
Xen device tree (DT) will remain the same as the Host Platform DT (BSP
Linux), except for the /chosen node:
```
/{
chosen {
...
// Xen SCMI management channel
scmi_shm_xen : sram@47ff1000 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x47ff1000 0x0 0x1000>;
};
scmi_xen: scmi {
compatible = "arm,scmi-smc";
arm,smc-id = <0x82000003>; <--- Xen manegement agent smc-id
#address-cells = < 1>;
#size-cells = < 0>;
#access-controller-cells = < 1>;
shmem = <&scmi_shm_xen>; <--- 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 = <
0x82000002 &scmi_shm 1
0x82000004 &scmi_shm_2 2
0x82000005 &scmi_shm_3 3
0x82000006 &scmi_shm_4 4>;
};
// Host SCMI OSPM channel - provided to the Dom0 as is if SCMI
enabled for it (same address as Host Platform DT)
scmi_shm: sram@47ff0000 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x47ff0000 0x0 0x1000>;
};
firmware { <-- the below configuration is the same as Host
Platform DT and will be passed to Dom0
scmi: scmi {
compatible = "arm,scmi-smc";
arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id
which is the same as in Host Platform DT
#address-cells = < 1>;
#size-cells = < 0>;
shmem = <&scmi_shm>; <--- Host OSPM agent shmem (same
address as Host Platform DT)
protocol@X{
};
};
};
}
```
>>>> 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@xxxxxxxx>
>>>> Signed-off-by: Oleksii Moisieiev<oleksii_moisieiev@xxxxxxxx>
>>>> ---
>>>>
>>>>
>>>>
>>>> .../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?
OSPM is OS in general, for example Linux.
>>> 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |