qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cédric Le Goater
Subject: Re: [Qemu-arm] [PATCH] target-arm: Add VBAR support to ARM1176 CPUs
Date: Mon, 28 Nov 2016 16:21:15 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 11/28/2016 11:40 AM, Peter Maydell wrote:
> 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.

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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]