> Am 18.01.2014 um 05:24 schrieb Christoffer Dall <christoffer.dall@xxxxxxxxxx>: > >> On Fri, Jan 17, 2014 at 06:52:57PM +0000, Peter Maydell wrote: >>> 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] > > I completely agree, given that it's too late to be set on always LE/BE, > I think the natural choice is something that allows a user to cast the > byte array to an appropriate pointer type and dereference it. > > And I think we need to amend the KVM API docs to specify this. I don't see the problem. For ppc we always do mmio emulation as if the cpu was big endian. We've had an is_bigendian variable for that since the very first versions. Alex > > -- > Christoffer -- 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
