qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wron


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] linux-user: qemu treats TLS pointer in the wrong way when spicifying cpu cotrex-a15.
Date: Mon, 16 Mar 2015 12:05:23 +0000

On 16 March 2015 at 11:26, Mikhail Ilyin <address@hidden> wrote:
> From: Mikhail Ilyin <address@hidden>
>
> At present there are two copies of TPIDRURO register for secure and unsecure
> access. TLS is set via a system call __ARM_NR_set_tls and its handler
> (cpu_set_tls) always assigns a provided value to unsecure register
> tpidrro_el[0]/tpidruro_ns. But during execution for cortex-a15 mrc instruction
> returns TLS from secure rigester tpidruro_s which is 0 and causes SIGSEGV.
>
> Signed-off-by: Mikhail Ilyin <address@hidden>

Oops; thanks for this patch. I've applied it to target-arm.next.
I took the liberty of rewriting the commit message a bit to better
fit in with QEMU's usual style; hope that's OK:

===begin===
linux-user: Access correct register for get/set_tls syscalls on ARM TZ CPUs

When support was added for TrustZone to ARM CPU emulation, we failed
to correctly update the support for the linux-user implementation of
the get/set_tls syscalls. This meant that accesses to the TPIDRURO
register via the syscalls were always using the non-secure copy of
the register even if native MRC/MCR accesses were using the secure
register. This inconsistency caused most binaries to segfault on startup
if the CPU type was explicitly set to one of the TZ-enabled ones like
cortex-a15. (The default "any" CPU doesn't have TZ enabled and so is
not affected.)

Use access_secure_reg() to determine whether we should be using
the secure or the nonsecure copy of TPIDRURO when emulating these
syscalls.
===endit===

-- PMM



reply via email to

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