Re: [Qemu-devel] [PATCH] target-arm: A64: Correct handling of UXN bit.

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Mon, Jun 09, 2014 at 02:40:59PM +0100, Peter Maydell wrote:
> On 8 June 2014 14:53, Ian Campbell <ijc@hellion.org.uk> wrote:
> > In v8 page tables bit 54 in the PTE is UXN in the EL0/EL1 translation regimes
> > and XN elsewhere. In v7 the bit is always XN. Since we only emulate EL0/EL1 we
> > can just treat this bit as UXN whenever we are in v8 mode.
> >
> > Also correctly extract the upper attributes from the PTE entry, the v8 version
> > tried to avoid extracting the CONTIG bit and ended up with the upper bits being
> > off-by-one. Instead behave the same as v7 and extract (but ignore) the CONTIG
> > bit.
> >
> > This fixes "Bad mode in Synchronous Abort handler detected, code 0x8400000f"
> > seen when modprobing modules under Linux.
> >
> > Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Cc: Claudio Fontana <claudio.fontana@huawei.com>
> > Cc: Rob Herring <robherring2@gmail.com>
> 
> Thanks, applied to target-arm.next.
> To those interested in EL2/EL3 support: what's the
> plan for telling the get_phys_addr() functions which
> translation regime they should be operating in?

My ARMv8 S2 MMU code is a bit of a mess at the moment but I'm thinking to add
translation_el and stage arguments to get_phys_addr(). We can work out the
details later but basically we need get_phys_addr() to be able to
do translation for the various ELs, Stage 1 and/or Stage 2 and to be able
to do the translations independent from the current CPU state. We need
the latter to support the various address translation regs (e.g ATS12E0R
from El3).

Cheers,
Edgar


> 
> (since that is what indicates whether this bit is UXN or XN,
> as well as having various other effects).
> 
> thanks
> -- PMM