mbox series

[RFC,v3,0/7] xen/arm: scmi: introduce SCI SCMI SMC multi-agent support

Message ID 20250311111618.1850927-1-grygorii_strashko@epam.com (mailing list archive)
Headers show
Series xen/arm: scmi: introduce SCI SCMI SMC multi-agent support | expand

Message

Grygorii Strashko March 11, 2025, 11:16 a.m. UTC 
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 

Code can be found at:
https://github.com/GrygiriiS/xen/commits/master_v4h_sci_v13_dt_gen

[1] RFC v2:
https://patchwork.kernel.org/project/xen-devel/cover/cover.1644341635.git.oleksii_moisieiev@epam.com/

SCMI spec:
https://developer.arm.com/documentation/den0056/e/?lang=en

SCMI bindings:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/access-controllers/access-controllers.yaml

Reference EL3 FW:
RPI5: https://github.com/xen-troops/arm-trusted-firmware/commits/rpi5_dev/
Renesas v4h: https://github.com/GrygiriiS/arm-trusted-firmware/commits/rcar_gen4_v2.7_v4x-scmi_upd/

base-commit: c3f5d1bb40b5 ("automation/cirrus-ci: introduce FreeBSD randconfig builds")

Grygorii Strashko (2):
  xen/arm: scmi-smc: update to be used under sci subsystem
  xen/arm: scmi-smc: passthrough SCMI SMC to domain, single agent

Oleksii Moisieiev (5):
  xen/arm: add generic SCI subsystem
  xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver
  libs: libxenhypfs - handle blob properties
  xen/arm: Export host device-tree to hypfs
  xen/arm: scmi: generate scmi dt node for DomUs

 MAINTAINERS                                  |   6 +
 docs/man/xl.cfg.5.pod.in                     |  51 ++
 docs/misc/xen-command-line.pandoc            |  18 +
 tools/include/libxl.h                        |   5 +
 tools/include/xenctrl.h                      |   3 +
 tools/libs/ctrl/xc_domain.c                  |  18 +
 tools/libs/hypfs/core.c                      |   2 -
 tools/libs/light/libxl_arm.c                 | 311 ++++++-
 tools/libs/light/libxl_create.c              |  12 +
 tools/libs/light/libxl_internal.h            |   3 +
 tools/libs/light/libxl_types.idl             |  12 +
 tools/xl/xl_parse.c                          |  83 ++
 xen/arch/arm/Kconfig                         |  16 +
 xen/arch/arm/Makefile                        |   1 +
 xen/arch/arm/device.c                        |   5 +
 xen/arch/arm/dom0less-build.c                |  13 +
 xen/arch/arm/domain.c                        |  12 +-
 xen/arch/arm/domain_build.c                  |  11 +-
 xen/arch/arm/domctl.c                        |  22 +
 xen/arch/arm/firmware/Kconfig                |  36 +-
 xen/arch/arm/firmware/Makefile               |   2 +
 xen/arch/arm/firmware/sci.c                  | 187 ++++
 xen/arch/arm/firmware/scmi-proto.h           | 164 ++++
 xen/arch/arm/firmware/scmi-shmem.c           | 172 ++++
 xen/arch/arm/firmware/scmi-shmem.h           |  45 +
 xen/arch/arm/firmware/scmi-smc-multiagent.c  | 858 +++++++++++++++++++
 xen/arch/arm/firmware/scmi-smc.c             | 161 +++-
 xen/arch/arm/host_dtb_export.c               |  28 +
 xen/arch/arm/include/asm/domain.h            |  11 +
 xen/arch/arm/include/asm/firmware/sci.h      | 214 +++++
 xen/arch/arm/include/asm/firmware/scmi-smc.h |  41 -
 xen/arch/arm/vsmc.c                          |   4 +-
 xen/common/domctl.c                          |  13 +
 xen/drivers/passthrough/device_tree.c        |   7 +
 xen/include/asm-generic/device.h             |   1 +
 xen/include/public/arch-arm.h                |  12 +
 xen/include/public/device_tree_defs.h        |   1 +
 xen/include/public/domctl.h                  |  11 +
 38 files changed, 2471 insertions(+), 101 deletions(-)
 create mode 100644 xen/arch/arm/firmware/sci.c
 create mode 100644 xen/arch/arm/firmware/scmi-proto.h
 create mode 100644 xen/arch/arm/firmware/scmi-shmem.c
 create mode 100644 xen/arch/arm/firmware/scmi-shmem.h
 create mode 100644 xen/arch/arm/firmware/scmi-smc-multiagent.c
 create mode 100644 xen/arch/arm/host_dtb_export.c
 create mode 100644 xen/arch/arm/include/asm/firmware/sci.h
 delete mode 100644 xen/arch/arm/include/asm/firmware/scmi-smc.h

Comments

Jan Beulich March 11, 2025, 11:46 a.m. UTC | #1 
On 11.03.2025 12:16, Grygorii Strashko wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1223,6 +1223,13 @@ struct xen_domctl_vmtrace_op {
>  #define XEN_DOMCTL_vmtrace_get_option         5
>  #define XEN_DOMCTL_vmtrace_set_option         6
>  };
> +
> +/* XEN_DOMCTL_get_sci_info */
> +struct xen_domctl_sci_info {
> +    uint64_t paddr;
> +    uint32_t func_id;
> +};

Please take a look at the rest of this header: Outside of x86-specific
sub-ops there's no use of uint64_t; uint64_aligned_t wants using instead.

> @@ -1333,6 +1340,9 @@ struct xen_domctl {
>  #define XEN_DOMCTL_dt_overlay                    87
>  #define XEN_DOMCTL_gsi_permission                88
>  #define XEN_DOMCTL_set_llc_colors                89
> +
> +#define XEN_DOMCTL_get_sci_info                  90
> +
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002

The latter of the blank lines may make sense to add. There former shouldn't
be there imo.

Jan