From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55365 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PLZHs-0004P4-Bi for qemu-devel@nongnu.org; Thu, 25 Nov 2010 05:42:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PLZHr-0004F1-54 for qemu-devel@nongnu.org; Thu, 25 Nov 2010 05:42:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PLZHq-0004EM-Tg for qemu-devel@nongnu.org; Thu, 25 Nov 2010 05:42:47 -0500 Date: Thu, 25 Nov 2010 12:42:33 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH 00/15] [RFC] MMIO endianness cleanup Message-ID: <20101125104233.GB6897@redhat.com> References: <1290670555-12575-1-git-send-email-agraf@suse.de> <4CEE37F2.8040000@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CEE37F2.8040000@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Blue Swirl , Paul Brook , Alexander Graf , QEMU-devel Developers On Thu, Nov 25, 2010 at 11:18:26AM +0100, Gerd Hoffmann wrote: > On 11/25/10 08:35, Alexander Graf wrote: > >The way mmio endianness is currently implemented is horrifying. > > > >In the real world, CPUs have an endianness and write out data > >to the memory bus. Instead of RAM, a receiving side here can be > >a device. This device gets a byte stream again and needs to > >make sense of it. > > > >Since big endian systems write big endian numbers into memory > >while little endian systems write little endian numbers there, > >the device and software on the CPU need to be aware of this. > > > >In practice, most devices these days (ISA, PCI) assume that > >the data is little endian. So to communicate with such a device > >from the CPU's side, the OS byte swaps all MMIO. > > > >In qemu however, we simply pass the register value we find on > >to the device. So any byte mangling the guest does to compensate > >for the transfer screw us up by exposing byte swapped MMIO > >on the device's side. > > > >The way this has been fixed historically is by constructs like > >this one: > > > >#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. > > > >It's especially bad since it doesn't make any sense at all to > >clutter all the device code with endianness workarounds, aside > >from the fact that about 80% of the device code currently does > >the wrong thing :). > > > >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. > > > >The patch set also includes a bunch of conversions for devices > >that were already aware of endianness. > > > >This is an RFC, so please comment as much as you can :). > > Seen http://git.qemu.org/qemu.git/commit/?id=acd1c812b5548c8426e093075362b6d4119db6ac > ? > > I think it make sense to either extend it so it works for mmio too > (and add the endian awareness along the way) or create something > simliar for mmio. > FWTW when I asked why addr and data in IORange are 64bit I was told that it is intended for use with MMIO too. -- Gleb.