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

[Christoffer Dall]

On Tue, Jan 28, 2014 at 03:47:32PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-01-27 at 16:44 -0800, Christoffer Dall wrote:
> 
> > 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.
> 
> It doesn't matter once it's a byte array in address order. Again this is
> the *right* abstraction for the kernel ABI, because you do not care
> about the endianness of either side, guest or host.
> 
> It makes no sense to treat a modern CPU data bus as having an MSB and an
> LSB (even if they have it sometimes on the block diagram). Only when
> *interpreting a value* on that bus, such as an *address* does the
> endianness become of use.
> 
> Treat the bus instead as an ordered sequence of bytes in ascending
> address order and most of the complexity goes away.
> 
> From there, for a given device, it all depends which bytes *that device*
> choses to consider as being the MSB vs. LSB. It's not even a bus thing,
> though of course some busses suggest an endianness, and some like PCI
> mandates it for configuration space. 
> 
> But it remains a device-side choice.
> 
> > 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.
> 
> The ABI going to qemu should be (and inside qemu from TCG to the
> emulation) that the CPU did an access of N bytes wide at address A
> whose value is the byte array data[] in ascending address order.
> 
OK, I've sent a v3 of the ABI clarification patch following the wording
from you and Scott.  I think we all agree what the format should look
like at this point and hopefully we can quickly agree about a text to
describe that.

Thanks,
-Christoffer