From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxgmG-0004s3-Qd for qemu-devel@nongnu.org; Fri, 12 Jul 2013 13:05:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxgmD-0001X4-P7 for qemu-devel@nongnu.org; Fri, 12 Jul 2013 13:05:04 -0400 Message-ID: <51E0372C.2070209@reactos.org> Date: Fri, 12 Jul 2013 19:04:44 +0200 From: =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= MIME-Version: 1.0 References: <51C75FA6.6080903@reactos.org> <51C7E21A.9090005@web.de> <8A36D64D-0625-49E1-9E59-391DAEEBD1FC@suse.de> <51DEA91B.40903@suse.de> <3FAA7DE1-06A0-45C5-885C-0433BCC0CFE8@suse.de> <5D205309-1154-4730-902E-BF07F5D3B4EB@suse.de> <1373581960.19894.109.camel@pasglop> <02433CA4-954D-4C56-A4A4-7BC0D62638C0@suse.de> <1373628932.19894.158.camel@pasglop> In-Reply-To: <1373628932.19894.158.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 11/14] ioport: Switch dispatching to memory core layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Liu Ping Fan , qemu-devel Developers , Alexander Graf , "qemu-ppc@nongnu.org list:PowerPC" , Paolo Bonzini , Jan Kiszka , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Benjamin Herrenschmidt a =C3=A9crit : > 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. >=20 > Single system wide IO space is broken. We have separate IO space per > PHB. That was working afaik. >=20 > In any case, I completely object to all that business with conversion i= n > bridges. >=20 > That's fundamentally WRONG. Indeed. >=20 > The whole business of endianness in qemu is a mess. In the end what > matters and the only thing that does is: >=20 > * 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..) >=20 On PowerPC PReP, you have the MSR:LE bit in the CPU, and the system=20 endianness (port 0x92 on PReP system I/O board). Of course, both can be=20 changed independently, but they are usually changed within a few=20 instructions. When only one of them is changed, this means some "interesting" things=20 can happen. For example, in [1]: "When PowerPC little-endian is in effect but before system's=20 little-endian is in effect, the address munge becomes effective. If we=20 need to access system endian port (byte) address, say 0x80000092, the=20 program needs to issue 0x80000095 instead, to compensate (unmunge) for=20 the effect of PowerPC address modification." Those will be required for QEMU to be able to run BeOS, AIX, or Windows=20 NT or PowerPC PReP. In the light of this, I think there should only be one endianness for=20 all memory accesses (which could be changed at runtime), and all=20 bridges/devices should ask for "same endianness as parent" or "reverse=20 endianness as parent", but not for big, little, or native endianness. Regards, Herv=C3=A9 [1] ftp://ftp.software.ibm.com/rs6000/technology/spec/endian.ps)