qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] tcg-aarch64: handle additional PXN case


From: Andrew Jones
Subject: Re: [Qemu-devel] [PATCH] tcg-aarch64: handle additional PXN case
Date: Mon, 5 Jan 2015 13:52:12 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Jan 05, 2015 at 11:54:17AM +0000, Peter Maydell wrote:
> On 2 January 2015 at 17:33, Andrew Jones <address@hidden> wrote:
> > D4.5.1 "Memory access control:Access permissions for instruction
> > execution" states
> > "...
> > In addition:
> > * For the EL1&0 translation regime, if the value of the AP[2:1] bits
> > is 0b01, permitting write access from EL0, then the PXN bit is
> > treated as if it has the value 1, regardless of its actual value.
> > ..."
> 
> As far as I can see this only applies to 64-bit translations
> (there is no equivalent wording in the 32-bit VMSA section of
> the ARM ARM), so I think the condition should be on va_size == 64,
> not on ARM_FEATURE_V8.

Ah yes, using ARM_FEATURE_V8 is a mistake. I don't see anything
like this in the AArch32 section either (just looked now).

> 
> > @@ -4960,6 +4960,8 @@ static int get_phys_addr_lpae(CPUARMState *env, 
> > target_ulong address,
> >      *prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
> >      if ((arm_feature(env, ARM_FEATURE_V8) && is_user && (attrs & (1 << 
> > 12))) ||
> >          (!arm_feature(env, ARM_FEATURE_V8) && (attrs & (1 << 12))) ||
> > +        (arm_feature(env, ARM_FEATURE_V8) && !is_user &&
> > +         ((attrs & (3 << 4)) == (1 << 4) /* AP[2:1] == 0b01 */)) ||
> >          (!is_user && (attrs & (1 << 11)))) {
> >          /* XN/UXN or PXN. Since we only implement EL0/EL1 we 
> > unconditionally
> >           * treat XN/UXN as UXN for v8.
> 
> This condition is becoming pretty badly overweight. I think that
> rather than just add another clause to it (especially one which
> needs an embedded /* comment */ !) we should split it up somehow.
> (Consider also that as per the comment we're going to need to
> distinguish UXN from XN shortly for EL2/EL3.)

I can take a stab at cleaning this up. The thought had crossed my
mind as well.

> 
> We don't implement the SCTLR.UWXN/WXN bits either -- don't know
> if you care about those.

I care in the sense that I'd like tcg-aarch64 to be as accurate as
possible, but I haven't bumped into a need for WXN support yet,
as I have with this PXN condition. I can throw support into the new
'prot = check_xn(...)' function that we'll create for the cleanup.

Thanks,
drew



reply via email to

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