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

[Alexander Graf]

On 26.11.2010, at 19:44, Blue Swirl wrote:

> On Thu, Nov 25, 2010 at 7:35 AM, Alexander Graf <address@hidden> 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.

The only issue for VGA should be the frame buffer. Since we can keep that as 
DEVICE_NATIVE_ENDIAN, we should be good. I hope. Not sure yet. :)

So far there hasn't really been any negative feedback. Should we take this RFC 
as v1 and just merge it?


Alex