Hi All, Jan, Anthony, Stefano, On 11.03.25 13:16, Grygorii Strashko wrote:
Hi,This is respin of RFCv2 series from Oleksii Moisieiev [1] which was send pretty long time ago (2022), with the main intention is to resume this discussion in public and gather more opinions. Hence the code was previously sent long time ago there are pretty high number of changes, including rebase on newer Xen version 4.20.0-rc2, which already contains some basic SCMI SMC driver introduced by Andrei Cherechesu, commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling layer"). Patch 1 "xen/arm: add generic SCI subsystem" - rebased and refactored - introduced DEVICE_ARM_SCI DT device class and used for SCI drivers probing instead of custom, linker sections based implementation. - added SCI API for Dom0 DT handling, instead of manipulating with ARM arch dom0 code directly. - TODO: RFC changes in XEN_DOMCTL_assign_device OP processing Patch 2 "xen/arm: scmi-smc: update to be used under sci subsystem" - update driver introduced by commit 3e322bef8bc0 ("xen/arm: firmware: Add SCMI over SMC calls handling layer") be used under sci subsystem. - no functional changes in general Patch 3 "xen/arm: scmi-smc: passthrough SCMI SMC to guest domain This is new change which allows passthrough SCMI SMC, single agent interface to guest domain cover use case "thin Dom0 with guest domain, which serves as Driver domain". See patch commit message for full description. Patch 4 - xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver - added "xen,scmi-secondary-agents" property in "chosen" to inform SCI SCMI multi-agent driver about available agents and their configuration. It defines <agent_id> to <smc-id,scmi_shm> map. This option is Xen specific as Xen is the only one entry in the system which need to know about SCMI multi-agent support and configuration. - each guest using SCMI should be configured with SCMI agent_id, so SCMI FW can implement Agent-specific permission policy. -- dom0: dom0_scmi_agent_id=<agent_id> in Xen command line option -- toolstack: arm_sci = "type=scmi_smc_multiagent,agent_id=<agent_id>" -- dom0less: todo: "xen,sci_type", "xen,sci_agent_id" properties in "xen,domain" nodes. - factored out SCMI generic definitions (re-usable) - factored out SCMI shmem code (re-usable) - the SCMI passthrough configuration for guest domains is similar to any other HW passthrough cfg. Patches 5-7 - no major changes, except to follow rebase and changes in previous patches Regarding patches 5-7 I'd like to rise a question and I, personally, feel very skeptical doing any kind of SCMI DT nodes generation as from toolstack as from Xen. 1) SCMI is no differ as any other HW MFD device, and HW passthrough configuration works for it in the same way. 2) if toolstack generates DT then dom0less case might need it also, but this means more code in Xen, so, with certification in mind, it means more overhead requirements, docs and testing. In my opinion if something can be done outside "kernel" - it should. So better invest in tools (imagebuilder, lopper, etc.) instead. 3) Hence SCMI DT bindings are pretty complex the corresponding guest DT nodes can't be generated from scratch - the user still need to add scmi node, protocols and protocols subnodes in the partial device tree, at least empty. But stop, not exactly empty - the properties like "#clock-cells" need to be added to avoid DTC warnings. Such behavior is rather confusing than helpful. 4) Exposing the Host Device tree in Dom0 is another questionable thing for toolstack SCMI DT generation. It consumes 128K of memory on Renesas r8a779g0-whitehawk. 5) No needs for additional public API (XEN_DOMCTL_get_sci_info, GUEST_SCI_SHMEM_BASE..) if dropped
Thanks a lot for your time, review and valuable comments. Most of comments are clear enough and will be addressed. Those, required clarification, I'll reply separately. -- Best regards, -grygorii
