On Thu, 24 Feb 2022, Sudeep Holla wrote: > On Tue, Feb 22, 2022 at 05:15:49PM +0000, Oleksii Moisieiev wrote: > > Hi Sudeep, > > > > On Tue, Feb 22, 2022 at 04:06:37PM +0000, Sudeep Holla wrote: > > > Hi Oleksii, > > > > > > My initial feedback on this. And thanks Cristian for making it so easy as > > > you have covered most of the things in depth(which I might have not done > > > myself that well) > > > > > > On Tue, Feb 22, 2022 at 11:00:03AM +0000, Cristian Marussi wrote: > > > > On Mon, Feb 21, 2022 at 05:26:46PM +0000, Oleksii Moisieiev wrote: > > > > > Introducing new parameter called scmi_devid to the device-tree bindings. > > > > > This parameter should be set for the device nodes, which has > > > > > clocks/power-domains/resets working through SCMI. > > > > > > I prefer you had given more details on your usage model here instead of > > > pointing to the other Xen thread as it helps for someone without much > > > background on Xen or your use-case to review this. > > > > > Let me describe the process in few words: > > We implemented a new feature, called SCI-mediator in Xen. > > The proposed implementation allows Guests to communicate with the Firmware using SCMI > > protocol with SMC as a transport. Other implementation are also > > possible, such as SCMI-Mailbox, SCPI-mailbox etc. > > > > In this feature Xen is the Trusted Agent, which receives the following > > information in Xen device-tree: > > 1) All channels should be described, each channel defined as > > arm,scmi-shmem node; > > 2) Scmi node arm,scmi-smc with protocols description; > > Sounds good so far. > > > 3) scmi-devid should be set in nodes, which works through SCMI. > > > > Why is this needed for Guest OS, you need not populate this if Guest OS > is not required to use it, right ? If it is needed just by Xen hypervisor, > lets talk about that and why it is bad idea to mix that with general > SCMI bindings. I'll try to help Oleksii by answering here, I hope I am not off the mark :-) I think Sudeep is right, scmi-devid is not needed by the guest OS. The host device tree is a more interesting discussion. As the host device tree is meant to be generic and not tied to a specific version of Linux, it should fully describe the SCMI interface available. If the device tree is provided to a Trusted Agent, then it should also have the scmi-devid information, right? > > On start Xen inits itself as trusted agent and requests agent > > configuration by using BASE_DISCOVER_AGENT message. This message is sent > > to each configured channel to get agent_id > > > > On Domain creation stage Xen will do the following steps: > > 1) Assign channel to the Guest and map channel address to the Domain > > address. For the Domain this address should be the same; > > 2) Generate arm,scmi-shmem and arm,scmi-smc nodes if needed for Guest > > device-tree (the device-tree which should be passed to the Guest); > > 3) Process devices, which are passed through to this Guest and set > > BASE_SET_DEVICE_PERMISSIONS for the scmi-devid, received from the > > device-node; > > > > I am confused here. So the Xen knows which devices are assigned to each > Guest OS but doesn't know device ID for them, but relies on the device > tree node ? Which devices go to which guest OS is a user-provided configuration. For instance, a user can say: "assing /amba/ethernet@ff0e0000 to dom1". This is normal and not related to SCMI: when a user configures a static partitioning system, they decide which resources belong to which domain. So Xen is told that /amba/ethernet@ff0e0000 is supposed to go to dom1. Xen proceeds to map memory and interrupts corresponding to /amba/ethernet@ff0e0000 to dom1. So far so good. What about SCMI? In Oleksii's design, Xen is going to assign one of the available SCMI channels to dom1 and restrict its permission to only /amba/ethernet@ff0e0000. To do that, Xen needs to know the scmi-devid of /amba/ethernet@ff0e0000. As far as I can tell there is nothing Xen-specific in this activitity, that's why I asked Oleksii to reach out to the upstream device tree community to improve the generic bindings for everyone's benefits.
