On 11/28/2016 11:40 AM, Peter Maydell wrote: > On 24 November 2016 at 14:29, Cédric Le Goater <c...@kaod.org> 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.
Thanks for the explanation. It is clearer now. > 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. I don't for the back-compat requirement. But I need to rework the patch to keep VBAR in any case for the v7-without-EL3 CPUs and remove it for the 1176 CPUs when 'has_el3' is not set. Thanks, C. >> 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 >
