Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer

[Benjamin Herrenschmidt]

On Fri, 2013-07-12 at 14:06 -0500, Anthony Liguori wrote:
> > In the light of this, I think there should only be one endianness
> for 
> > all memory accesses (which could be changed at runtime),
> 
> We already do this, it's "host native endian".

The simple fact that you used the word "endian" makes it broken here :-)

If the guest has done a byte reverse access for example, what you have
is not "host native endian" anymore.

The simple fact that you use "endian" to describe what you carry around
is a source of wrongness and errors. It's misleading and people always
get that wrong (I did a bloody talk on the matter at two conferences now
and it seems people really don't get what endianness really is about).

> > and all 
> > bridges/devices should ask for "same endianness as parent" or
> "reverse 
> > endianness as parent", but not for big, little, or native
> endianness.
> 
> I/O doesn't propagate so there's no way to say something like this.
> That's the fundamental problem IMHO.

There is no such thing as "endianness of parent" again. This is all
wrong. Wrong terminology, wrong concepts.

Do not try to use the "endian" attribute on a bus or bridge, it will
only confuse things further.

Stick to what is the byte order of your transport (much more precise
term, ie. which byte is the lowest address within the host variable that
carries the access).

Ben.