Re: [Qemu-devel] [Qemu-ppc] KVM and variable-endianness guest CPUs

[Christoffer Dall]

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