On 18 January 2014 07:32, Alexander Graf <ag...@suse.de> wrote: >> Am 18.01.2014 um 05:24 schrieb Christoffer Dall >> <christoffer.d...@linaro.org>: >>> On Fri, Jan 17, 2014 at 06:52:57PM +0000, Peter Maydell wrote: >>> 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.
The problem is (a) the docs aren't clear about the semantics (b) people have picked behaviour that suited them to implement without documenting what it was. > For ppc we always do mmio emulation > as if the cpu was big endian. Even if the guest, the host kernel and QEMU in userspace are all little endian? Also "mmio emulation as if the CPU was big endian" doesn't make sense -- MMIO emulation doesn't depend on CPU endianness. > We've had an is_bigendian variable > for that since the very first versions. Where? In the kernel? In QEMU? What does it control? thanks -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
