On Tue, 20 Jan 2026, Oleksii Moisieiev wrote:
> On 19/01/2026 23:12, Stefano Stabellini wrote:
> > On Mon, 19 Jan 2026, Oleksii Moisieiev wrote:
> >> On 16/01/2026 23:21, Stefano Stabellini wrote:
> >>> On Fri, 16 Jan 2026, Oleksii Moisieiev wrote:
> >>>> Hi Stefano,
> >>>> Please see below.
> >>>>
> >>>> On 15/01/2026 03:14, Stefano Stabellini wrote:
> >>>>> Hi Oleksii,
> >>>>>
> >>>>> I am fine with the goals and the strategy to achieve the goals but there
> >>>>> are some finer details that don't make sense to me. I apologize if I am
> >>>>> asking the same questions you have already answered as some time as
> >>>>> passed from the last interaction.
> >>>>>
> >>>>>
> >>>>> On Wed, 14 Jan 2026, Oleksii Moisieiev wrote:
> >>>>>> This patch introduces SCI driver to support for ARM EL3 Trusted
> >>>>>> Firmware-A
> >>>>>> (TF-A) which provides SCMI interface with multi-agent support, as shown
> >>>>>> below.
> >>>>>>
> >>>>>> +-----------------------------------------+
> >>>>>> | |
> >>>>>> | EL3 TF-A SCMI |
> >>>>>> +-------+--+-------+--+-------+--+-------++
> >>>>>> |shmem1 | |shmem0 | |shmem2 | |shmemX |
> >>>>>> +-----+-+ +---+---+ +--+----+ +---+---+
> >>>>>> smc-id1 | | | |
> >>>>>> agent1 | | | |
> >>>>>> +-----v--------+---------+-----------+----+
> >>>>>> | | | | |
> >>>>>> | | | | |
> >>>>>> +--------------+---------+-----------+----+
> >>>>>> smc-id0 | smc-id2| smc-idX|
> >>>>>> agent0 | agent2 | agentX |
> >>>>>> | | |
> >>>>>> +----v---+ +--v-----+ +--v-----+
> >>>>>> | | | | | |
> >>>>>> | Dom0 | | Dom1 | | DomX |
> >>>>>> | | | | | |
> >>>>>> | | | | | |
> >>>>>> +--------+ +--------+ +--------+
> >>>>>>
> >>>>>> The EL3 SCMI multi-agent firmware is expected to provide SCMI SMC
> >>>>>> shared
> >>>>>> memory transport for every Agent in the system.
> >>>>>>
> >>>>>> The SCMI Agent transport channel defined by pair:
> >>>>>> - smc-id: SMC id used for Doorbell
> >>>>>> - shmem: shared memory for messages transfer, Xen page
> >>>>>> aligned. Shared memort is mapped with the following flags:
> >>>>>> MT_DEVICE_nGnRE.
> >>>>>>
> >>>>>> The follwoing SCMI Agents are expected to be defined by SCMI FW to
> >>>>>> enable SCMI
> >>>>>> multi-agent functionality under Xen:
> >>>>>> - Xen management agent: trusted agents that accesses to the Base
> >>>>>> Protocol
> >>>>>> commands to configure agent specific permissions
> >>>>>> - OSPM VM agents: non-trusted agent, one for each Guest domain which is
> >>>>>> allowed direct HW access. At least one OSPM VM agent has to be
> >>>>>> provided
> >>>>>> by FW if HW is handled only by Dom0 or Driver Domain.
> >>>>>>
> >>>>>> The EL3 SCMI FW is expected to implement following Base protocol
> >>>>>> messages:
> >>>>>> - BASE_DISCOVER_AGENT (optional if agent_id was provided)
> >>>>>> - BASE_RESET_AGENT_CONFIGURATION (optional)
> >>>>>> - BASE_SET_DEVICE_PERMISSIONS (optional)
> >>>>>>
> >>>>>> The SCI SCMI SMC multi-agent driver implements following
> >>>>>> functionality:
> >>>>>> - The driver is initialized from the Xen SCMI container
> >>>>>> ``xen_scmi_config``
> >>>>>> (compatible ``xen,sci``) placed under ``/chosen/xen``. Only the
> >>>>>> ``arm,scmi-smc`` node that is a child of this container will bind
> >>>>>> to Xen;
> >>>>>> other SCMI nodes (for example under ``/firmware``) are ignored to
> >>>>>> avoid
> >>>>>> stealing the host OSPM instance.
> >>>>>>
> >>>>>> scmi_shm_1: sram@47ff1000 {
> >>>>>> compatible = "arm,scmi-shmem";
> >>>>>> reg = <0x0 0x47ff1000 0x0 0x1000>;
> >>>>>> };
> >>>>>> scmi_xen: scmi {
> >>>>>> compatible = "arm,scmi-smc";
> >>>>>> arm,smc-id = <0x82000003>; <--- Xen management agent smc-id
> >>>>>> #address-cells = < 1>;
> >>>>>> #size-cells = < 0>;
> >>>>>> #access-controller-cells = < 1>;
> >>>>>> shmem = <&scmi_shm_1>; <--- Xen management agent shmem
> >>>>>> };
> >>>>>>
> >>>>>> - The driver obtains Xen specific SCMI Agent's configuration from the
> >>>>>> Host DT, probes Agents and builds SCMI Agents list. The Agents
> >>>>>> configuration is taken from "scmi-secondary-agents" property where
> >>>>>> first item is "arm,smc-id", second - "arm,scmi-shmem" phandle and
> >>>>>> third is optional "agent_id":
> >>>>>>
> >>>>>> / {
> >>>>>> chosen {
> >>>>>> xen {
> >>>>>> ranges;
> >>>>>> xen_scmi_config {
> >>>>>> compatible = "xen,sci";
> >>>>>> #address-cells = <2>;
> >>>>>> #size-cells = <2>;
> >>>>>> ranges;
> >>>>>>
> >>>>>> scmi_shm_0: sram@47ff0000 {
> >>>>>> compatible = "arm,scmi-shmem";
> >>>>>> reg = <0x0 0x47ff0000 0x0 0x1000>;
> >>>>>> };
> >>>>>>
> >>>>>> /* Xen SCMI management channel */
> >>>>>> 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-secondary-agents = <
> >>>>>> 0x82000002 &scmi_shm_0 0
> >>>>> 0x82000002 is the same func_id as...
> >>>>>
> >>>>>
> >>>>>> 0x82000004 &scmi_shm_2 2
> >>>>>> 0x82000005 &scmi_shm_3 3>; <--- func_id, shmem, agent_id
> >>>>>> #scmi-secondary-agents-cells = <3>;
> >>>>>>
> >>>>>> scmi_xen: scmi {
> >>>>>> compatible = "arm,scmi-smc";
> >>>>>> arm,smc-id = <0x82000002>; <--- Xen management agent
> >>>>>> func_id
> >>>>> as the one used for Xen. This cannot be right?
> >>>>>
> >>>> That's right. Here should be 0x82000003.
> >>>>>> #address-cells = <1>;
> >>>>>> #size-cells = <0>;
> >>>>>> #access-controller-cells = <1>;
> >>>>>> shmem = <&scmi_shm_1>; <--- Xen management agent shmem
> >>>>>> };
> >>>>>> };
> >>>>>> };
> >>>>>> };
> >>>>>> };
> >>>>>>
> >>>>>> / {
> >>>>>> /*
> >>>>>> * Host SCMI OSPM channel - provided to the Dom0 as is if SCMI
> >>>>>> * enabled for it, ignored by Xen multi-agent mediator
> >>>>>> */
> >>>>>> scmi_shm: sram@47ff0000 {
> >>>>>> compatible = "arm,scmi-shmem";
> >>>>>> reg = <0x0 0x47ff0000 0x0 0x1000>;
> >>>>>> };
> >>>>> this is the same as &scmi_shm_0 which I guess is intended?
> >>>>>
> >>>> it is. to match Host DT.
> >>>>>> firmware {
> >>>>>> scmi: scmi {
> >>>>>> compatible = "arm,scmi-smc";
> >>>>>> arm,smc-id = <0x82000002>; <--- Host OSPM agent smc-id
> >>>>> but this again is the same smc-id meant to be used by Xen.
> >>>>>
> >>>>> If 0x82000002 is the privileged interface, then it is OK for Xen and
> >>>>> also baremetal Linux to use it, but Linux Dom0 should not be using it?
> >>>>> Or is the smc-id interchangeable and not necessarily tied to the
> >>>>> agent-id?
> >>>>>
> >>>>> I think either way this detail should be clarified in the docs. Speaking
> >>>>> of docs, the next patch introducing the doc is not up-to-date with this
> >>>>> patch.
> >>>>>
> >>>> In my current configuration, I have the following setup:
> >>>>
> >>>> The Xen privileged interface operates through func_id 0x82000003.
> >>>> func_id 0x82000002 is used for Domain-0, in order to keep the Device
> >>>> Tree (DT) consistent between Xen and bare-metal configurations.
> >>>> I am unsure how best to document this, since the implementation does
> >>>> not strictly require this specific configuration and allows flexibility
> >>>> for the
> >>>> end user. My intention is to provide an example configuration in the DT
> >>>> examples that is most likely to be used as a reference for real-world
> >>>> setups.
> >>> Yes, I am aligned with that
> >>>
> >>>
> >>>> At this stage, I believe the most appropriate approach is to include a
> >>>> note
> >>>> in the documentation stating that the examples illustrate a configuration
> >>>> that aligns well with the Xen architecture, but other configurations are
> >>>> possible depending on user requirements.
> >>> Yes. The important detail is to explain that the same configuration
> >>> works for both Linux baremetal and Linux Dom0. In the Linux Dom0 case,
> >>> the privileged SCMI connection differs from the one of Linux Dom0 and it
> >>> is the one used by Xen.
> >>>
> >>> Baremetal Linux: func_id 0x82000002, scmi-shmem 0x47ff0000
> >>> Dom0 Linux: func_id 0x82000002, scmi-shmem 0x47ff0000
> >>> Xen: func_id 0x82000003, scmi-shmem 0x47ff1000
> >>>
> >>> This works because, I am guessing, the privileged SCMI connection is not
> >>> tied to func_id 0x82000002, scmi-shmem 0x47ff0000.
> >>>
> >>> The problem occurs when there can be only one privileged SCMI connection
> >>> and it is tied to func_id 0x82000002, scmi-shmem 0x47ff0000 which is the
> >>> one described in the Host DT. In which case, Linux Dom0 ends up with the
> >>> privileged connection, not Xen.
> >>>
> >>> I think we should explain why this problem does not occur.
> >>>
> >>>
> >>>>>> #address-cells = < 1>;
> >>>>>> #size-cells = < 0>;
> >>>>>> shmem = <&scmi_shm>; <--- Host OSPM agent shmem
> >>>>>>
> >>>>>> protocol@X{
> >>>>>> };
> >>>>>> };
> >>>>>> };
> >>>>>> };
> >>>>>>
> >>>>>> This approach allows defining multiple SCMI Agents by adding
> >>>>>> Xen-specific properties under the ``/chosen`` node to the Host Device
> >>>>>> Tree, leaving the main part unchanged. The Host DT SCMI channel will
> >>>>>> be passed to Dom0.
> >>>>>>
> >>>>>> The Xen management agent is described as a ``scmi_xen`` node under the
> >>>>>> ``xen,sci`` comaptible node, which is used by Xen to control other
> >>>>>> SCMI Agents in the system.
> >>>>>>
> >>>>>> All secondary agents' configurations are provided in the
> >>>>>> ``scmi-secondary-agents`` property with an optional ``agent_id`` field.
> >>>>>>
> >>>>>> The ``agent_id`` from the ``scmi-secondary-agents`` property is used
> >>>>>> to identify the agent in the system and can be omitted by setting
> >>>>>> ``#scmi-secondary-agents-cells = <2>``, so the Secondary Agents
> >>>>>> configuration will look like this:
> >>>>>>
> >>>>>> / {
> >>>>>> chosen {
> >>>>>> xen {
> >>>>>> xen_scmi_config {
> >>>>>> compatible = "xen,sci";
> >>>>>> #address-cells = <2>;
> >>>>>> #size-cells = <2>;
> >>>>>> ranges;
> >>>>>>
> >>>>>> /* Shared memory nodes as defined earlier */
> >>>>>>
> >>>>>> scmi-secondary-agents = <
> >>>>>> 0x82000003 &scmi_shm_0
> >>>>>> 0x82000004 &scmi_shm_2
> >>>>>> 0x82000005 &scmi_shm_3
> >>>>>> 0x82000006 &scmi_shm_4>;
> >>>>>> #scmi-secondary-agents-cells = <2>;
> >>>>>> };
> >>>>>> };
> >>>>>> };
> >>>>>> }
> >>>>>>
> >>>>>> In this case, Xen will use the ``SCMI_BASE_DISCOVER_AGENT`` call to
> >>>>>> discover the ``agent_id`` for each secondary agent. Providing the
> >>>>>> ``agent_id`` in the ``scmi-secondary-agents`` property allows skipping
> >>>>>> the discovery call, which is useful when the secondary agent's shared
> >>>>>> memory is not accessible by Xen or when boot time is important because
> >>>>>> it allows skipping the agent discovery procedure.
> >>>>>>
> >>>>>> Note that Xen is the only one entry in the system which need to
> >>>>>> know
> >>>>>> about SCMI multi-agent support.
> >>>>>>
> >>>>>> - It implements the SCI subsystem interface required for configuring
> >>>>>> and
> >>>>>> enabling SCMI functionality for Dom0/hwdom and Guest domains. To enable
> >>>>>> SCMI functionality for domain it has to be configured with unique
> >>>>>> supported
> >>>>>> SCMI Agent_id and use corresponding SCMI SMC shared memory transport
> >>>>>> [smc-id, shmem] defined for this SCMI Agent_id.
> >>>>>> - Once Xen domain is configured it can communicate with EL3 SCMI FW:
> >>>>>> -- zero-copy, the guest domain puts SCMI message in shmem;
> >>>>>> -- the guest triggers SMC exception with smc-id (doorbell);
> >>>>>> -- the Xen driver catches exception, do checks and synchronously
> >>>>>> forwards
> >>>>>> it to EL3 FW.
> >>>>>> - the Xen driver sends BASE_RESET_AGENT_CONFIGURATION message to Xen
> >>>>>> management agent channel on domain destroy event. This allows to
> >>>>>> reset
> >>>>>> resources used by domain and so implement use-case like domain
> >>>>>> reboot.
> >>>>>>
> >>>>>> Dom0 Enable SCMI SMC:
> >>>>>> - pass dom0_scmi_agent_id=<agent_id> in Xen command line. if not
> >>>>>> provided
> >>>>>> SCMI will be disabled for Dom0 and all SCMI nodes removed from
> >>>>>> Dom0 DT.
> >>>>>> The driver updates Dom0 DT SCMI node "arm,smc-id" value and fix
> >>>>>> up shmem
> >>>>>> node according to assigned agent_id.
> >>>>> Given that everything else, the entire configuration, is based on device
> >>>>> tree, I think it makes sense to also configure this via device tree
> >>>>> instead of a command line.
> >>>>>
> >>>>> This could be another parameter under xen_scmi_config. What do you
> >>>>> think?
> >>>>>
> >>>> The ``dom0_scmi_agent_id`` parameter was introduced to keep the Dom0
> >>>> configuration separate from the xen_scmi_config node, which is intended
> >>>> specifically for Xen SCMI configuration. In my opinion, adding
> >>>> Dom0-specific
> >>>> configuration to xen_scmi_config would mix the purposes of the node and
> >>>> reduce clarity.
> >>>>
> >>>> Additionally, the ``dom0_scmi_agent_id`` parameter is similar to the
> >>>> ``agent_id`` parameter used for arm_sci in xl.cfg. This approach ensures
> >>>> that
> >>>> the Dom0 configuration is as consistent as possible with the
> >>>> configuration for
> >>>> other domains.
> >>>>
> >>>> Overall, I believe this makes the configuration less confusing, as it
> >>>> allows
> >>>> us to set similar parameters for both Dom0 and other domains in a clear
> >>>> and organized manner.
> >>> We are heading in a direction where Dom0 has its own separate domain
> >>> node similarly to other Dom0less domains. Many of these changes have
> >>> already been committed as part of Hardware Domain / Control Domain
> >>> separation work by Jason.
> >>>
> >>> In a world where Dom0, like other DomUs, has its own configuration node
> >>> and also Dom0 can be split between Hardware Domain and Control Domain,
> >>> it doesn't make sense to use Dom0 command line options anymore. It is
> >>> already possible to assign Dom0 "powers" to a dom0less domain for
> >>> example.
> >>>
> >>> I can see it is worth discussing command line options for dom0 in
> >>> situations where Device Tree might not be present (datacenter
> >>> configuration on ACPI system) but in this case where Device Tree changes
> >>> are required, I think it doesn't make sense to add Dom0 command line
> >>> options as they are less flexible and a duplicate of other options we
> >>> must have anyway.
> >> That makes sense to me. Since we are moving to the Dom0 Device Tree
> >> configuration,
> >> I can move ``dom0_scmi_agent_id`` inside the ``xen,sci`` node and rename
> >> it as the
> >> ``agent_id`` property.
> >>
> >> Would you recommend dropping the ``dom0_scmi_agent_id`` command line
> >> parameter
> >> entirely, or should I keep it as a backup option?
> > I would drop the command line parameter entirely
> I would like to add one more observation from my
> implementation experience:
>
> The main difference between Dom0 and dom0less configurations is that,
> for dom0less, we have a separate node for each domain, for example:
>
> Dom0less configuration:
>
> xen,domain@1 {
> compatible = "xen,domain";
> xen,sci_type = "scmi_smc_multiagent";
> xen,sci-agent-id = <2>;
> /* other domain properties here */
> };
>
> However, for Dom0, we only have the following node:
>
> chosen {
> xen {
> ranges;
> xen_scmi_config {
> compatible = "xen,sci";
> ....
> };
> };
> };
>
> which describes the SCI configuration for Xen.
>
> Therefore, I believe that using the property name
> ``agent_id``` could be confusing in this context.
> I suggest naming it xen,dom0-sci-agent-id instead.
>
> The device tree would then look like this:
> chosen {
> xen {
> ranges;
> xen_scmi_config {
> compatible = "xen,sci";
> ....
> xen,dom0-sci-agent-id = <0>; /* Dom0 agent ID */ <-----
> };
> };
> };
>
> Does this approach look good to you?
Yes, it look OK.
It is already possible to create a dom0less device tree node for Dom0,
simply by using capabilities. However, the older device tree bindings
where dom0 doesn't have a node is also still supported and for that it
makes sense to introduce xen,dom0-sci-agent-id.
