On 29/06/2025 21:34, Julien Grall wrote: > 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) > KVM [1] is not applicable here as it starts under/inside Linux, so it doesn't have direct access to SCMI, the Linux does. And Linux will see only one SCMI transport (Agent). Seems, the only option possible is virtio-scmi (qemu) - the virtio-scmi potentially can simulate multi-channel, but this is out if scope of this work.
QNX [0] relies on configuration files rather than the Device Tree. [0] https://www.qnx.com/developers/docs/8.0/com.qnx.doc.hypervisor.user/topic/config/hyp.html [1] https://trueconf.com/blog/knowledge-base/configure-kvm-hypervisor-ubuntu-server#KVM_configuration > 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... > Not aware of any similar task done or in progress. > Cheers, >
