From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50515 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLaj4-0003JB-Jj for qemu-devel@nongnu.org; Thu, 25 Nov 2010 07:14:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PLaj3-00037j-9g for qemu-devel@nongnu.org; Thu, 25 Nov 2010 07:14:58 -0500 Received: from mail.codesourcery.com ([38.113.113.100]:46264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PLaj3-00037N-1T for qemu-devel@nongnu.org; Thu, 25 Nov 2010 07:14:57 -0500 From: Paul Brook Date: Thu, 25 Nov 2010 12:14:46 +0000 References: <1290670555-12575-1-git-send-email-agraf@suse.de> In-Reply-To: <1290670555-12575-1-git-send-email-agraf@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011251214.46800.paul@codesourcery.com> Subject: [Qemu-devel] Re: [PATCH 00/15] [RFC] MMIO endianness cleanup List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Blue Swirl , QEMU-devel Developers > The way mmio endianness is currently implemented is horrifying. Agreed. > #ifdef TARGET_WORDS_BIGENDIAN > val = bswap32(val); > #endif > > With the move to get device code only compiled once, this has > become harder and harder to justify though, since we don't know > the target endianness during compile time. Not just that, it's wrong to start with. I've used machines with both native and cross-endian 16550 based UARTs. > So my solution to the issue is to make every device define if > it's a little, big or native (target) endianness device. This > basically tells the layers below what endianness the device > expects mmio to occur in. Little endian devices on little endian > hosts don't swap. On big endian hosts they do. Same the other > way around. > > The only reason I added "native" endianness is that we have some > PV devices like the fw_cfg that expect qemu's broken behavior. > These devices are the minority though. In the long run I'd expect > to see most code be committed with either of the two endianness > choices. I'd prefer to avoid this, or at least document it as a temporary hack that should be removed. If a device can exist in either endian, then we really want to push this decision down to the board-level code. One of the reasons I haven't bothered fixing this yet is that this feels like something that should be a device/bus property. e.g. PCI devices/busses are always little-endian[1], as as mentioned above some devices come in both flavors. I guess we can go with your approach for now, and make sure we fix this properly when we introduce bus-specific registration functions. Paul [1] Ignoring magical byteswapping cpu-pci bridges, but they're broken by design, and thankfully quite rare.