From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7Vqa-0001GY-Sa for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:35:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7VqV-0006Yo-AP for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:35:12 -0400 Received: from mail-vn0-f42.google.com ([209.85.216.42]:46004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7VqU-0006XH-Uf for qemu-devel@nongnu.org; Tue, 23 Jun 2015 17:35:07 -0400 Received: by vnbg1 with SMTP id g1so3569353vnb.12 for ; Tue, 23 Jun 2015 14:35:06 -0700 (PDT) MIME-Version: 1.0 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> From: Peter Maydell Date: Tue, 23 Jun 2015 22:34:47 +0100 Message-ID: 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 Crosthwaite Cc: Paolo Bonzini , QEMU Developers On 23 June 2015 at 21:30, Peter Crosthwaite wrote: > On Tue, Jun 23, 2015 at 11:54 AM, Peter Maydell > wrote: >> On 23 June 2015 at 19:43, Peter Crosthwaite >> wrote: >> I'm confused. arm_cpu_is_big_endian() tells you whether the CPU >> is *currently* big-endian or not. That doesn't help you with >> answering the question "I'm about to run a signal handler; what >> should I set the CPSR.E bit to?" in linux-user mode. That's >> what signal_cpsr_e does. >> > > arm_cpu_is_bigendian is the consumer of this information. We still > need some state for signal_cpsr_e, just the question is what state > does that set. If we reuse arm_cpu_is_big_endian, then signal_cpsr_e > (or its rename) needs to drive CPSR.E as well as SCTLR.E0E. That doesn't make sense to me. arm_cpu_is_bigendian() is asking a runtime question about the current state of the CPU. signal_cpsr_e is a set-once-at-startup bit of information about the environment we're trying to run the program in. The point at which we want to ask the question "what should we set CPSR.E to for signal delivery" is when we try to deliver the signal; it doesn't depend upon the current state of the CPU at all. And (except at that exact point when we've just set CPSR.E but haven't run any guest code) the current state of the CPU doesn't depend on signal_cpsr_e. >>> 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). >> >> I'm not entirely sure what you're suggesting here, but >> a "generic endianness bool" sounds more confusing than something >> that's specific about exactly what it's trying to control. > > Agree, what I am trying to get away from though is using "CPSR" or any > other regs in the naming scheme. Certainly we can fix the naming to be less AArch32-ish. But in general I think the logic in Paolo's patchset for AArch32 was exactly correct, and we should be trying to extend it to cover the (actually much simpler) AArch64 cases, not rewriting it. thanks -- PMM