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 -- 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
