Comment 4 for bug 1359930

On 22 August 2014 12:17, Mark Cave-Ayland <email address hidden> wrote:
> Hi Jakub,
>
> Thanks for the test case. I've just done a git bisect using your test
> image above and it seems as if the offending commit is this:
>
>
> commit 2c7ffc414d8591018248b5487757e45f7bb6bd3c
> Author: Peter Maydell <email address hidden>
> Date: Tue Apr 15 19:18:40 2014 +0100
>
> target-arm: Fix VFP enables for AArch32 EL0 under AArch64 EL1
>
> The current A32/T32 decoder bases its "is VFP/Neon enabled?" check
> on the FPSCR.EN bit. This is correct if EL1 is AArch32, but for
> an AArch64 EL1 the logic is different: it must act as if FPSCR.EN
> is always set. Instead, trapping must happen according to CPACR
> bits for cp10/cp11; these cover all of FP/Neon, including the
> FPSCR/FPSID/MVFR register accesses which FPSCR.EN does not affect.
> Add support for CPACR checks (which are also required for ARMv7,
> but were unimplemented because Linux happens not to use them)
> and make sure they generate exceptions with the correct syndrome.

Thanks for the bisect; this was actually my primary suspect
for the offending commit but I hadn't got round to looking at it.
We're trapping based on the CPACR (c1_coproc) bits being zero,
but that register only appears in ARMv6 and later, so we
accidentally disabled VFP in ARMv5 CPUs.

Probably the best fix is to mak cpu_get_tb_cpu_state() do

   if (arm_feature(env, ARM_FEATURE_V6)) {
       fpen = extract32(env->cp15.c1_coproc, 20, 2);
   } else {
       /* CPACR doesn't exist before v6 so VFP always accessible */
       fpen = 3;
   }

-- PMM