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

2014-01-28 Thread Avi Kivity
On 01/28/2014 01:27 AM, Benjamin Herrenschmidt wrote: On Wed, 2014-01-22 at 17:29 +, Peter Maydell wrote: Basically if it would be on real bus, get byte value that corresponds to phys_addr + 0 address place it into data[0], get byte value that corresponds to phys_addr + 1 address place it

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

2014-01-28 Thread 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

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

2014-01-27 Thread Benjamin Herrenschmidt
On Wed, 2014-01-22 at 17:29 +, Peter Maydell wrote: Basically if it would be on real bus, get byte value that corresponds to phys_addr + 0 address place it into data[0], get byte value that corresponds to phys_addr + 1 address place it into data[1], etc. This just isn't how real

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

2014-01-27 Thread Benjamin Herrenschmidt
On Wed, 2014-01-22 at 11:29 -0800, Victor Kamensky wrote: I don't see why you so attached to desire to describe data part of memory transaction as just one of int types. If we are talking about bunch of hypothetical cases imagine such bus that allow transaction with size of 6 bytes. How do

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

2014-01-27 Thread Benjamin Herrenschmidt
On Wed, 2014-01-22 at 20:02 +, Peter Maydell wrote: Defining it as being always guest-order would mean that userspace had to continually look at the guest CPU endianness bit, which is annoying and awkward. Defining it as always host-endian order is the most reasonable option

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

2014-01-27 Thread Peter Maydell
On 27 January 2014 23:34, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2014-01-22 at 20:02 +, Peter Maydell wrote: Defining it as being always guest-order would mean that userspace had to continually look at the guest CPU endianness bit, which is annoying and awkward.

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

2014-01-27 Thread Benjamin Herrenschmidt
On Tue, 2014-01-28 at 11:07 +1100, Benjamin Herrenschmidt wrote: On Thu, 2014-01-23 at 15:33 +, Peter Maydell wrote: (4) PPC CPUs in BE mode and ARM CPUs in BE mode are not the same, because in the ARM case it is doing an internal-to-CPU byteswap, and in the PPC case it is

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

2014-01-27 Thread Benjamin Herrenschmidt
On Thu, 2014-01-23 at 15:33 +, Peter Maydell wrote: (4) PPC CPUs in BE mode and ARM CPUs in BE mode are not the same, because in the ARM case it is doing an internal-to-CPU byteswap, and in the PPC case it is not Aren't they both byte-order invariant ? In that case they are the

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

2014-01-27 Thread Benjamin Herrenschmidt
The point is simple, and Peter has made it over and over: Any consumer of a memory operation sees value, len, address. This is what KVM_EXIT_MMIO emulates. So just by knowing the ABI definition and having a pointer to the structure you need to be able to tell me value, len, address. But

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

2014-01-27 Thread Benjamin Herrenschmidt
On Thu, 2014-01-23 at 20:11 -0800, Victor Kamensky wrote: I would take 50 byteswaps with a clear ABI any day over an obscure standard that can avoid a single hardware-on-register instruction. This is about designing a clean software interface, not about building an optimized integrated

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

2014-01-27 Thread Benjamin Herrenschmidt
On Mon, 2014-01-27 at 23:49 +, 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

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

2014-01-27 Thread Christoffer Dall
On Tue, Jan 28, 2014 at 11:32:41AM +1100, Benjamin Herrenschmidt wrote: On Thu, 2014-01-23 at 20:11 -0800, Victor Kamensky wrote: I would take 50 byteswaps with a clear ABI any day over an obscure standard that can avoid a single hardware-on-register instruction. This is about

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

2014-01-27 Thread Christoffer Dall
On Tue, Jan 28, 2014 at 11:36:13AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2014-01-27 at 23:49 +, 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.

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

2014-01-27 Thread Benjamin Herrenschmidt
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

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

2014-01-23 Thread Alexander Graf
On 23.01.2014, at 05:25, Victor Kamensky victor.kamen...@linaro.org wrote: Hi Alex, Sorry, for delayed reply, I was focusing on discussion with Peter. Hope you and other folks may get something out of it :). Please see responses inline On 22 January 2014 02:52, Alexander Graf

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

2014-01-23 Thread Greg Kurz
On Wed, 22 Jan 2014 20:25:05 -0800 Victor Kamensky victor.kamen...@linaro.org wrote: Hi Alex, Sorry, for delayed reply, I was focusing on discussion with Peter. Hope you and other folks may get something out of it :). Please see responses inline On 22 January 2014 02:52, Alexander

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

2014-01-23 Thread 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

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

2014-01-22 Thread Anup Patel
Hi Alex, On Wed, Jan 22, 2014 at 12:11 PM, Alexander Graf ag...@suse.de wrote: Am 22.01.2014 um 07:31 schrieb Anup Patel a...@brainfault.org: On Wed, Jan 22, 2014 at 11:09 AM, Victor Kamensky victor.kamen...@linaro.org wrote: Hi Guys, Christoffer and I had a bit heated chat :) on this

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

2014-01-22 Thread Alexander Graf
On 22.01.2014, at 08:26, Victor Kamensky victor.kamen...@linaro.org wrote: On 21 January 2014 22:41, Alexander Graf ag...@suse.de wrote: Native endian really is just a shortcut for target endian which is LE for ARM and BE for PPC. There shouldn't be a qemu-system-armeb or

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

2014-01-22 Thread Victor Kamensky
Hi Alex, Sorry, for delayed reply, I was focusing on discussion with Peter. Hope you and other folks may get something out of it :). Please see responses inline On 22 January 2014 02:52, Alexander Graf ag...@suse.de wrote: On 22.01.2014, at 08:26, Victor Kamensky victor.kamen...@linaro.org

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

2014-01-21 Thread Alexander Graf
Am 22.01.2014 um 07:31 schrieb Anup Patel a...@brainfault.org: On Wed, Jan 22, 2014 at 11:09 AM, Victor Kamensky victor.kamen...@linaro.org wrote: Hi Guys, Christoffer and I had a bit heated chat :) on this subject last night. Christoffer, really appreciate your time! We did not

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

2014-01-21 Thread Victor Kamensky
On 21 January 2014 22:41, Alexander Graf ag...@suse.de wrote: Am 22.01.2014 um 07:31 schrieb Anup Patel a...@brainfault.org: On Wed, Jan 22, 2014 at 11:09 AM, Victor Kamensky victor.kamen...@linaro.org wrote: Hi Guys, Christoffer and I had a bit heated chat :) on this subject last night.