From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54632 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PM81K-0003g8-Pl for qemu-devel@nongnu.org; Fri, 26 Nov 2010 18:48:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PM81J-00023N-C3 for qemu-devel@nongnu.org; Fri, 26 Nov 2010 18:48:02 -0500 Received: from mail.codesourcery.com ([38.113.113.100]:53159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PM81I-00022k-Or for qemu-devel@nongnu.org; Fri, 26 Nov 2010 18:48:01 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio Date: Fri, 26 Nov 2010 23:47:45 +0000 References: <1290670555-12575-1-git-send-email-agraf@suse.de> <1290670555-12575-2-git-send-email-agraf@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011262347.46536.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?q?F=E4rber?= Cc: Blue Swirl , Alexander Graf , QEMU-devel Developers > > diff --git a/exec.c b/exec.c > > index db9ff55..f54a360 100644 > > --- a/exec.c > > +++ b/exec.c > > > > @@ -3370,6 +3474,22 @@ static int cpu_register_io_memory_fixed(int > > io_index, > > > > } > > io_mem_opaque[io_index] = opaque; > > > > + switch (endian) { > > + case DEVICE_BIG_ENDIAN: > > +#ifndef TARGET_WORDS_BIGENDIAN > > + swapendian_init(io_index); > > +#endif > > + break; > > So basically, you just moved the #ifdefs to another place. :) Many #ifdefs inconsistently scattered through all the device code have been replaced by a single #ifdef. > Shouldn't this be dependent on the CPU state and determined at > runtime? Thinking of MSR LE bit on ppc. I guess QEMU doesn't support > bi-endian ppc today, as does the 970, but it would be nice to keep it > in mind. Switching endianness of a CPU generally does not effect the endianness of the CPU/peripheral busses. It makes the CPU byteswap accesses before they are seen by either memory or devices. In theory it might be possible to avoid redundant byteswaps if you're really clever. In practice you still have to handle the fact that your devices are a different endianness to RAM, so it probably doesn't gain you a whole lot. Paul