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.
Alex
|