On 7 April 2014 20:31, Paolo Bonzini <pbonz...@redhat.com> 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
