[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 00/15] [RFC] MMIO endianness cleanup
From: |
Blue Swirl |
Subject: |
[Qemu-devel] Re: [PATCH 00/15] [RFC] MMIO endianness cleanup |
Date: |
Fri, 26 Nov 2010 18:44:31 +0000 |
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.
- Re: [Qemu-devel] [PATCH 08/15] prep: Declare as little endian, (continued)
[Qemu-devel] [PATCH 10/15] ppc4xx_pci: Declare as little endian, Alexander Graf, 2010/11/25
[Qemu-devel] [PATCH 09/15] versatile_pci: Declare as little endian, Alexander Graf, 2010/11/25
[Qemu-devel] [PATCH 14/15] isa_mmio: Always use little endian, Alexander Graf, 2010/11/25
[Qemu-devel] [PATCH 02/15] Add endianness as io mem parameter, Alexander Graf, 2010/11/25
Re: [Qemu-devel] [PATCH 00/15] [RFC] MMIO endianness cleanup, Gerd Hoffmann, 2010/11/25
[Qemu-devel] Re: [PATCH 00/15] [RFC] MMIO endianness cleanup, Paul Brook, 2010/11/25
[Qemu-devel] Re: [PATCH 00/15] [RFC] MMIO endianness cleanup,
Blue Swirl <=