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

[Avi Kivity]

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.