Re: [Qemu-devel] [PATCH 05/11] target-arm: Use correct mmu_idx for unprivileged loads and stores

From: Greg Bellows <greg.bellows@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	"Andrew Jones" <drjones@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Patch Tracking" <patches@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 05/11] target-arm: Use correct mmu_idx for unprivileged loads and stores
Date: Mon, 26 Jan 2015 16:01:12 -0600	[thread overview]
Message-ID: <CAOgzsHV=ehpgRJF1LN74ydEd7oJWRxhdaVBysKTTUN_+iMkkig@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA--nMDKLDg+YMj5y6mgyK6-+qNSh+8mHLO+jAS=v+c6Ug@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

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 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 following
> > 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.
>

My bad, you are correct, I read S2NS too fast.

>
> > - 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").
>
> Ah 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
>

I see the differences now, thanks for the clarification.

[-- Attachment #2: Type: text/html, Size: 3342 bytes --]