From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uxi3u-00066c-1d for qemu-devel@nongnu.org; Fri, 12 Jul 2013 14:27:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uxi3s-000193-FV for qemu-devel@nongnu.org; Fri, 12 Jul 2013 14:27:21 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:41060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uxi3s-00018m-7p for qemu-devel@nongnu.org; Fri, 12 Jul 2013 14:27:20 -0400 Received: by mail-la0-f41.google.com with SMTP id fn20so8009736lab.14 for ; Fri, 12 Jul 2013 11:27:19 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <878v1bvfaw.fsf@codemonkey.ws> 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> From: Peter Maydell Date: Fri, 12 Jul 2013 19:26:58 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Anthony Liguori Cc: Liu Ping Fan , Alexander Graf , qemu-devel Developers , "qemu-ppc@nongnu.org list:PowerPC" , Paolo Bonzini , Jan Kiszka , =?UTF-8?Q?Andreas_F=C3=A4rber?= , =?UTF-8?Q?Herv=C3=A9_Poussineau?= On 12 July 2013 18:49, Anthony Liguori wrote: > Benjamin Herrenschmidt writes: >> 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. > > Hrm, probably not. We don't propagate I/O spaces very well today. > >> In any case, I completely object to all that business with conversion in >> bridges. >> >> That's fundamentally WRONG. 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. >> 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.) thanks -- PMM