On 02/23/2018 09:00 AM, Alex Bennée wrote: > > Richard Henderson <richard.hender...@linaro.org> writes: > >> Enable ARM_FEATURE_SVE for the generic "any" cpu. >> >> Signed-off-by: Richard Henderson <richard.hender...@linaro.org> >> --- >> target/arm/cpu.c | 7 +++++++ >> target/arm/cpu64.c | 1 + >> 2 files changed, 8 insertions(+) >> >> diff --git a/target/arm/cpu.c b/target/arm/cpu.c >> index 1b3ae62db6..10843994c3 100644 >> --- a/target/arm/cpu.c >> +++ b/target/arm/cpu.c >> @@ -150,6 +150,13 @@ static void arm_cpu_reset(CPUState *s) >> env->cp15.sctlr_el |= SCTLR_UCT | SCTLR_UCI | SCTLR_DZE; >> /* and to the FP/Neon instructions */ >> env->cp15.cpacr_el1 = deposit64(env->cp15.cpacr_el1, 20, 2, 3); >> + /* and to the SVE instructions */ >> + env->cp15.cpacr_el1 = deposit64(env->cp15.cpacr_el1, 16, 2, 3); >> + env->cp15.cptr_el |= CPTR_EZ; >> + /* with maximum vector length */ >> + env->vfp.zcr_el = ARM_MAX_VQ - 1; >> + env->vfp.zcr_el = ARM_MAX_VQ - 1; >> + env->vfp.zcr_el = ARM_MAX_VQ - 1; >> #else > > I notice this is linux-user only but what happens if you specify a > specific CPU in linux-user mode, do we still end up running SVE specific > initialisation? > > It seems to me that we should be seeing feature guarded reset stuff in here.
You're right. On the whole (probably) wouldn't matter in the end because the actual insn decode would still be protected by ARM_FEATURE_SVE. But even so we'd see VQ=16 in the TB flags and do too much work in clear_high_part. r~