Re: [Qemu-devel] [Bug 1359930] Re: [ARMv5] Integrator/CP regression when reading FPSID instruction

[Peter Maydell]

On 22 August 2014 12:17, Mark Cave-Ayland <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 <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