On 17 January 2014 17:53, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > Specifically, the KVM API says "here's a uint8_t[] byte > array and a length", and the current QEMU code treats that > as "this is a byte array written as if the guest CPU > (a) were in TARGET_WORDS_BIGENDIAN order and (b) wrote its > I/O access to this buffer rather than to the device". > > The KVM API docs don't actually specify the endianness > semantics of the byte array, but I think that that really > needs to be nailed down. I can think of a couple of options: > * always LE > * always BE > [these first two are non-starters because they would > break either x86 or PPC existing code] > * always the endianness the guest is at the time > * always some arbitrary endianness based purely on the > endianness the KVM implementation used historically > * always the endianness of the host QEMU binary > * something else? > > Any preferences? Current QEMU code basically assumes > "always the endianness of TARGET_WORDS_BIGENDIAN", > which is pretty random. Having thought a little more about this, my opinion is: * we should specify that the byte order of the mmio.data array is host kernel endianness (ie same endianness as the QEMU process itself) [this is what it actually is, I think, for all the cases that work today] * we should fix the code path in QEMU for handling mmio.data which currently has the implicit assumption that when using KVM TARGET_WORDS_BIGENDIAN is the same as the QEMU host process endianness (because it's using load/store functions which swap if TARGET_WORDS_BIGENDIAN is different from HOST_WORDS_BIGENDIAN) thanks -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
