|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v7 4/5] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver
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?
> However, we can express them in better ways. For instance, we could
> reuse your exiting work to enable dom0less DomUs.
>
> See https://www.youtube.com/watch?v=J6q67jkG5DQ
>
>
>>>> Guest domains enable SCMI SMC:
>>>> - xl.cfg: add configuration option as below
>>>>
>>>> arm_sci = "type=scmi_smc_multiagent,=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).
>>>>
>>>> [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>
>>>> ---
>>>>
>>>> Changes in v7:
>>>> - rework scmi nodes for xen to match on compatible string instead of
>>>> the direct path
>>>>
>>>> Changes in v6:
>>>> - updated scmi-shmem to use io.h from generic location
>>>> - update scmi_agent_id parameter to be provided inside dom0= parameter
>>>> list and have the following format "dom0=sci-agent-id=0"
>>>> This change was done as a response for Stefano comment and
>>>> requires a lot of code changes, but produces much cleaner solution
>>>> that's why I've added it to the code.
>>>> - fix file comments and return codes
>>>> - fix lenght checks in shmem_{get,put}_message to use offsetof
>>>> - remove len member from scmi_channel structure as it is not used
>>>> - set scmi-secondary-agents property to be mandatory since if no
>>>> secondary agents were provided then there is no sence to enable scmi
>>>> when no secondary agents are populated to the Domains
>>>> - update documentation in booting.txt, added xen_scmi node to the
>>>> example
>>>> - adjust d->arch.sci_enabled value in scmi_domain_destroy
>>>> - fix lock management in smc_create_channel call
>>>> - avoid extra map_channel_memory command for Xen management channel
>>>> because collect_agent_id call unmaps memory if DOMID_XEN is not
>>>> set. So for Xen management channel we can init domain_id ad DOMID_XEN
>>>> before calling collect_agent_id so memory shouldn't be unmapped.
>>>>
>>>> Changes in v5:
>>>> - fix device-tree example format in booting.txt, added ";" after "}".
>>>> - update define in scmi-proto.h
>>>> - update define in scmi-shmem.h file
>>>> - scmi_assign_device - do not ignore -EOPNOTSUPP return
>>>> code of the do_smc_xfer
>>>> - remove overwriting agent_channel->agent_id after
>>>> SCMI_BASE_DISCOVER_AGENT call
>>>> - add multi-agent files to the MAINTAINERS
>>>> - add SCMI multi-agent description to the SUPPORT.md
>>>> - handle ARM_SMCCC_INVALID_PARAMETER return code and return -EINVAL
>>>> for smc call
>>>> - updated collect_agents function. Set agent_id parameter as optional
>>>> in scmi-secondary-agents device-tree property
>>>> - introduce "#scmi-secondary-agents-cells" parameter to set if
>>>> agent_id was provided
>>>> - reanme xen,scmi-secondary-agents property to scmi-secondary-agents
>>>> - move memcpu_toio/fromio for the generic place
>>>> - update Xen to get management channel from /chosen/xen,config node
>>>> - get hypervisor channnel from node instead of using hardcoded
>>>> - update handling scmi and shmem nodes for the domain
>>>> - Set multi-agent driver to support only Arm64
>>>>
>>>> Changes in v4:
>>>> - toolstack comments from Anthony PERARD
>>>> - added dom0less support
>>>> - added doc for "xen,scmi-secondary-agents"
>>>>
>>>> MAINTAINERS | 4 +
>>>> SUPPORT.md | 11 +
>>>> docs/man/xl.cfg.5.pod.in | 13 +
>>>> docs/misc/arm/device-tree/booting.txt | 103 +++
>>>> docs/misc/xen-command-line.pandoc | 19 +-
>>>> tools/libs/light/libxl_arm.c | 4 +
>>>> tools/libs/light/libxl_types.idl | 4 +-
>>>> tools/xl/xl_parse.c | 12 +
>>>> xen/arch/arm/dom0less-build.c | 11 +
>>>> xen/arch/arm/domain_build.c | 26 +-
>>>> xen/arch/arm/firmware/Kconfig | 12 +
>>>> xen/arch/arm/firmware/Makefile | 1 +
>>>> xen/arch/arm/firmware/scmi-proto.h | 164 ++++
>>>> xen/arch/arm/firmware/scmi-shmem.c | 115 +++
>>>> xen/arch/arm/firmware/scmi-shmem.h | 45 ++
>>>> xen/arch/arm/firmware/scmi-smc-multiagent.c | 815 ++++++++++++++++++++
>>>> xen/include/public/arch-arm.h | 3 +
>>>> 17 files changed, 1359 insertions(+), 3 deletions(-)
>>>> create mode 100644 xen/arch/arm/firmware/scmi-proto.h
>>>> create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
>>>> create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
>>>> create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index ecd3f40df8..4ad1d818a6 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -532,6 +532,10 @@ R: Oleksii Moisieiev<oleksii_moisieiev@xxxxxxxx>
>>>> S: Supported
>>>> F: xen/arch/arm/firmware/sci.c
>>>> F: xen/arch/arm/include/asm/firmware/sci.h
>>>> +F: xen/arch/arm/firmware/scmi-smc-multiagent.c
>>>> +F: xen/arch/arm/firmware/scmi-shmem.c
>>>> +F: xen/arch/arm/firmware/scmi-shmem.h
>>>> +F: xen/arch/arm/firmware/scmi-proto.h
>>>>
>>>> SEABIOS UPSTREAM
>>>> M: Wei Liu<wl@xxxxxxx>
>>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>>> index 491f9ecd1b..7c8951d67b 100644
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -956,6 +956,17 @@ by hwdom. Some platforms use SCMI for access to
>>>> system-level resources.
>>>>
>>>> Status: Supported
>>>>
>>>> +### Arm: SCMI SMC multi-agent support
>>>> +
>>>> +Enable support for the multi-agent configuration of the EL3 Firmware,
>>>> which
>>>> +allows Xen to provide an SCMI interface to the Domains.
>>>> +Xen manages access permissions to the HW resources and provides an SCMI
>>>> interface
>>>> +to the Domains. Each Domain is represented as a separate Agent, which can
>>>> +communicate with EL3 Firmware using a dedicated shared memory region, and
>>>> +notifications are passed through by Xen.
>>>> +
>>>> + Status, ARM64: Tech Preview
>>>> +
>>>> ### ARM: Guest PSCI support
>>>>
>>>> Emulated PSCI interface exposed to guests. We support all mandatory
>>>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
>>>> index ad1553c5e9..4fc3e12939 100644
>>>> --- a/docs/man/xl.cfg.5.pod.in
>>>> +++ b/docs/man/xl.cfg.5.pod.in
>>>> @@ -3156,8 +3156,21 @@ single SCMI OSPM agent support.
>>>> Should be used together with B<scmi-smc-passthrough> Xen command line
>>>> option.
>>>>
>>>> +=item B<scmi_smc_multiagent>
>>>> +
>>>> +Enables ARM SCMI SMC multi-agent support for the guest by enabling SCMI
>>>> over
>>>> +SMC calls forwarding from domain to the EL3 firmware (like Trusted
>>>> Firmware-A)
>>>> +with a multi SCMI OSPM agent support. The SCMI B<agent_id> should be
>>>> +specified for the guest.
>>>> +
>>>> =back
>>>>
>>>> +=item B<agent_id=NUMBER>
>>>> +
>>>> +Specifies a non-zero ARM SCI agent id for the guest. This option is
>>>> mandatory
>>>> +if the SCMI SMC support is enabled for the guest. The agent ids of domains
>>>> +existing on a single host must be unique and in the range [1..255].
>>>> +
>>>> =back
>>>>
>>>> =back
>>>> diff --git a/docs/misc/arm/device-tree/booting.txt
>>>> b/docs/misc/arm/device-tree/booting.txt
>>>> index 977b428608..6fd7e4a16b 100644
>>>> --- a/docs/misc/arm/device-tree/booting.txt
>>>> +++ b/docs/misc/arm/device-tree/booting.txt
>>>> @@ -322,6 +322,20 @@ with the following properties:
>>>> Should be used together with scmi-smc-passthrough Xen command line
>>>> option.
>>>>
>>>> + - "scmi_smc_multiagent"
>>>> +
>>>> + Enables ARM SCMI SMC multi-agent support for the guest by enabling
>>>> SCMI over
>>>> + SMC calls forwarding from domain to the EL3 firmware (like ARM
>>>> + Trusted Firmware-A) with a multi SCMI OSPM agent support.
>>>> + The SCMI agent_id should be specified for the guest with
>>>> "xen,sci-agent-id"
>>>> + property.
>>>> +
>>>> +- "xen,sci-agent-id"
>>>> +
>>>> + Specifies ARM SCMI agent id for the guest. This option is mandatory
>>>> if the
>>>> + SCMI SMC "scmi_smc_multiagent" support is enabled for the guest. The
>>>> agent ids
>>>> + of guest must be unique and in the range [0..255].
>>> these two don't seem to be in the commit message examples
>>>
>>>
>> ``scmi_smc_multiagent`` mentioned in the commit message at the following
>> part:
>>
>> > - xl.cfg: add configuration option as below
>> > arm_sci = "type=scmi_smc_multiagent,agent_id=2"
>>
>> ``xen,sci-agent-id`` is used for dom0less. It described in arm-scmi.rst
>> file which was presented in the next commit.
> All device tree options should be described
> docs/misc/arm/device-tree/booting.txt, even if they are similar to other
> options described elsewhere. This is similar to the way all Xen command
> line options should be described in docs/misc/xen-command-line.pandoc
>
>
>>>> Under the "xen,domain" compatible node, one or more sub-nodes are
>>>> present
>>>> for the DomU kernel and ramdisk.
>>>>
>>>> @@ -824,3 +838,92 @@ The automatically allocated static shared memory will
>>>> get mapped at
>>>> 0x80000000 in DomU1 guest physical address space, and at 0x90000000 in
>>>> DomU2
>>>> guest physical address space. DomU1 is explicitly defined as the owner
>>>> domain,
>>>> and DomU2 is the borrower domain.
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |