On Thu, Nov 25, 2010 at 7:35 AM, Alexander Graf <ag...@suse.de> 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 :).
Nice approach, better than mine. I'm looking forward to see VGA converted ;-). It's used by almost all targets, so that conversion would save a lot of compile cycles.
