From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4Af4-0006v0-35 for qemu-devel@nongnu.org; Sun, 04 Mar 2012 07:35:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4Af2-0006n6-3W for qemu-devel@nongnu.org; Sun, 04 Mar 2012 07:35:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4Af1-0006n2-RN for qemu-devel@nongnu.org; Sun, 04 Mar 2012 07:35:36 -0500 Message-ID: <4F53618B.6020101@redhat.com> Date: Sun, 04 Mar 2012 14:35:23 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20120304094614.GA8158@redhat.com> <20120304123302.GA11527@redhat.com> In-Reply-To: <20120304123302.GA11527@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] pci: fix bridge IO/BASE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Blue Swirl , Mark Cave-Ayland , qemu-devel@nongnu.org, Anthony Liguori On 03/04/2012 02:33 PM, Michael S. Tsirkin wrote: > On Sun, Mar 04, 2012 at 10:27:24AM +0000, Blue Swirl wrote: > > On Sun, Mar 4, 2012 at 09:46, Michael S. Tsirkin wrote: > > > commit 5caef97a16010f818ea8b950e2ee24ba876643ad introduced > > > a regression: we do not make IO base/limit upper 16 > > > bit registers writeable, so we should report a 16 bit > > > IO range type, not a 32 bit one. > > > Note that PCI_PREF_RANGE_TYPE_32 is 0x0, but PCI_IO_RANGE_TYPE_32 is 0x1. > > > > > > In particular, this broke sparc64. > > > > > > Note: this just reverts to behaviour prior to the patch. > > > Making PCI_IO_BASE_UPPER16 and PCI_IO_LIMIT_UPPER16 > > > registers writeable should, and seems to, work just as well, but > > > as no system seems to actually be interested in 32 bit IO, > > > let's not make unnecessary changes. > > > > > > Reported-by: Mark Cave-Ayland > > > Signed-off-by: Michael S. Tsirkin > > > > > > Mark, can you confirm that this fixes the bug for you? > > > > No, running > > qemu-system-sparc64 -serial stdio > > still shows black screen and the following on console: > > OpenBIOS for Sparc64 > > Unhandled Exception 0x0000000000000032 > > PC = 0x00000000ffd19e18 NPC = 0x00000000ffd19e1c > > Stopping execution > > > > This unassigned memory exception is triggered because CMD646 IDE I/O > > registers are not accessible: > > So here's a theory: the issue is that both device IO > and bridge IO have the same priority. > Bridge is initialized with IO at 0 to 4K > and so we have two devices at the same priority. > And flipping a type bit affects this, by chance? What device shares its BAR with the bridge I/O window? > I tried the following and it seems to help. > But the real fix IMO is to either disable the bridge ranges > at reset, in hardware, or have the BIOS do this. > > Avi, could you pls comment on my analysis? > > diff --git a/hw/pci.c b/hw/pci.c > index 6d08cef..286383a 100644 > --- a/hw/pci.c > +++ b/hw/pci.c > @@ -986,7 +986,7 @@ static void pci_update_mappings(PCIDevice *d) > r->addr = new_addr; > if (r->addr != PCI_BAR_UNMAPPED) { > memory_region_add_subregion_overlap(r->address_space, > - r->addr, r->memory, 1); > + r->addr, r->memory, 2); > } > } > } Who says a BAR has higher priority than a bridge? -- error compiling committee.c: too many arguments to function