Re: [Qemu-devel] [PATCH 00/15] [RFC] MMIO endianness cleanup

[Gleb Natapov <gleb@redhat.com>]

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.