Re: [Qemu-ppc] [PULL for-2.0 2/7] raven: Implement non-contiguous I/O region

[Peter Maydell]

On 7 April 2014 20:31, Paolo Bonzini <address@hidden> wrote:
> I think if you are using address_space_read/write
> then you must use DEVICE_NATIVE_ENDIAN

I think it's actually worse than that. address_space_read/write
have an API which requires you to pass them a buffer which is
in guest CPU endianness. This means they cannot be used from
target-independent source files (like hw/pci-host/prep.c)
because there's no way to say "write this 32 bit value to
the buffer in target endianness". ioport.c which has pretty
much identical code works OK because it is built per target.

Worse, we have two versions of the ldl_p()/stl_p() &c
functions with conflicting semantics!
cpu-all.h defines these to be "target CPU endianness".
bswap.h defines these to be "host CPU endianness".
So which version any particular source file gets depends
on which of these two headers it ends up with. prep.c gets
the bswap.h versions, and exec.c gets the cpu-all.h versions,
which means on x86 we get the bizarre effect of doing an
stl_p() into a buffer in raven_io_write() and then having
address_space_rw() do a ldl_p() from the buffer and getting
a different value...

thanks
-- PMM