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

[Christoffer Dall <christoffer.dall@linaro.org>]

On Tue, Jan 28, 2014 at 11:36:13AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-01-27 at 23:49 +0000, Peter Maydell wrote:
> > 
> > Er, what? If we make the array be guest's current order
> > then by definition userspace has to look at the guest's
> > current endianness. I agree that would be bad. Either
> > of the two current proposals (host kernel order; guest
> > CPU's native/natural/default-byte-order) avoid it, though.
> 
> No, this has nothing to do with the guest endianness, and
> all to do about the (hopefully) byte-address invariant bus we have
> on the processor.
> 
> Anyway, the existing crap is ABI so I suspect we have to stick with it,
> just maybe document it better.
> 

I'm loosing track of this discussion, Ben, can you explain a bit?  You
wrote:

  Having a byte array coming in that represents what the CPU does in its
  current byte order means you do *NOT* need to query the endianness of
  the guest CPU from userspace.

What does "a byte array that represents what the CPU does in its current
byte order" mean in this context.  Do you mean the VCPU or the physical
CPU when you say CPU.

I read your text as saying "just do a store of the register into the
data pointer and don't worry about endianness", but somebody, somewhere,
has to check the VCPU endianness setting.

I'm probably wrong, and you are probably the right person to clear this
up, but can you formulate exactly what you think the KVM ABI is and how
you would put it in Documentation/virtual/kvm/api.txt?

My point of view is that it is KVM that needs to do this, and it should
"emulate the CPU" by performing a byteswap in the case where the CPU
E-bit is set on ARM, but this is an ARM-centric way of looking at
things.

Thanks,
-Christoffer