|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver
On 23/06/2025 01:15, Stefano Stabellini wrote: > On Thu, 19 Jun 2025, Oleksii Moisieiev wrote: >> On 18/06/2025 02:22, Stefano Stabellini wrote: >>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote: [snip] >>>>> Are you sure it is worth to go through all this trouble to modify FDT in >>>>> place when we could simply generate the DT node from scratch like we do >>>>> for example for the GIC? This seems to be more error prone as well. Is >>>>> generating it from scratch is really difficult? If it is difficult then >>>>> OK. >>>>> >>>> In the last patch [0] of the series, there is a proposal to separate >>>> >>>> the Xen privileged agent from the Dom0 agent. This eliminates the >>>> >>>> need to modify the Xen Device Tree Blob (DTB), which is a positive >>>> improvement >>>> >>>> since the Dom0 agent node is already present in the device tree. >>>> >>>> However, the issue with SCMI node generation lies in the need to handle >>>> >>>> the list of protocols that are supported across the system. >>>> >>>> If we want to generate the SCMI node for Dom0, we need to: >>>> >>>> Copy these protocols from a centralized or predefined source. >>>> Set the correct phandle for each subnode within the SCMI node, ensuring >>>> >>>> accurate representation and functionality. >>>> This extra step of managing the protocols and phandles adds >>>> >>>> complexity but is necessary for ensuring proper support for Dom0. >>>> >>>> [0] >>>> https://lists.xenproject.org/archives/html/xen-devel/2025-05/msg01041.html >>> I was only commenting that rather than trying to modify the DT in place >>> we could create the node for Dom0 from scratch (artificially), based on >>> host DT information as required (fetching data from the host DT as >>> required and copying it to the Dom0 DT). >>> >> The problem is that scmi node, apart from the default parameters has a >> list of >> >> supported protocols which may be different for Xen and Dom0 so to >> generate Dom0 node >> >> from scratch we need to copy(or even generate) these nodes which will >> require complex implementation. >> >> In contrary, if we go with implementation, proposed in the last patch - >> then we can have >> >> more cleaner Xen device tree, which will look like this: >> >> ``` >> >> chosen { >> >> scmi_xen: scmi { >> >> arm,smc-id = <0x82000002>; >> >> shmem= <$shm_0>; >> >> ... # no protocols description here >> >> }; >> >> firmware { >> >> scmi { >> >> arm,smc-id = <0x82000003>; >> >> shmem= <$shm_1>; >> >> protocol@X{ >> >> }; >> >> } >> >> }; >> >> ``` >> >> In this case, we don’t provide any protocol information for the Xen >> agent and instead set protocols for Dom0. >> >> This ensures that each node has the information it requires. > Leaving aside how we generate the device tree nodes for Dom0, which is > of minor importance, we have two potentially conflicting goals: > > 1) no Xen-specific changes to Device Tree outside of /chosen > 2) When Xen is present, Xen should be the one using the information in the > Host Device Tree > > With 1), I mean that the Host Device Tree, outside of the /chosen node, > should be the same for the BSP (no Xen) and for Xen. That is because it > should describe the platform, no matter the software running on it. Also > at the time the Device Tree is generated, often it is not known if Xen > will be running on the platform or not. > > With 2) I meant that ideally when Xen is present, Xen should be the one > to use the information under /firmware/scmi, because Xen is the > principal SCMI client. Then Xen would generate somehow the SCMI device > tree nodes for Dom0 and the DomUs. > > 1) is more important than 2). > > >From what you wrote, it looks like the SCMI device tree nodes are > different between Linux baremetal and Xen. If /firmware/scmi describes > what Linux baremetal should use, then it would work for Linux baremetal > but it would *not* work for Xen's own SCMI connection. Is that correct? > > If that is the case, that is unfortunate. We need to compromise on 2). > > I would keep /firmware/scmi as the one used by Linux baremetal because I > think we should uphold 1) above all else. > > Then the Xen SCMI nodes could be placed under /chosen. This is less than > ideal because /chosen should contain Xen/Linux configurations, not > firmware interfaces. But it is the best we can do in a difficult > situation. > > I think that whether the Dom0 device tree nodes are artificially > generated by Xen, or copied from the Host Device Tree somewhere, it > matters less. I completely agree with your point. That’s why, during the discussion of the last patch in the series, I proposed an approach that keeps the /firmware/scmi node unchanged in the Host Device Tree (DT) and places all Xen-related changes inside the /chosen/xen,config node. I plan to follow this approach in v5. Here’s the link to the message where I provided a DT example that ensures the /firmware/scmi node remains the same as in the Host DT: [0]. [0]: https://lists.xenproject.org/archives/html/xen-devel/2025-06/msg01421.html
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |