On 25.11.2010, at 11:18, 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.
We only have a single opaque for mmio, so I don't see the value-add. There is a simple mmio version already in rwhandler.c btw. http://git.qemu.org/qemu.git/commit/?id=049f7adbd547969ba013fed13c0a26c1f62a4a71 Alex
