Re: [Qemu-arm] [PATCH] target-arm: Add VBAR support to ARM1176 CPUs

[Peter Maydell]

On 24 November 2016 at 14:29, Cédric Le Goater <address@hidden> wrote:
> On 09/05/2016 04:39 PM, Peter Maydell wrote:
>> We implement VBAR in v7-without-EL3 even though architecturally
>> it should only exist in v7-with-EL3 because we have some
>> legacy board models which we implement as without-EL3 but
>> where the guest (Linux) assumes it's running on a with-EL3
>> CPU in NS mode. I'd rather we stick to the architectural
>> definition for 1176 if we can rather than expanding the
>> "things we do which aren't architectural" set if there's
>> no legacy config that requires it. (If it is necessary
>> to define it for 1176 always then that's OK, I'd just
>> prefer not to unless we know we have to.)
>
> According to the ARM spec, 1176 is a v6 with a couple of
> extensions, among which v6k and TrustZone. So it has Secure
> and Non-Secure VBAR and MVBAR registers.
>
> Looking at :
>
>   https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures
>
> May be, we should instead introduce a new ARMv6Z architecture
> for the 1176 cpu which would represent a ARMv6 + TrustZone ?
>
>
> But I am a bit confused with this EL3 feature. 1176 does not
> have EL3 to my understanding (I am beyond my ARM skills there).

EL3 == TrustZone's Monitor mode level of privilege. In
ARMv8 the privilege level model was tidied up a bit so it's
more cleanly arranged in levels EL0 (user) EL1 (kernel)
EL2 (hypervisor) EL3 (secure monitor), and the old 32-bit
setup can be expressed in terms of that (User being EL0,
the various Sys/Fiq/Irq/etc modes being EL1, Hyp at EL2
and Mon at EL3). For QEMU we implemented TrustZone support
after the v8 spec was published, so we had the opportunity
to do it in a way that fit nicely with 64-bit TZ support.
So ARM_FEATURE_EL3 is our "does this CPU have TrustZone"
flag, in the same way that ARM_FEATURE_EL2 is "does it have
the Virtualization extensions".

We also support 1176-without-TrustZone, which doesn't
exist in real hardware but which we have for backwards
compatibility with code that runs on our 1176 boards
which we implemented before we had TZ support in the
CPU implementation.

What I'm suggesting is that we shoulld provide VBAR
only in the 1176-with-TZ CPUs, not in the 1176-no-TZ
CPUs, unless we must provide it for the latter as a
back-compat requirement.

> So why is it part of the feature list in arm1176_initfn ?
> Is that a way to define the MVBAR and SCR regs ?

The CPU object defaults to TZ-enabled, and then the
board model can disable it. (See for instance the
code in hw/arm/realview.c which sets the has_el3 property
on the CPU object to false.)

thanks
-- PMM