[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v6 01/12] xen/arm: enable SVE extension for Xen
> On 18 May 2023, at 10:35, Julien Grall <julien@xxxxxxx> wrote: > > Hi Luca, > > Sorry for jumping late in the review. Hi Julien, Thank you for taking the time to review, >> >> /* >> * Comment from Linux: >> * Userspace may perform DC ZVA instructions. Mismatched block sizes >> diff --git a/xen/arch/arm/arm64/sve-asm.S b/xen/arch/arm/arm64/sve-asm.S >> new file mode 100644 >> index 000000000000..4d1549344733 >> --- /dev/null >> +++ b/xen/arch/arm/arm64/sve-asm.S >> @@ -0,0 +1,48 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * Arm SVE assembly routines >> + * >> + * Copyright (C) 2022 ARM Ltd. >> + * >> + * Some macros and instruction encoding in this file are taken from linux >> 6.1.1, >> + * file arch/arm64/include/asm/fpsimdmacros.h, some of them are a modified >> + * version. > AFAICT, the only modified version is _sve_rdvl, but it is not clear to me why > we would want to have a modified version? > > I am asking this because without an explanation, it would be difficult to > know how to re-sync the code with Linux. In this patch the macros are exactly equal to Linux, apart from the coding style that uses spaces instead of tabs, I was not expecting to keep them in sync as they seems to be not prone to change soon, let me know if I need to use also tabs and be 100% equal to Linux. The following macros that are coming in patch 5 are equal apart from sve_save/sve_load, that are different because of the construction differences between the storage buffers here and in Linux, if you want I can put a comment on them to explain this difference in patch 5 >> >> diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c >> new file mode 100644 >> index 000000000000..6f3fb368c59b >> --- /dev/null >> +++ b/xen/arch/arm/arm64/sve.c >> @@ -0,0 +1,50 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ > > Above, you are using GPL-2.0-only, but here GPL-2.0. We favor the former now. > Happy to deal it on commit if there is nothing else to address. No problem, I will fix in the next push > >> +/* >> + * Arm SVE feature code >> + * >> + * Copyright (C) 2022 ARM Ltd. >> + */ >> + >> +#include <xen/types.h> >> +#include <asm/arm64/sve.h> >> +#include <asm/arm64/sysregs.h> >> +#include <asm/processor.h> >> +#include <asm/system.h> >> + >> +extern unsigned int sve_get_hw_vl(void); >> + >> +register_t compute_max_zcr(void) >> +{ >> + register_t cptr_bits = get_default_cptr_flags(); >> + register_t zcr = vl_to_zcr(SVE_VL_MAX_BITS); >> + unsigned int hw_vl; >> + >> + /* Remove trap for SVE resources */ >> + WRITE_SYSREG(cptr_bits & ~HCPTR_CP(8), CPTR_EL2); >> + isb(); >> + >> + /* >> + * Set the maximum SVE vector length, doing that we will know the VL >> + * supported by the platform, calling sve_get_hw_vl() >> + */ >> + WRITE_SYSREG(zcr, ZCR_EL2); > > From my reading of the Arm (D19-6331, ARM DDI 0487J.a), a direct write to a > system register would need to be followed by an context synchronization event > (e.g. isb()) before the software can rely on the value. > > In this situation, AFAICT, the instruciton in sve_get_hw_vl() will use the > content of ZCR_EL2. So don't we need an ISB() here? From what I’ve read in the manual for ZCR_ELx: An indirect read of ZCR_EL2.LEN appears to occur in program order relative to a direct write of the same register, without the need for explicit synchronization I’ve interpreted it as “there is no need to sync before write” and I’ve looked into Linux and it does not Appear any synchronisation mechanism after a write to that register, but if I am wrong I can for sure add an isb if you prefer. > >> + >> + /* >> + * Read the maximum VL, which could be lower than what we imposed >> before, >> + * hw_vl contains VL in bytes, multiply it by 8 to use vl_to_zcr() later >> + */ >> + hw_vl = sve_get_hw_vl() * 8U; >> + >> + /* Restore CPTR_EL2 */ >> + WRITE_SYSREG(cptr_bits, CPTR_EL2); >> + isb(); >> + >> + return vl_to_zcr(hw_vl); >> +} >> + >> +/* Takes a vector length in bits and returns the ZCR_ELx encoding */ >> +register_t vl_to_zcr(unsigned int vl) >> +{ >> + ASSERT(vl > 0); >> + return ((vl / SVE_VL_MULTIPLE_VAL) - 1U) & ZCR_ELx_LEN_MASK; >> +} > > Missing the emacs magic blocks at the end. I’ll add > >> diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c >> index c4ec38bb2554..83b84368f6d5 100644 >> --- a/xen/arch/arm/cpufeature.c >> +++ b/xen/arch/arm/cpufeature.c >> @@ -9,6 +9,7 @@ >> #include <xen/init.h> >> #include <xen/smp.h> >> #include <xen/stop_machine.h> >> +#include <asm/arm64/sve.h> >> #include <asm/cpufeature.h> >> DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS); >> @@ -143,6 +144,9 @@ void identify_cpu(struct cpuinfo_arm *c) >> c->zfr64.bits[0] = READ_SYSREG(ID_AA64ZFR0_EL1); >> + if ( cpu_has_sve ) >> + c->zcr64.bits[0] = compute_max_zcr(); >> + >> c->dczid.bits[0] = READ_SYSREG(DCZID_EL0); >> c->ctr.bits[0] = READ_SYSREG(CTR_EL0); >> @@ -199,7 +203,7 @@ static int __init create_guest_cpuinfo(void) >> guest_cpuinfo.pfr64.mpam = 0; >> guest_cpuinfo.pfr64.mpam_frac = 0; >> - /* Hide SVE as Xen does not support it */ >> + /* Hide SVE by default to the guests */ >> guest_cpuinfo.pfr64.sve = 0; >> guest_cpuinfo.zfr64.bits[0] = 0; >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >> index d8ef6501ff8e..0350d8c61ed8 100644 >> --- a/xen/arch/arm/domain.c >> +++ b/xen/arch/arm/domain.c >> @@ -181,9 +181,6 @@ static void ctxt_switch_to(struct vcpu *n) >> /* VGIC */ >> gic_restore_state(n); >> - /* VFP */ >> - vfp_restore_state(n); >> - > > At the moment ctxt_switch_to() is (mostly?) the reverse of > ctxt_switch_from(). But with this change, you are going to break it. > > I would really prefer if the existing convention stays because it helps to > confirm that we didn't miss bits in the restore code. > > So if you want to move vfp_restore_state() later, then please more > vfp_save_state() earlier in ctxt_switch_from(). Ok I will move vfp_save_state earlier, and ... > > >> /* XXX MPU */ >> /* Fault Status */ >> @@ -234,6 +231,7 @@ static void ctxt_switch_to(struct vcpu *n) >> p2m_restore_state(n); >> /* Control Registers */ >> + WRITE_SYSREG(n->arch.cptr_el2, CPTR_EL2); > > I would prefer if this called closer to vfp_restore_state(). So the > dependency between the two is easier to spot. > >> WRITE_SYSREG(n->arch.cpacr, CPACR_EL1); >> /* >> @@ -258,6 +256,9 @@ static void ctxt_switch_to(struct vcpu *n) >> #endif >> isb(); >> + /* VFP */ > > Please document in the code that vfp_restore_state() have to be called after > CPTR_EL2() + a synchronization event. > > Similar docoumentation on top of at least CPTR_EL2 and possibly isb(). This > would help if we need to re-order the code in the future. I will put comments on top of CPTR_EL2 and vfp_restore_state to explain the sequence and the synchronisation. > > >> + vfp_restore_state(n); >> + >> /* CP 15 */ >> WRITE_SYSREG(n->arch.csselr, CSSELR_EL1); >> @@ -548,6 +549,8 @@ int arch_vcpu_create(struct vcpu *v) >> v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id); >> + v->arch.cptr_el2 = get_default_cptr_flags(); >> + >> v->arch.hcr_el2 = get_default_hcr_flags(); >> v->arch.mdcr_el2 = HDCR_TDRA | HDCR_TDOSA | HDCR_TDA; >> diff --git a/xen/arch/arm/include/asm/arm64/sve.h >> b/xen/arch/arm/include/asm/arm64/sve.h >> new file mode 100644 >> index 000000000000..144d2b1cc485 >> --- /dev/null >> +++ b/xen/arch/arm/include/asm/arm64/sve.h >> @@ -0,0 +1,43 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ > > Use GPL-2.0-only. Ok > >> +/* >> + * Arm SVE feature code >> + * >> + * Copyright (C) 2022 ARM Ltd. >> + */ >> + >> +#ifndef _ARM_ARM64_SVE_H >> +#define _ARM_ARM64_SVE_H >> + >> +#define SVE_VL_MAX_BITS (2048U) > > NIT: The parentheses are unnecessary and we don't tend to add them in Xen. Ok > >> + >> +/* Vector length must be multiple of 128 */ >> +#define SVE_VL_MULTIPLE_VAL (128U) > > NIT: The parentheses are unnecessary Ok > >> + >> +#ifdef CONFIG_ARM64_SVE >> + >> +register_t compute_max_zcr(void); >> +register_t vl_to_zcr(unsigned int vl); >> + >> +#else /* !CONFIG_ARM64_SVE */ >> + >> +static inline register_t compute_max_zcr(void) >> +{ > > Is this meant to be called when SVE is not enabled? If not, then please add > ASSERT_UNREACHABLE(). I’ll add > >> + return 0; >> +} >> + >> +static inline register_t vl_to_zcr(unsigned int vl) >> +{ > > Is this meant to be called when SVE is not enabled? If not, then please add > ASSERT_UNREACHABLE(). It seems that for this patch this was unneeded, maybe some change from v1 led to that, I will remove this. > >> + return 0; >> +} >> + >> +#endif /* CONFIG_ARM64_SVE */ >> + >> +#endif /* _ARM_ARM64_SVE_H */ >> +/* >> + * Local variables: >> + * mode: C >> + * c-file-style: "BSD" >> + * c-basic-offset: 4 >> + * indent-tabs-mode: nil >> + * End: >> + */ >> diff --git a/xen/arch/arm/include/asm/arm64/sysregs.h >> b/xen/arch/arm/include/asm/arm64/sysregs.h >> index 463899951414..4cabb9eb4d5e 100644 >> --- a/xen/arch/arm/include/asm/arm64/sysregs.h >> +++ b/xen/arch/arm/include/asm/arm64/sysregs.h >> @@ -24,6 +24,7 @@ >> #define ICH_EISR_EL2 S3_4_C12_C11_3 >> #define ICH_ELSR_EL2 S3_4_C12_C11_5 >> #define ICH_VMCR_EL2 S3_4_C12_C11_7 >> +#define ZCR_EL2 S3_4_C1_C2_0 >> #define __LR0_EL2(x) S3_4_C12_C12_ ## x >> #define __LR8_EL2(x) S3_4_C12_C13_ ## x >> diff --git a/xen/arch/arm/include/asm/cpufeature.h >> b/xen/arch/arm/include/asm/cpufeature.h >> index c62cf6293fd6..6d703e051906 100644 >> --- a/xen/arch/arm/include/asm/cpufeature.h >> +++ b/xen/arch/arm/include/asm/cpufeature.h >> @@ -32,6 +32,12 @@ >> #define cpu_has_thumbee (boot_cpu_feature32(thumbee) == 1) >> #define cpu_has_aarch32 (cpu_has_arm || cpu_has_thumb) >> +#ifdef CONFIG_ARM64_SVE >> +#define cpu_has_sve (boot_cpu_feature64(sve) == 1) >> +#else >> +#define cpu_has_sve (0) > > NIT: The parentheses are unnecessary Ok > >> +#endif >> + >> #ifdef CONFIG_ARM_32 >> #define cpu_has_gicv3 (boot_cpu_feature32(gic) >= 1) >> #define cpu_has_gentimer (boot_cpu_feature32(gentimer) == 1) >> @@ -323,6 +329,14 @@ struct cpuinfo_arm { >> }; >> } isa64; >> + union { >> + register_t bits[1]; >> + struct { >> + unsigned long len:4; >> + unsigned long __res0:60; >> + }; >> + } zcr64; >> + >> struct { >> register_t bits[1]; >> } zfr64; >> diff --git a/xen/arch/arm/include/asm/domain.h >> b/xen/arch/arm/include/asm/domain.h >> index 2a51f0ca688e..e776ee704b7d 100644 >> --- a/xen/arch/arm/include/asm/domain.h >> +++ b/xen/arch/arm/include/asm/domain.h >> @@ -190,6 +190,7 @@ struct arch_vcpu >> register_t tpidrro_el0; >> /* HYP configuration */ >> + register_t cptr_el2; >> register_t hcr_el2; >> register_t mdcr_el2; >> diff --git a/xen/arch/arm/include/asm/processor.h >> b/xen/arch/arm/include/asm/processor.h >> index 54f253087718..bc683334125c 100644 >> --- a/xen/arch/arm/include/asm/processor.h >> +++ b/xen/arch/arm/include/asm/processor.h >> @@ -582,6 +582,8 @@ void do_trap_guest_serror(struct cpu_user_regs *regs); >> register_t get_default_hcr_flags(void); >> +register_t get_default_cptr_flags(void); >> + >> /* >> * Synchronize SError unless the feature is selected. >> * This is relying on the SErrors are currently unmasked. >> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c >> index 6f9f4d8c8a15..4191a766767a 100644 >> --- a/xen/arch/arm/setup.c >> +++ b/xen/arch/arm/setup.c >> @@ -135,10 +135,11 @@ static void __init processor_id(void) >> cpu_has_el2_32 ? "64+32" : cpu_has_el2_64 ? "64" : "No", >> cpu_has_el1_32 ? "64+32" : cpu_has_el1_64 ? "64" : "No", >> cpu_has_el0_32 ? "64+32" : cpu_has_el0_64 ? "64" : "No"); >> - printk(" Extensions:%s%s%s\n", >> + printk(" Extensions:%s%s%s%s\n", >> cpu_has_fp ? " FloatingPoint" : "", >> cpu_has_simd ? " AdvancedSIMD" : "", >> - cpu_has_gicv3 ? " GICv3-SysReg" : ""); >> + cpu_has_gicv3 ? " GICv3-SysReg" : "", >> + cpu_has_sve ? " SVE" : ""); >> /* Warn user if we find unknown floating-point features */ >> if ( cpu_has_fp && (boot_cpu_feature64(fp) >= 2) ) >> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c >> index d40c331a4e9c..c0611c2ef6a5 100644 >> --- a/xen/arch/arm/traps.c >> +++ b/xen/arch/arm/traps.c >> @@ -93,6 +93,21 @@ register_t get_default_hcr_flags(void) >> HCR_TID3|HCR_TSC|HCR_TAC|HCR_SWIO|HCR_TIDCP|HCR_FB|HCR_TSW); >> } >> +register_t get_default_cptr_flags(void) >> +{ >> + /* >> + * Trap all coprocessor registers (0-13) except cp10 and >> + * cp11 for VFP. >> + * >> + * /!\ All coprocessors except cp10 and cp11 cannot be used in Xen. >> + * >> + * On ARM64 the TCPx bits which we set here (0..9,12,13) are all >> + * RES1, i.e. they would trap whether we did this write or not. >> + */ >> + return ((HCPTR_CP_MASK & ~(HCPTR_CP(10) | HCPTR_CP(11))) | >> + HCPTR_TTA | HCPTR_TAM); >> +} >> + >> static enum { >> SERRORS_DIVERSE, >> SERRORS_PANIC, >> @@ -122,6 +137,7 @@ __initcall(update_serrors_cpu_caps); >> void init_traps(void) >> { >> + register_t cptr_bits = get_default_cptr_flags(); > > Coding style: Please add a newline after the declaration. That said... > >> /* >> * Setup Hyp vector base. Note they might get updated with the >> * branch predictor hardening. >> @@ -135,17 +151,7 @@ void init_traps(void) >> /* Trap CP15 c15 used for implementation defined registers */ >> WRITE_SYSREG(HSTR_T(15), HSTR_EL2); >> - /* Trap all coprocessor registers (0-13) except cp10 and >> - * cp11 for VFP. >> - * >> - * /!\ All coprocessors except cp10 and cp11 cannot be used in Xen. >> - * >> - * On ARM64 the TCPx bits which we set here (0..9,12,13) are all >> - * RES1, i.e. they would trap whether we did this write or not. >> - */ >> - WRITE_SYSREG((HCPTR_CP_MASK & ~(HCPTR_CP(10) | HCPTR_CP(11))) | >> - HCPTR_TTA | HCPTR_TAM, >> - CPTR_EL2); >> + WRITE_SYSREG(cptr_bits, CPTR_EL2); > > ... I would combine the two lines as the variable seems unnecessary. I will combine > >> /* >> * Configure HCR_EL2 with the bare minimum to run Xen until a guest > > Cheers, > > -- > Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |