From patchwork Tue Dec 14 04:57:15 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 75467 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 02A3F1007D1 for ; Tue, 14 Dec 2010 15:58:17 +1100 (EST) Received: from localhost ([127.0.0.1]:51282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSMxq-0007LG-JK for incoming@patchwork.ozlabs.org; Mon, 13 Dec 2010 23:58:14 -0500 Received: from [140.186.70.92] (port=55352 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSMxK-0007Ec-3m for qemu-devel@nongnu.org; Mon, 13 Dec 2010 23:57:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSMxI-00027T-Pd for qemu-devel@nongnu.org; Mon, 13 Dec 2010 23:57:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSMxI-00027F-HG for qemu-devel@nongnu.org; Mon, 13 Dec 2010 23:57:40 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBE4vcqW009422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Dec 2010 23:57:38 -0500 Received: from redhat.com (vpn2-9-140.ams2.redhat.com [10.36.9.140]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id oBE4vax0001462; Mon, 13 Dec 2010 23:57:36 -0500 Date: Tue, 14 Dec 2010 06:57:15 +0200 From: "Michael S. Tsirkin" To: Alex Williamson Subject: Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device Message-ID: <20101214045715.GG9554@redhat.com> References: <20101004215311.17070.54862.stgit@s20.home> <20101108112227.GA1075@redhat.com> <1292270663.2857.129.camel@x201> <20101214044658.GF9554@redhat.com> <1292302161.2857.144.camel@x201> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1292302161.2857.144.camel@x201> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Cc: yamahata@valinux.co.jp, qemu-devel@nongnu.org X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Mon, Dec 13, 2010 at 09:49:21PM -0700, Alex Williamson wrote: > On Tue, 2010-12-14 at 06:46 +0200, Michael S. Tsirkin wrote: > > On Mon, Dec 13, 2010 at 01:04:23PM -0700, Alex Williamson wrote: > > > On Mon, 2010-11-08 at 13:22 +0200, Michael S. Tsirkin wrote: > > > > On Mon, Oct 04, 2010 at 03:53:11PM -0600, Alex Williamson wrote: > > > > > pcibus_dev_print() was erroneously retrieving the device bus > > > > > number from the secondary bus number offset of the device > > > > > instead of the bridge above the device. This ends of landing > > > > > in the 2nd byte of the 3rd BAR for devices, which thankfully > > > > > is usually zero. pcibus_get_dev_path() copied this code, > > > > > inheriting the same bug. pcibus_get_dev_path() is used for > > > > > ramblock naming, so changing it can effect migration. However, > > > > > I've only seen this byte be non-zero for an assigned device, > > > > > which can't migrate anyway, so hopefully we won't run into > > > > > any issues. > > > > > > > > > > Signed-off-by: Alex Williamson > > > > > > > > Good catch. Applied. > > > > > > Um... submitted vs applied: > > > > > > PCI: Bus number from the bridge, not the device > > > > > > @@ -6,20 +8,28 @@ > > > number from the secondary bus number offset of the device > > > instead of the bridge above the device. This ends of landing > > > in the 2nd byte of the 3rd BAR for devices, which thankfully > > > - is usually zero. pcibus_get_dev_path() copied this code, > > > + is usually zero. > > > + > > > + Note: pcibus_get_dev_path() copied this code, > > > inheriting the same bug. pcibus_get_dev_path() is used for > > > ramblock naming, so changing it can effect migration. However, > > > I've only seen this byte be non-zero for an assigned device, > > > which can't migrate anyway, so hopefully we won't run into > > > any issues. > > > > > > + This patch does not touch pcibus_get_dev_path, as > > > + bus number is guest assigned for nested buses, > > > + so using it for migration is broken anyway. > > > + Fix it properly later. > > > + > > > Signed-off-by: Alex Williamson > > > + Signed-off-by: Michael S. Tsirkin > > > > > > diff --git a/hw/pci.c b/hw/pci.c > > > -index 6d0934d..15416dd 100644 > > > +index 962886e..8f6fcf8 100644 > > > --- a/hw/pci.c > > > +++ b/hw/pci.c > > > -@@ -1940,8 +1940,7 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent) > > > +@@ -1806,8 +1806,7 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent) > > > > > > monitor_printf(mon, "%*sclass %s, addr %02x:%02x.%x, " > > > "pci id %04x:%04x (sub %04x:%04x)\n", > > > @@ -29,14 +39,3 @@ > > > PCI_SLOT(d->devfn), PCI_FUNC(d->devfn), > > > pci_get_word(d->config + PCI_VENDOR_ID), > > > pci_get_word(d->config + PCI_DEVICE_ID), > > > -@@ -1965,7 +1964,7 @@ static char *pcibus_get_dev_path(DeviceState *dev) > > > - char path[16]; > > > - > > > - snprintf(path, sizeof(path), "%04x:%02x:%02x.%x", > > > -- pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS], > > > -+ pci_find_domain(d->bus), pci_bus_num(d->bus), > > > - PCI_SLOT(d->devfn), PCI_FUNC(d->devfn)); > > > - > > > - return strdup(path); > > > - > > > - > > > > > > So the chunk that fixed the part that I was actually interested in got > > > dropped even though the existing code is clearly wrong. Yes, we still > > > have issues with nested bridges (not that we have many of those), but > > > until the "Fix it properly later" part comes along, can we please > > > include the obvious bug fix? Thanks, > > > > > > Alex > > > > We can stick 0 in there - would that help? I would much rather not > > create a version where we put the bus number there. > > Yep, 0 is good enough until we solve the nested bridge problem. Thanks, > > Alex I'm surprised you see that it matters in practice, but ok. Like this? Acked-by: Alex Williamson diff --git a/hw/pci.c b/hw/pci.c index 254647b..81231c5 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -1952,7 +1952,10 @@ static char *pcibus_get_dev_path(DeviceState *dev) char path[16]; snprintf(path, sizeof(path), "%04x:%02x:%02x.%x", - pci_find_domain(d->bus), d->config[PCI_SECONDARY_BUS], + pci_find_domain(d->bus), + 0 /* TODO: need a persistent path for nested buses. + * Note: pci_bus_num(d->bus) is not right as it's guest + * assigned. */, PCI_SLOT(d->devfn), PCI_FUNC(d->devfn)); return strdup(path);