From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uxlzm-000353-9u for qemu-devel@nongnu.org; Fri, 12 Jul 2013 18:39:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uxlzl-0003Go-A8 for qemu-devel@nongnu.org; Fri, 12 Jul 2013 18:39:22 -0400 Message-ID: <1373668747.19894.191.camel@pasglop> From: Benjamin Herrenschmidt Date: Sat, 13 Jul 2013 08:39:07 +1000 In-Reply-To: <51E0372C.2070209@reactos.org> 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> <51E0372C.2070209@reactos.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 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: =?ISO-8859-1?Q?Herv=E9?= Poussineau Cc: Liu Ping Fan , qemu-devel Developers , Alexander Graf , "qemu-ppc@nongnu.org list:PowerPC" , Paolo Bonzini , Jan Kiszka , Andreas =?ISO-8859-1?Q?F=E4rber?= On Fri, 2013-07-12 at 19:04 +0200, Herv=C3=A9 Poussineau wrote: > "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." >=20 > Those will be required for QEMU to be able to run BeOS, AIX, or Windows= =20 > NT or PowerPC PReP. Funnily enough we've dropped support for Linux on PReP a long time ago :-) > 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. Right. I would in fact avoid the term "endianness" that tends to confuse people and basically stick to this: - For a given access, know (attribute) which byte is first in ascending address order - For a given target *register* (and again, this ONLY applies to registe= rs and in fact, some devices might change their register "endianness" and al= so have several banks with a different one), which byte is first in ascendin= g address order. This is at that point that a conversion might need to occur, and only at = that point if there is a mismatch. Ben.