From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W80ao-0002kD-3I for qemu-devel@nongnu.org; Mon, 27 Jan 2014 23:48:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W80ai-0004Rv-4u for qemu-devel@nongnu.org; Mon, 27 Jan 2014 23:48:10 -0500 Message-ID: <1390884452.3872.84.camel@pasglop> From: Benjamin Herrenschmidt Date: Tue, 28 Jan 2014 15:47:32 +1100 In-Reply-To: <20140128004443.GB9687@cbox> References: <20140120191919.GH13432@cbox> <1390865691.3872.33.camel@pasglop> <1390869373.3872.43.camel@pasglop> <20140128004443.GB9687@cbox> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] KVM and variable-endianness guest CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoffer Dall Cc: Peter Maydell , Thomas Falcon , kvm-devel , Victor Kamensky , QEMU Developers , "qemu-ppc@nongnu.org" , "kvmarm@lists.cs.columbia.edu" 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. Ben.