On 17.01.2014, at 19:52, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 17 January 2014 17:53, Peter Maydell <peter.mayd...@linaro.org> 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) Yes, I fully agree :). Alex
