> On 15 Mar 2023, at 09:20, Jan Beulich <[email protected]> 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
