From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W84mM-0006HW-CY for qemu-devel@nongnu.org; Tue, 28 Jan 2014 04:16:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W84mE-0002k9-58 for qemu-devel@nongnu.org; Tue, 28 Jan 2014 04:16:22 -0500 Received: from mail-wg0-f48.google.com ([74.125.82.48]:51528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W84mD-0002jc-Um for qemu-devel@nongnu.org; Tue, 28 Jan 2014 04:16:14 -0500 Received: by mail-wg0-f48.google.com with SMTP id x13so242192wgg.27 for ; Tue, 28 Jan 2014 01:16:13 -0800 (PST) Message-ID: <52E77559.4020800@cloudius-systems.com> Date: Tue, 28 Jan 2014 11:16:09 +0200 From: Avi Kivity MIME-Version: 1.0 References: <03D15FE3-2A12-4D60-8D20-07D05F3740F6@suse.de> <20140120191919.GH13432@cbox> <1390865229.3872.27.camel@pasglop> In-Reply-To: <1390865229.3872.27.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Benjamin Herrenschmidt , Peter Maydell Cc: Thomas Falcon , kvm-devel , Victor Kamensky , QEMU Developers , "qemu-ppc@nongnu.org" , "kvmarm@lists.cs.columbia.edu" , Christoffer Dall On 01/28/2014 01:27 AM, Benjamin Herrenschmidt wrote: > On Wed, 2014-01-22 at 17:29 +0000, 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 buses work. > Actually it can be :-) > >> There is no >> "address + 1, address + 2". There is a single address >> for the memory transaction and a set of data on >> data lines and some separate size information. >> How the device at the far end of the bus chooses >> to respond to 32 bit accesses to address X versus >> 8 bit accesses to addresses X through X+3 is entirely >> its own business and unrelated to the CPU. > However the bus has a definition of what byte lane is the lowest in > address order. Byte order invariance is an important function of > all busses. > > I think that trying to treat it any differently than an address > ordered series of bytes is going to turn into a complete and > inextricable mess. I agree. The two options are: (address, byte array, length) and (address, value, word size, endianness) the first is the KVM ABI, the second is how MemoryRegions work. Both are valid, but the first is more general (supports the 3-byte accesses sometimes generated on x86). > >> (It would >> be perfectly possible to have a device which when >> you read from address X as 32 bits returned 0x12345678, >> when you read from address X as 16 bits returned >> 0x9abc, returned 0x42 for an 8 bit read from X+1, >> and so on. Having byte reads from X..X+3 return >> values corresponding to parts of the 32 bit access >> is purely a convention.) > Right, it's possible. It's also stupid and not how most modern devices > and busses work. Besides there is no reason why that can't be > implemented with Victor proposal anyway. Right.