From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSFbp-0005Hs-3d for qemu-devel@nongnu.org; Tue, 05 Jan 2010 15:02:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSFbk-0005HE-PI for qemu-devel@nongnu.org; Tue, 05 Jan 2010 15:02:28 -0500 Received: from [199.232.76.173] (port=43167 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSFVs-0003G1-8D for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:56:20 -0500 Received: from mx20.gnu.org ([199.232.41.8]:36554) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSFVr-0005es-3L for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:56:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NRuYU-0004qU-7W for qemu-devel@nongnu.org; Mon, 04 Jan 2010 16:33:38 -0500 Date: Mon, 4 Jan 2010 23:30:21 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH 1/6] Make config space accessor host bus trapable Message-ID: <20100104213021.GC21488@redhat.com> References: <41679128-EE37-47DA-82F6-830A4C364183@suse.de> <20100103180609.GB8522@redhat.com> <472F306A-0699-401C-8E6A-8E79B86E4C95@suse.de> <1262551822.2173.267.camel@pasglop> <19BFDDD5-85E0-42EC-9D71-391CECC023F5@suse.de> <20100104104516.GD4672@valinux.co.jp> <20100104110758.GE8522@redhat.com> <1262635858.2173.371.camel@pasglop> <20100104211208.GA21488@redhat.com> <1262640330.2173.386.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1262640330.2173.386.camel@pasglop> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Blue Swirl , Isaku Yamahata , Alexander Graf , Aurelien Jarno , QEMU Developers On Tue, Jan 05, 2010 at 08:25:30AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2010-01-04 at 23:12 +0200, Michael S. Tsirkin wrote: > > Well, the main issue if I understand correcttly is that basically the > > same hardware bridge can be connected to host in different ways. Yes, we > > can say "if it's connected differently it's a different device" but this > > is slightly ugly, device should not have to know how it's connected. It > > would be cleaner to have a "connector" device in the middle that swaps > > bytes. Even though yes, what you describe would be less ugly than using > > proprocessor as we do now. > > Well, the thing is... PCI is always little endian. > I'm not 100% familiar > on how emulation of devices works in qemu, but it's possible that the > problem here is simply not how a standard PCI host bridge is connected > to the processor changing but rather whether it's connected to an x86 > host or a ppc host should make the byte order appear different. IE. a > PPC operating system will byteswap accesses. If qemu just passes on > accesses -as-is- instead of doing natural byteswapping then indeed you > will need that added swap there too. > Yes, but I think how you program your host to pci bridge is platform specific, the standard (mostly) applies to what happens below the bridge. There's no real standard for how PCI host bridge is connected to processor AFAIK, it's by luck we can share code there at all. > I still think though that this should be buried in the accessors for the > host bridge themselves, eventually controlled by a flag set when > instanciating the host bridge in case it can indeed be wired in > different ways. > > Cheers, > Ben. > buried sounds scary, but generally yes, a flag in host bridge code is the idea.