Re: [PATCH v2 00/10] SVE feature for arm guests

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.03.2023 10:05, Luca Fancellu wrote:
> This serie is introducing the possibility for Dom0 and DomU guests to use
> sve/sve2 instructions.
> 
> SVE feature introduces new instruction and registers to improve performances 
> on
> floating point operations.
> 
> The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, 
> and
> when available the ID_AA64ZFR0_EL1 register provides additional information
> about the implemented version and other SVE feature.
> 
> New registers added by the SVE feature are Z0-Z31, P0-P15, FFR, ZCR_ELx.
> 
> Z0-Z31 are scalable vector register whose size is implementation defined and
> goes from 128 bits to maximum 2048, the term vector length will be used to 
> refer
> to this quantity.
> P0-P15 are predicate registers and the size is the vector length divided by 8,
> same size is the FFR (First Fault Register).
> ZCR_ELx is a register that can control and restrict the maximum vector length
> used by the <x> exception level and all the lower exception levels, so for
> example EL3 can restrict the vector length usable by EL3,2,1,0.
> 
> The platform has a maximum implemented vector length, so for every value
> written in ZCR register, if this value is above the implemented length, then 
> the
> lower value will be used. The RDVL instruction can be used to check what 
> vector
> length is the HW using after setting ZCR.
> 
> For an SVE guest, the V0-V31 registers are part of the Z0-Z31, so there is no
> need to save them separately, saving Z0-Z31 will save implicitly also V0-V31.
> 
> SVE usage can be trapped using a flag in CPTR_EL2, hence in this serie the
> register is added to the domain state, to be able to trap only the guests that
> are not allowed to use SVE.
> 
> This serie is introducing a command line parameter to enable Dom0 to use SVE 
> and
> to set its maximum vector length that by default is 0 which means the guest is
> not allowed to use SVE. Values from 128 to 2048 mean the guest can use SVE 
> with
> the selected value used as maximum allowed vector length (which could be lower
> if the implemented one is lower).
> For DomUs, an XL parameter with the same way of use is introduced and a 
> dom0less
> DTB binding is created.
> 
> The context switch is the most critical part because there can be big 
> registers
> to be saved, in this serie an easy approach is used and the context is
> saved/restored every time for the guests that are allowed to use SVE.
> 
> Luca Fancellu (10):
>   xen/arm: enable SVE extension for Xen
>   xen/arm: add sve_vl_bits field to domain
>   xen/arm: Expose SVE feature to the guest
>   xen/arm: add SVE exception class handling
>   arm/sve: save/restore SVE context switch
>   xen/arm: enable Dom0 to use SVE feature
>   xen/physinfo: encode Arm SVE vector length in arch_capabilities
>   tools: add physinfo arch_capabilities handling for Arm
>   xen/tools: add sve parameter in XL configuration
>   xen/arm: add sve property for dom0less domUs
> 
>  docs/man/xl.cfg.5.pod.in                 |  11 ++
>  docs/misc/arm/device-tree/booting.txt    |   9 ++
>  docs/misc/xen-command-line.pandoc        |  13 ++
>  tools/golang/xenlight/helpers.gen.go     |   4 +
>  tools/golang/xenlight/types.gen.go       |   2 +
>  tools/include/arm_arch_capabilities.h    |  32 ++++
>  tools/include/libxl.h                    |   5 +
>  tools/libs/light/libxl.c                 |   1 +
>  tools/libs/light/libxl_arm.c             |   2 +
>  tools/libs/light/libxl_types.idl         |   2 +
>  tools/ocaml/libs/xc/xenctrl.ml           |   4 +-
>  tools/ocaml/libs/xc/xenctrl.mli          |   4 +-
>  tools/ocaml/libs/xc/xenctrl_stubs.c      |   8 +-
>  tools/python/xen/lowlevel/xc/xc.c        |   8 +-
>  tools/xl/xl_info.c                       |   8 +
>  tools/xl/xl_parse.c                      |  25 ++-
>  xen/arch/arm/Kconfig                     |  10 +-
>  xen/arch/arm/arm64/Makefile              |   1 +
>  xen/arch/arm/arm64/cpufeature.c          |   7 +-
>  xen/arch/arm/arm64/sve.c                 | 119 ++++++++++++++
>  xen/arch/arm/arm64/sve_asm.S             | 189 +++++++++++++++++++++++
>  xen/arch/arm/arm64/vfp.c                 |  79 ++++++----
>  xen/arch/arm/arm64/vsysreg.c             |  39 ++++-
>  xen/arch/arm/cpufeature.c                |   6 +-
>  xen/arch/arm/domain.c                    |  48 +++++-
>  xen/arch/arm/domain_build.c              |  11 ++
>  xen/arch/arm/include/asm/arm64/sve.h     |  72 +++++++++
>  xen/arch/arm/include/asm/arm64/sysregs.h |   4 +
>  xen/arch/arm/include/asm/arm64/vfp.h     |  10 ++
>  xen/arch/arm/include/asm/cpufeature.h    |  14 ++
>  xen/arch/arm/include/asm/domain.h        |   8 +
>  xen/arch/arm/include/asm/processor.h     |   3 +
>  xen/arch/arm/setup.c                     |   5 +-
>  xen/arch/arm/sysctl.c                    |  11 ++
>  xen/arch/arm/traps.c                     |  40 +++--
>  xen/include/public/arch-arm.h            |   3 +
>  xen/include/public/domctl.h              |   2 +-
>  xen/include/public/sysctl.h              |   3 +
>  38 files changed, 748 insertions(+), 74 deletions(-)
>  create mode 100644 tools/include/arm_arch_capabilities.h
>  create mode 100644 xen/arch/arm/arm64/sve.c
>  create mode 100644 xen/arch/arm/arm64/sve_asm.S
>  create mode 100644 xen/arch/arm/include/asm/arm64/sve.h

I think I had asked for this before - can new files please use dashes
in preference to underscores in their names? Underscores really should
only be used when other possible separators aren't available because of
having other lexical meaning.

Jan