From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyjUN-0004b1-V1 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 10:10:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyjUM-00019A-B7 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 10:10:55 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:63745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyjUM-000194-44 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 10:10:54 -0400 Received: by mail-lb0-f178.google.com with SMTP id y6so9215373lbh.23 for ; Mon, 15 Jul 2013 07:10:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87sizfudli.fsf@codemonkey.ws> References: <51C75FA6.6080903@reactos.org> <51C7E21A.9090005@web.de> <8A36D64D-0625-49E1-9E59-391DAEEBD1FC@suse.de> <51DEA91B.40903@suse.de> <3FAA7DE1-06A0-45C5-885C-0433BCC0CFE8@suse.de> <5D205309-1154-4730-902E-BF07F5D3B4EB@suse.de> <1373581960.19894.109.camel@pasglop> <02433CA4-954D-4C56-A4A4-7BC0D62638C0@suse.de> <1373628932.19894.158.camel@pasglop> <878v1bvfaw.fsf@codemonkey.ws> <1373669427.19894.202.camel@pasglop> <87sizfudli.fsf@codemonkey.ws> From: Peter Maydell Date: Mon, 15 Jul 2013 15:10:33 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Liu Ping Fan , Alexander Graf , qemu-devel Developers , "qemu-ppc@nongnu.org list:PowerPC" , Paolo Bonzini , Jan Kiszka , =?UTF-8?Q?Andreas_F=C3=A4rber?= , =?UTF-8?Q?Herv=C3=A9_Poussineau?= On 15 July 2013 15:01, Anthony Liguori wrote: > Peter Maydell writes: >> On 12 July 2013 23:50, Benjamin Herrenschmidt wrote: >> I agree that TARGET_WORDS_BIGENDIAN *should* go away, but >> it exists currently. Do you actually implement a CPU which >> does dynamic endianness flipping? > > TCG already supports bi-endianness for PPC. Grep for 'le_mode' in > target-ppc/translate.c to see how the TCG instruction stream is affected > by it. Right, that's what I thought. This means that if you're on a little-endian host and using a PPC chip in le-mode then the QEMU infrastructure will byteswap the data, and then those generated bswap* ops will byteswap it again. It would be more efficient if we supported dynamically having the emulated CPU specify whether it wanted a BE or LE memory access, and then byteswapping the correct number of times based on device/host endianness/CPU setting. (This would also avoid ugliness like the current ARM BE8 code which should be doing "BE read for data, LE read for instructions" and instead has to do "BE read of everything via TARGET_WORDS_BIGENDIAN and then swap the instruction words again to get back to LE".) If we ever want to support multiple different CPUs in one model we'll need this anyway, because one might be BE and another LE. > On PPC, le_mode only really affects load/stores and instruction > decoding. Any shared data structures between the CPU and OS remain big > endian. > > So TARGET_WORDS_BIGENDIAN is still accurate even when > le_mode=1. It's not the semantic equivalent of > changing TARGET_WORDS. I'm not sure what you mean by "accurate" here. It's a compile time switch, when the hardware we're actually emulating does runtime (dynamic) switching, and when the current runtime mode doesn't match the compiled-in setting we end up doing unnecessary double-swap operations. thanks -- PMM