From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TAE-0002Qa-6o for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:43:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7TAA-000695-W7 for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:43:18 -0400 Received: from mail-yk0-f175.google.com ([209.85.160.175]:35423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TAA-000691-Rc for qemu-devel@nongnu.org; Tue, 23 Jun 2015 14:43:14 -0400 Received: by ykdy1 with SMTP id y1so10703215ykd.2 for ; Tue, 23 Jun 2015 11:43:14 -0700 (PDT) MIME-Version: 1.0 Sender: peter.crosthwaite@petalogix.com In-Reply-To: References: <1403355502-12288-1-git-send-email-pbonzini@redhat.com> <1403355502-12288-5-git-send-email-pbonzini@redhat.com> <53AC2B9B.40801@redhat.com> Date: Tue, 23 Jun 2015 11:43:13 -0700 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v3 04/11] linux-user: arm: set CPSR.E correctly for BE8 mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paolo Bonzini , QEMU Developers On Tue, Jun 23, 2015 at 1:04 AM, Peter Maydell wrote: > On 22 June 2015 at 23:48, Peter Crosthwaite > wrote: >> On Thu, Jun 26, 2014 at 7:18 AM, Paolo Bonzini wrote: >>> Il 26/06/2014 16:15, Peter Maydell ha scritto: >>>> >>>> (There is code for handling CPSR_E in the kernel's start_thread() >>>> macro but that is actually only called for starting new >>>> processes, AFAICT.) >>> >>> >>> Yes, you're right. >>> >> >> So I am struggling on figuring out the need to have this extra state >> of signal_cpsr_e. Is it still needed and to follow up, would something >> similar be needed for SCTLR.E0E on AA64 support? > > The Linux userland ABI says: > (1) the ELF file defines whether an executable is BE8 or not > (2) this setting affects: > (a) whether we start at the process entry point in BE or LE > (b) whether we run signal handlers in BE or LE > (c) whether newly cloned threads start in BE or LE > > signal_cpsr_e is how this patch implements that -- we set it > based on the ELF file flags, then set CPSR.E based on it: > * in main, for the initial thread > * in cpu_clone_regs, for subsequent threads > * in signal.c, for signal handlers > > For AArch64 BE we will need something similar. I don't know if > there's somewhere more appropriate to store this "what's the > ELF file endianness" state, but we do need to keep it somewhere... > So my current thinking is the new state captured in TB flags, disas-context and this thing is just a bool for endianess. No sense of CPSR.E or SCTLR.xx in the newly added state across the series. The TB flag is then based on SCTLR.EE, SCTLR.E0E or CPSR.E depending on processor mode. We already have arm_cpu_is_big_endian() to calculate this. That means that this logic would change signal_cpsr_e to a generic endianess bool that will set both SCTLR_EL1.E0E and CPSR.E at all the points Paolo is patching. SCTLR.EEs shouldn't need patching as usermode shouldn't be affected (maybe add an assert in arm_cpu_big_endian for usermode). Regards, Peter > thanks > -- PMM >