Re: [PATCH v15 4/6] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver

[Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>]

Hi Oleksii,

Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx> writes:

> 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 memory is mapped with the following flags:
>  MT_DEVICE_nGnRE.
>
> The following 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 (required for Xen and secondary agents without reg)
> - BASE_RESET_AGENT_CONFIGURATION (optional)
> - BASE_SET_DEVICE_PERMISSIONS (optional)
>
> The driver binds to the arm,scmi-smc management node inside a Xen-specific
> container compatible with xen,sci under /chosen/xen. Other SCMI nodes,
> including the host /firmware/scmi, are ignored by the mediator.
>
> Describe secondary agents as xen,scmi-agent children of an agents node
> inside the same container. The agents node uses #address-cells = <1> and
> `#size-cells = <0>`. Each child provides arm,smc-id and a single shmem 
> phandle.
> The optional single-cell reg property supplies the SCMI agent ID (0..254).
> When reg is absent, Xen discovers the ID using BASE_DISCOVER_AGENT on that
> channel. Use agent@<id> for an explicit ID, and a node name without a unit
> address for discovery. Disabled agent nodes are ignored; at least one
> enabled secondary agent is required.
>
> Resolve discovered IDs before adding channels to the list, so duplicate
> IDs are rejected consistently, including clashes with Xen's management
> agent. Explicit IDs avoid mapping and probing secondary channels during
> initialization. Xen always discovers its own management agent ID.
>
> Keep shared-memory nodes under xen_scmi_config and leave the platform's
> existing /firmware/scmi and host OSPM shared-memory node unchanged. Channel
> nodes describe locations, rather than reserve memory: if firmware buffers
> occupy system RAM, the platform DT must reserve the whole firmware-owned
> range in /reserved-memory before Xen boots. A single reservation may cover
> multiple channels, including unused ones. SRAM outside system RAM does
> not require a RAM reservation. Channel nodes need not be moved into
> /reserved-memory.
>
> For example:
>
> / {
>     #address-cells = <2>;
>     #size-cells = <2>;
>
>     scmi_shm_0: sram@47ff0000 {
>         compatible = "arm,scmi-shmem";
>         reg = <0x0 0x47ff0000 0x0 0x1000>;
>     };
>
>     firmware {
>         scmi: scmi {
>             compatible = "arm,scmi-smc";
>             arm,smc-id = <0x82000002>;
>             #address-cells = <1>;
>             #size-cells = <0>;
>             shmem = <&scmi_shm_0>;
>         };
>     };
>
>     chosen {
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges;
>
>         xen {
>             #address-cells = <2>;
>             #size-cells = <2>;
>             ranges;
>
>             xen_scmi_config {
>                 compatible = "xen,sci";
>                 #address-cells = <2>;
>                 #size-cells = <2>;
>                 ranges;
>                 xen,dom0-sci-agent-id = <0>;
>
>                 /* Xen 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_xen: scmi {
>                     compatible = "arm,scmi-smc";
>                     arm,smc-id = <0x82000003>;
>                     #address-cells = <1>;
>                     #size-cells = <0>;
>                     #access-controller-cells = <1>;
>                     shmem = <&scmi_shm_1>;
>                 };
>
>                 agents {
>                     #address-cells = <1>;
>                     #size-cells = <0>;
>
>                     agent@0 {
>                         compatible = "xen,scmi-agent";
>                         reg = <0>;
>                         arm,smc-id = <0x82000002>;
>                         shmem = <&scmi_shm_0>;
>                     };
>
>                     agent@2 {
>                         compatible = "xen,scmi-agent";
>                         reg = <2>;
>                         arm,smc-id = <0x82000004>;
>                         shmem = <&scmi_shm_2>;
>                     };
>
>                     agent@3 {
>                         compatible = "xen,scmi-agent";
>                         reg = <3>;
>                         arm,smc-id = <0x82000005>;
>                         shmem = <&scmi_shm_3>;
>                     };
>                 };
>             };
>         };
>     };
> };
>
> To discover a secondary agent ID instead, omit reg from its node:
>
>     agent-domu {
>         compatible = "xen,scmi-agent";
>         arm,smc-id = <0x82000004>;
>         shmem = <&scmi_shm_2>;
>     };
>
> The agents child nodes replace the former scmi-secondary-agents list and
> `#scmi-secondary-agents-cells` property. The xen,sci subtree is omitted from
> Dom0's DT; the host OSPM channel is passed through when SCMI is enabled
> for Dom0. Full configuration and domain examples are included in the
> binding documentation and the hypervisor guide in patch 6.
>
> SMC ID Configuration and SCMI Connection Compatibility:
>
> The configuration allows the same device tree to work for both baremetal
> Linux and Linux Dom0. This is achieved because:
>
> - Baremetal Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000
> - Dom0 Linux uses: func_id 0x82000002, scmi-shmem 0x47ff0000
> - Xen management uses: func_id 0x82000003, scmi-shmem 0x47ff1000
>
> This works because the privileged SCMI connection in EL3 firmware is not
> tied exclusively to func_id 0x82000002. The EL3 firmware supports multiple
> SCMI agents with different SMC IDs and shared memory regions. Each agent
> (Dom0 via 0x82000002, Xen via 0x82000003, other domains via additional
> func_ids) has an independent communication channel to the firmware.
>
> The key distinction is that Xen's management channel (0x82000003) is used
> for privileged operations like agent configuration and device permissions
> (BASE_SET_DEVICE_PERMISSIONS, BASE_RESET_AGENT_CONFIGURATION), while Dom0's
> channel (0x82000002) is used for standard SCMI protocol operations (power,
> clock, sensor management, etc.). The firmware enforces different permission
> levels for each agent based on their agent_id, not the SMC ID.
>
> Therefore, there is no conflict: Linux Dom0 retains its standard SCMI
> connection for hardware management, while Xen uses its separate privileged
> channel for mediating access between multiple domains.
>
> - 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:
>  - set xen,dom0-sci-agent-id=<agent_id> under the xen,sci container in
>    the Host DT. If the property is absent, SCMI is disabled for Dom0
>    and all SCMI nodes are removed from the Dom0 DT. The driver updates
>    the Dom0 DT SCMI node "arm,smc-id" value and fixes up the shmem
>    node according to the assigned agent_id.
>
>  - pass dom0=sci-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.
>
> Guest domains enable SCMI SMC:
>  - xl.cfg: add configuration option as below
>
>    arm_sci = "type=scmi_smc_multiagent,agent_id=2"
>
>  - xl.cfg: enable access to the "arm,scmi-shmem" which should
>  correspond assigned agent_id for the domain, for example:
>
> iomem = [
>     "47ff2,1@22001",
> ]
>
>  - DT: add SCMI nodes to the Driver domain partial device tree as in the
>  below example. The "arm,smc-id" should correspond assigned agent_id
>  for the domain:
>
> passthrough {
>    scmi_shm_0: sram@22001000 {
>        compatible = "arm,scmi-shmem";
>        reg = <0x0 0x22001000 0x0 0x1000>;
>    };
>
>    firmware {
>         compatible = "simple-bus";
>             scmi: scmi {
>                 compatible = "arm,scmi-smc";
>                 arm,smc-id = <0x82000004>;
>                 shmem = <&scmi_shm_0>;
>                 ...
>             }
>     }
> }
>
> SCMI "4.2.1.1 Device specific access control"
>
> The XEN SCI SCMI SMC multi-agent driver performs "access-controller"
> provider function in case EL3 SCMI FW implements SCMI "4.2.1.1 Device
> specific access control" and provides the BASE_SET_DEVICE_PERMISSIONS
> command to configure the devices that an agents have access to.
> The DT SCMI node should "#access-controller-cells=<1>" property and DT
> devices should be bound to the Xen SCMI.
>
> &i2c1 {
>         access-controllers = <&scmi 0>;
> };
>
> The Dom0 and dom0less domains DT devices will be processed
> automatically through sci_assign_dt_device() call, but to assign SCMI
> devices from toolstack the xl.cfg:"dtdev" property
> shall be used:
>
> dtdev = [
>     "/soc/i2c@e6508000",
> ]
>
> xl.cfg:dtdev will contain all nodes which are under SCMI
> management (not only those which are behind IOMMU).
>
> Additionally, this patch adds documentation for the pre-existing
> scmi-smc-passthrough command line option, which was previously
> undocumented.
>
> [0] https://developer.arm.com/documentation/den0056
> [1] 
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> [2] 
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml
>
> Signed-off-by: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>

Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>

[...]


--
WBR, Volodymyr