[This seemed like a good jumping off point for this question.] On 16 January 2014 17:51, Alexander Graf <agraf@xxxxxxx> wrote: > Am 16.01.2014 um 18:41 schrieb Peter Maydell <peter.maydell@xxxxxxxxxx>: >> Also see my remarks on the previous patch series suggesting >> that we should look at this in a more holistic way than >> just randomly fixing small bits of things. A good place >> to start would be "what should the semantics of stl_p() >> be for a QEMU where the CPU is currently operating with >> a reversed endianness to the TARGET_WORDS_BIGENDIAN >> setting?". > > That'd open a giant can of worms that I'd rather not open. Yeah, but you kind of have to open that can, because stl_p() is used in the code path for KVM MMIO accesses to devices. 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. 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
