From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFrif-0007K8-T5 for qemu-devel@nongnu.org; Mon, 26 Jan 2015 17:01:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFrib-0000cw-2b for qemu-devel@nongnu.org; Mon, 26 Jan 2015 17:01:17 -0500 Received: from mail-qc0-f173.google.com ([209.85.216.173]:62905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFria-0000cr-UP for qemu-devel@nongnu.org; Mon, 26 Jan 2015 17:01:13 -0500 Received: by mail-qc0-f173.google.com with SMTP id m20so9263914qcx.4 for ; Mon, 26 Jan 2015 14:01:12 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1422037228-5363-1-git-send-email-peter.maydell@linaro.org> <1422037228-5363-6-git-send-email-peter.maydell@linaro.org> Date: Mon, 26 Jan 2015 16:01:12 -0600 Message-ID: From: Greg Bellows Content-Type: multipart/alternative; boundary=047d7b5d430ec5cbc4050d9546a5 Subject: Re: [Qemu-devel] [PATCH 05/11] target-arm: Use correct mmu_idx for unprivileged loads and stores List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Edgar E. Iglesias" , Andrew Jones , =?UTF-8?B?QWxleCBCZW5uw6ll?= , QEMU Developers , Patch Tracking --047d7b5d430ec5cbc4050d9546a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 26, 2015 at 2:37 PM, Peter Maydell wrote: > On 26 January 2015 at 19:34, Greg Bellows wrote= : > > On Mon, Jan 26, 2015 at 8:56 AM, Peter Maydell > > > wrote: > >> Because that's what the ARM ARM specifies. Compare C3.2.5 (A64 LDT &c) > >> with F7.1.95 (A32/T32 LDRT). > > > > > > I had been comparing the wording of ARMv8 - F1.6.3 and ARMv7 - A4.6.3. > > After comparing the LDRT instructions between A64 (C6.6.97) and A32 > > (F7.1.95), I am still missing the distinction that warrants the followi= ng > > different behavior: > > > > - EL2 is unpredictable in both A64 and A32, but in one case we treat it > as > > such and the other we demote it to NS/EL0 to allow it. > > No, it's not unpredictable in A64. It behaves as if a normal > (EL2) access [C3.2.5 "if the PE is executing in any other Exception > level, then a normal memory access for that level is performed"]. > It is only unpredictable at EL2 in A32/T32 [F7.1.95 "UNPREDICTABLE > in Hyp mode"; in the v7 ARM ARM, A4.6.3 "UNPREDICTABLE if executed > at PL2"]. You'll see that the pseudocode for A32/T32 LDRT has > an UNPREDICTABLE check for PL2, but the pseudocode for A64 > LDTR does not have any equivalent check. > =E2=80=8BMy bad, you are correct, I read S2NS too fast.=E2=80=8B > > > - EL3 is demoted to S/EL0 in one case but remains EL3 in the > > other. > > Remains EL3 for AArch64 (by the same C3.2.5 requirement quoted above); > must act as if EL0 for AArch32 (F7.1.95 "as if the PE were running > in User mode"). > > =E2=80=8BAh yes.. EL3 is PL1 on AArch32. > This is because an EL3 A32/T32 insn is PL1, and AArch32 accesses > from PL1 must behave as if from PL0 (otherwise pre-v8 software > would break). An EL3 A64 insn, on the other hand, is definitely > not EL1 and there's no back-compatibility behaviour required. > > Both these differences are required by the spec. > > -- PMM > =E2=80=8BI see the differences now, thanks for the clarification.=E2=80=8B --047d7b5d430ec5cbc4050d9546a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 26, 2015 at 2:37 PM, Peter Maydell <peter.= maydell@linaro.org> wrote:
= On 26 January 2015 at 19:34, Greg Bellows <greg.bellows@linaro.org> wrote:
> On Mon, Jan 26, 2015 at 8:56 AM, Peter Maydell <peter.maydell@linaro.org>
> wrote:
>> Because that's what the ARM ARM specif= ies. Compare C3.2.5 (A64 LDT &c)
>> with F7.1.95 (A32/T32 LDRT).
>
>
> I had been comparing the wording of ARMv8 - F1.6.3 and ARMv7 - A4.6.3.=
> After comparing the LDRT instructions between A64 (C6.6.97) and A32 > (F7.1.95), I am still missing the distinction that warrants the follow= ing
> different behavior:
>
> - EL2 is unpredictable in both A64 and A32, but in one case we treat i= t as
> such and the other we demote it to NS/EL0 to allow it.

No, it's not unpredictable in A64. It behaves as if a normal
(EL2) access [C3.2.5 "if the PE is executing in any other Exception level, then a normal memory access for that level is performed"].
It is only unpredictable at EL2 in A32/T32 [F7.1.95 "UNPREDICTABLE
in Hyp mode"; in the v7 ARM ARM, A4.6.3 "UNPREDICTABLE if execute= d
at PL2"]. You'll see that the pseudocode for A32/T32 LDRT has
an UNPREDICTABLE check for PL2, but the pseudocode for A64
LDTR does not have any equivalent check.

=E2=80=8BMy bad, you are correct, I read S2NS too fast.=E2=80=8B
=
=C2=A0

> - EL3 is demoted to S/EL0 in one case but remains EL3 in the
> other.

Remains EL3 for AArch64 (by the same C3.2.5 requirement quoted above= );
must act as if EL0 for AArch32 (F7.1.95 "as if the PE were running
in User mode").

=E2=80=8BAh yes.. EL3 is PL1 on AArch32.

=
=C2=A0
This is because an EL3 A32/T32 insn is PL1, and AArch32 accesses
from PL1 must behave as if from PL0 (otherwise pre-v8 software
would break). An EL3 A64 insn, on the other hand, is definitely
not EL1 and there's no back-compatibility behaviour required.

Both these differences are required by the spec.

-- PMM

=E2=80=8BI see t= he differences now, thanks for the clarification.=E2=80=8B

<= /div> --047d7b5d430ec5cbc4050d9546a5--