qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 06/23] target-arm: add arm_is_secure() functi


From: Aggeler Fabian
Subject: Re: [Qemu-devel] [PATCH v2 06/23] target-arm: add arm_is_secure() function
Date: Thu, 15 May 2014 13:00:52 +0000

The v8 ARM ARM only leaves it as implementation defined when EL2 is not 
implemented,
otherwise is has only a non-secure state as Peter said. Another reason why I 
chose to make
the default non-secure is the suggested mapping of non-secure Aarch32 registers 
to EL1 and
secure Aarch32 registers to EL3 (D1.20.1).

To me it seems that it depends whether we want to follow the ARM ARM v7 or v8. 
Based on Peter’s
comment I’d go for the NS-only approach.

Fabian

On 15 May 2014, at 00:22, Greg Bellows <address@hidden<mailto:address@hidden>> 
wrote:

Thanks for the input Peter.

>From briefly looking, it actually looks like the ARMv7 spec more strictly 
>states that the default is secure.  ARMv8 on the other hand appears to leave 
>it open as implementation defined,

Based on out past discussions, I assumed non-secure as the default and that 
appears to be the direction of Fabian's code as well.  Clearly if we want to 
follow the spec, we'd both need to change this default.

Greg



On 14 May 2014 16:29, Peter Maydell <address@hidden<mailto:address@hidden>> 
wrote:
On 14 May 2014 21:22, Greg Bellows <address@hidden<mailto:address@hidden>> 
wrote:
> I suppose it depends on how true we want to be to the specification and
> whether our default is NS=0 or NS=1 when the security extension is present
> or not.  The code currently assumes non-secure as the default state.

The v8 ARM ARM at least allows the CPU to behave as if only
NS was present if there is no implementation of the Security
extensions. I haven't checked the v7 wording.

(In general I think QEMU's implementation of this should follow
the v8 ARM ARM and treat v7 CPUs as a sort of special degenerate
case.)

> Is there a convention in qemu?  How closely do we attempt to stay to the
> pseudo code provided in the spec?

The pseudocode in the ARM ARM is part of the spec. We should
strive to follow the spec. This doesn't necessarily mean matching
pseudocode functions exactly -- the requirement is to be
behaviourally the same, and sometimes the pseudocode is
written to be clear rather than efficient or to deal with situations
we don't necessarily care about.

thanks
-- PMM





reply via email to

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