On Wed, Jan 22, 2014 at 02:27:29PM +0530, Anup Patel wrote: [...] > > Thanks for the info on QEMU side handling of MMIO data. > > I was not aware that we would be only have "target endian = LE" > for ARM/ARM64 in QEMU. I think Marc Z had mentioned similar > thing about MMIO this in our previous discussions on his patches. > (Please refer, http://www.spinics.net/lists/arm-kernel/msg283313.html) > > This clearly means MMIO data passed to user space (QEMU) has > to of host endianness so that QEMU can take care of bust->device > endian map. Hmmm, I'm not sure what you mean exactly, but the fact remains that we simply need to decide on a layout of mmio.data that (1) doesn't break existing userspace (2) is clearly defined for mixed-mmio use cases. > > Current vcpu_data_guest_to_host() and vcpu_data_host_to_guest() > does not perform endianness conversion of MMIO data to LE when > we are running LE guest on BE host so we do need Victor's patch > for fixing vcpu_data_guest_to_host() and vcpu_data_host_to_guest(). > (Already reported long time back by me, > http://www.spinics.net/lists/arm-kernel/msg283308.html) > The problem is that we cannot decide on how the patch should look like before the endianness of mmio.data is decided. Alex, Peter, and I agree that it should be that of the host endianness and represent what the architecture in question would put on the memory bus. In the case of ARM, it's the register value when the VCPU E-bit is clear, and it's the byteswapped register value when the VCPU E-bit is set. Therefore, the patch needs to do an unconditional byteswap when the VCPU E-bit is set, instead of the beXX_to_cpu and cpu_to_beXX. I'm sending out a patch to clarify the KVM API so we can move on. -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
