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

[Julien Grall <julien@xxxxxxx>]

Hi Oleksii,

On 29/06/2025 16:41, Oleksii Moisieiev wrote:
> --->
> In the Virtualized system:
Thanks for the long explanation. In this section, you mention Xen all 
over the place. But as you previously agreed the multi-agent SCMI is not 
Xen specific. To put it differently, aside the fact...
>
> - 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.

... the name of this property contains "xen", I still don't understand 
why the binding could not be used by other hypervisors. IOW, what if 
above you s/xen/KVM/ (or any other hypervisor you come up with)? Are 
they all going to create their own bindings? I would guess not given the 
single agent is already generic (if I am not mistaken, both Linux and 
Xen are using it)
I will not insist on moving the binding outside of /chosen if the other 
maintainers think this is the best. But I think this is shortsighted to 
add "xen" in all the name or put it in a Xen specific position.
Ultimately what I want to avoid is we have to support multiple bindings 
in Xen because someone else decided to create a new binding as we didn't 
even attempt to make ours generic...
Cheers,

--
Julien Grall