> On 15 Mar 2023, at 09:20, Jan Beulich <jbeulich@suse.com> wrote:
>
> 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.
Yes, sorry about that, I’ll rename that file to arm-arch-capabilities.h in the next version
>
> Jan