From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSFjn-0008Mk-Lj for qemu-devel@nongnu.org; Tue, 05 Jan 2010 15:10:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSFjj-0008KG-0M for qemu-devel@nongnu.org; Tue, 05 Jan 2010 15:10:43 -0500 Received: from [199.232.76.173] (port=43173 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSFVv-0003HQ-Jt for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:56:23 -0500 Received: from mx20.gnu.org ([199.232.41.8]:36555) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSFVu-0005f5-Ep for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:56:22 -0500 Received: from gate.crashing.org ([63.228.1.57]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NRuSx-0004QS-AA for qemu-devel@nongnu.org; Mon, 04 Jan 2010 16:27:55 -0500 Subject: Re: [Qemu-devel] Re: [PATCH 1/6] Make config space accessor host bus trapable From: Benjamin Herrenschmidt In-Reply-To: <20100104211208.GA21488@redhat.com> References: <20100103174430.GA8522@redhat.com> <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> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Jan 2010 08:25:30 +1100 Message-ID: <1262640330.2173.386.camel@pasglop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Blue Swirl , Isaku Yamahata , Alexander Graf , Aurelien Jarno , QEMU Developers 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. 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.