From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UxmAp-0005oD-3e for qemu-devel@nongnu.org; Fri, 12 Jul 2013 18:50:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UxmAn-0003nv-QX for qemu-devel@nongnu.org; Fri, 12 Jul 2013 18:50:47 -0400 Message-ID: <1373669427.19894.202.camel@pasglop> From: Benjamin Herrenschmidt Date: Sat, 13 Jul 2013 08:50:27 +1000 In-Reply-To: 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> <878v1bvfaw.fsf@codemonkey.ws> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Peter Maydell Cc: Liu Ping Fan , Alexander Graf , qemu-devel Developers , "qemu-ppc@nongnu.org list:PowerPC" , Anthony Liguori , Paolo Bonzini , Jan Kiszka , Andreas =?ISO-8859-1?Q?F=E4rber?= , =?ISO-8859-1?Q?Herv=E9?= Poussineau On Fri, 2013-07-12 at 19:26 +0100, Peter Maydell wrote: > It's not wrong when the hardware actually does a byteswap at > some level in the memory hierarchy. You can see this for instance > on ARMv7M systems, where byteswapping for bigendian happens at > an intermediate level that not all accesses go through: > > [CPU] ----> [byteswap here] --> [memory and ext. devices] > | > --> [internal memory mapped devices] > > so some things see always little endian regardless. Ugh ? That's so completely fucked up, if that's indeed what the HW is doing this is a piece of trash and the designers are in urgent need of being turned into fertilizer. Unless again you are talking about "lane swapping" which allows to preserve the byte address invariance when the CPU decides to flip its bus around, but I would have thought that modern CPUs do not do that sort of shit anymore. In any case, it cannot be represented with an "endian" attribute at the bridge level, that doesn't mean anything. Again, the only endian attribute that exists are the byte order of the original access (which byte has the lowest address, regardless of significance of those bytes in the target, ie, purely from a qemu standpoint, in the variable that carries the access around inside qemu, which byte has the lowest address), and the same on the target device (at which point a concept of significance does apply, but it's a guest driver business to get it right, qemu just need to make sure byte 0 goes to byte 0). If a bridge flips things around in a way that breaks the model, then add some property describing the flipping properties but don't call it "big endian" or "little endian" at the bridge level, that has no meaning, confuses things and introduces breakage like we have seen. > >> The whole business of endianness in qemu is a mess. In the end what > >> matters and the only thing that does is: > > > > It's not as bad as you think I suspect. > > > >> * 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..) > > > > Correct. > > > >> vs. > >> > >> * The endianness of the target device register (and I say register ... > >> a framebuffer does NOT have endianness per-se and thus accesses to BAR > >> mapping a "memory" range (framebuffer, ROM, ...) should go such that the > >> *byte order* of individual bytes is preserved, which typically means > >> untranslated). > > > > Yes. To put it another way, an MMIO write is a store and depending on > > the VCPU, that will result in a write with a certain byte order. That > > byte order should be preserved. > > > > However, what we don't model today, and why we have the silly > > endianness in MemoryRegionOps, is the fact that I/O may pass through > > multiple layers and those layers may change byte ordering. > > > > We jump through great hoops to have a flat dispatch table. I've never > > liked it but that's what we do. That means that in cases where a host > > bridge may do byte swapping, we cannot easily support that. > > We could support that if we cared to -- you just have to have a > container MemoryRegion type which is a byte-swapping container > (or just have a flag on existing containers, I suppose). > Then as you flatten the regions into the flat table you keep > track of how many levels of byteswapping each region goes through, > and you end up with a single 'byteswap or not?' flag for each > section of your flat dispatch table. > > (Our other serious endianness problem is that we don't really > do very well at supporting a TCG CPU arbitrarily flipping > endianness -- TARGET_WORDS_BIGENDIAN is a compile time setting > and ideally it should not be.) Our experience is that it actually works fine for almost everything except virtio :-) ie mostly TARGET_WORDS_BIGENDIAN is irrelevant (and should be). Cheers, Ben.