[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Hervé Poussineau
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer
Date: Fri, 12 Jul 2013 19:04:44 +0200
User-agent: Thunderbird (Windows/20090812)

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

That's fundamentally WRONG.


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.



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]