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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

On 25/06/2025 23:32, Julien Grall wrote:
> Hi Oleksii,
>
> On 25/06/2025 20:47, Oleksii Moisieiev wrote:
>>
>> On 23/06/2025 11:02, Julien Grall wrote:
>>> I am probably missing something. But it looks like TF-A requires to
>>> suport multi-agent so Xen can use it. Am I correct?
>>>
>>> Furthermore, I can't tell why the multi-agent support is Xen specific.
>>> Surely, you may want something similar with other hypervisors? If not,
>>> then my next question is why does Xen needs to do things differently?
>>>
>>> Cheers,
>>>
>>
>> Yes, multi-agent support is required in TF-A for Xen, but this is not
>> specific to Xen.
>
> I am really confused. If the support is not Xen specific then why do
> we end up to have xen specific node/properties in your proposal (see
> [1]) such as xen,scmi-secondary-agents.
>
Sorry, for confusion. Some additional explanation is below.

All this is about the case when Host platform doesn't have SCP and SCMI
implemented in EL2 Firmware (TF-A).

The SCMI standard defines multi-agent support (as many other features),
but it is Optional.
Also SCMI standard doesn't define how its features has to be implemented
internally, just defines standard interface (API/HAL) to access them.
More over, even "shared-ram" Transport implementation is not strictly
standardized, for example in terms of
"shared-ram" base address alignment.

In most of the cases, SoC Vendors (if we are lucky) provide BSP with EL2
SCMI FW which implements
one SCMI transport and, so supports only one Agent which, in general,
has access to all resources.
Such EL2 SCMI FW is NOT virtualization (Xen) aware, so only "Simple SCMI
over SMC/HVC calls forwarding driver (EL3)" (CONFIG_SCMI_SMC)
can be used out of the box to enable SCMI in Hardware domain (or, with
patches 1-3 of this series, in Driver domain).

So, to have SCMI multi-channel features enabled with EL2 SCMI FW - it
has some SCMI features to be implemented
(which otherwise optional), including defining additional Transport
channels (Agents), shmem alignment on Xen page boundary,..
The requirements for EL2 SCMI FW is described in SCMI documentation [2].
And generic answer on your question above "I am probably missing
something. But it looks like TF-A requires to
suport multi-agent so Xen can use it. Am I correct?" would be Yes.

[1]
https://github.com/oleksiimoisieiev/xen/blob/scmi_upstrv5/docs/hypervisor-guide/arm/firmware/arm-scmi.rst#simple-scmi-over-smchvc-calls-forwarding-driver-el3

[2]
https://github.com/oleksiimoisieiev/xen/blob/scmi_upstrv5/docs/hypervisor-guide/arm/firmware/arm-scmi.rst#scmi-smchvc-multi-agent-driver-el3




-----
SCMI SCP Note. When Host platform support SCP the multi-agent support
will be in place, as
in such cases separate SCMI transport is allocated for at least each
Application processor (AP) which is defined as SCMI Agent.
For example, Core-R(s) (like Cortex-R/M), DSPs, Core-A (Cortex-A - here
the Xen is usually running).
No Agents in the system knows about each other. Only SCP FW does.

And even in this case, the BSP SCP FW might NOT be virtualization (Xen)
aware as only one Transport (Agent)
is provided for Core-A (actually two - one Secure for PSCI, and one
non-secure - for OSPM).
---

In the Virtualized system:

- The Xen is real OSPM which manages other Virtual OSPM and it needs
dedicated SCMI management channel through which
  it can perform HW resources assignment for Virtual OSPM by
communicating with EL2 SCMI FW
  during Virtual OSPM creation or release HW resources during Virtual
OSPM destruction.
  In the future it also possible to enable such PM feature as SCMI based
CpuFreq in Xen.

  The SCMI DT binding for Xen SCMI Agent expected to be exactly the same
as for any OSPM (like Linux) as from
  SCMI FW point of few it is just OS running on Application Core (which
substitutes regular OS - Linux, RTOS).
  So no new SCMI specific bindings (including compatibilities)
introduced neither in this series nor in this proposal.

  In other words, Xen needs two DT to boot, kinda:
  - Xen DT (with bootinfo, Application Core info, uart)
  - Host Platform DT (source information to create domains)
   and if there would be two separate DTs - each will have own standard
(bindings) DT SCMI node.
According to the current design Xen accepts DT which is Host Platform DT
with added Xen configuration so Xen SCMI info is added in Xen
configuration node under /chosen, and no Domains is expected to see it
ever. After Xen initialization DT nodes from Xen DT are copied to the
Dom0 device tree. Our proposal is to keep SCMI configuration from
Platform Host DT the  same so it will be copied to the Dom0 device tree.


- the number of Virtual Machines or Virtual OSPMs (in terms of SCMI)
depends on hypervisor (Xen) configuration.
  And Virtual OSPM is defined as VM which has direct access to HW
(passthrough), so need access
  SCMI services to get fine-grained and safe access to required Platform
HW resources, and avoid interference.

  Every Virtual OSPM is SCMI agent, which sees it's own SCMI transport,
and doesn't know about other agents.
  In the case of DT - the standard SCMI bindings are used.

- So the Xen is the only entity in the platform which need to know about
other Agents.
   Therefore, this Xen specific configuration "xen,scmi-secondary-agents",
   for the case of the EL2 SCMI FW, is introduced and added under the
/chosen node (or xen-config).
   Unfortunately, there is no way to discover Agent's configurations
using SCMI protocol (base), like "func-id"
   and shmem parameter (only can get Number of Agents, and discover own
Agent id), so only option is to
   define this info in DT for Xen. However, Xen can use shared memory
regions and func_ids of the other Agents to   determine agent_id using
base protocol. That's why it was decided to make agent_id in
"xem,scmi-secondary-agents" optional.
> I also question the placement of the SMCI multi-agent in /chosen. For
> me /chosen is for configuration related to the hypervisor/OS. But
> here, it seems the multi-agent SMCI is related to the platform.
>

 From SCMI point of view the Xen is separate OSPM (SCMI Agent), which
have own boot configuration data, in case of ARM - Device-tree.
The SCMI doesn't see the difference between Linux or Xen running on
Application processor.
They are both OSPM (Agents), but with different privileges and permissions.

As was stated before from Xen standpoint the device tree should be same
as Host DT with Xen
configuration placed under /chosen node. So agent_id dedicated to Xen
should be in xen configuration node.

The Host platform (BSP) will run using Host DT with Xen DT data removed and
doesn't need to know about Xen SCMI management channel (agent) or agents
available for Virtual OSPMs (VMs).

For Xen to run with SCMI multi-channel support - Xen specific DT data has
to be added under /chosen which includes Xen specific SCMI data.
> So wouldn't it be better to create a new compatible arm,smci-multi
> that will include the information for multi? An alternative would be
> to extend the existing SCMI node in a backward compatible way.
>
> Lastly, I see if you put a node under "/chosen" with "arm,scmi-smc".
> Have you checked this will not confused Linux? I was under the
> impression Linux would look for any node with the compatible when
> initializing a driver.
>
Xen configuration under /chosen will be removed when passing DT to the
Domains.
So Linux domains will not see any Xen configuration data.

When booting Baremetal Xen DT Linux kernel will not parse "arm,scmi-smc"
node under "chosen"  as Linux uses 2 depth level for probing.
And there is no compatible in chosen:

{
    chosen {
     // no compatible - skip
     xen-config {
         compat = "xen,config"; <- no go below as not Bus compat
         scmi {
             <-never get here
         }
     }
    }
}

> Cheers,
>
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2025-06/msg01421.html
>
>