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

["Hervé Poussineau" <hpoussin@reactos.org>]

Benjamin Herrenschmidt a écrit :
> On Fri, 2013-07-12 at 05:18 +0200, Alexander Graf wrote:
>> We model a single system wide io space today and access to that one
>> happens through you pci host controller. I just messed up the
>> terminology here.
> 
> Single system wide IO space is broken. We have separate IO space per
> PHB. That was working afaik.
> 
> In any case, I completely object to all that business with conversion in
> bridges.
> 
> That's fundamentally WRONG.

Indeed.

> 
> The whole business of endianness in qemu is a mess. In the end what
> matters and the only thing that does is:
> 
>  * The endianness of a given memory access by the guest (which may or
> may not be the endianness of the guest -> MSR:LE, byteswap load/store
> instsructions, etc..)
> 

On PowerPC PReP, you have the MSR:LE bit in the CPU, and the system 
endianness (port 0x92 on PReP system I/O board). Of course, both can be 
changed independently, but they are usually changed within a few 
instructions.

When only one of them is changed, this means some "interesting" things 
can happen. For example, in [1]:
"When PowerPC little-endian is in effect but before system's 
little-endian is in effect, the address munge becomes effective. If we 
need to access system endian port (byte) address, say 0x80000092, the 
program needs to issue 0x80000095 instead, to compensate (unmunge) for 
the effect of PowerPC address modification."

Those will be required for QEMU to be able to run BeOS, AIX, or Windows 
NT or PowerPC PReP.

In the light of this, I think there should only be one endianness for 
all memory accesses (which could be changed at runtime), and all 
bridges/devices should ask for "same endianness as parent" or "reverse 
endianness as parent", but not for big, little, or native endianness.

Regards,

Hervé

[1] ftp://ftp.software.ibm.com/rs6000/technology/spec/endian.ps)