From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47610 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSMpX-0003LY-4T for qemu-devel@nongnu.org; Mon, 13 Dec 2010 23:49:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSMpJ-0007wr-9e for qemu-devel@nongnu.org; Mon, 13 Dec 2010 23:49:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSMpI-0007wa-Rc for qemu-devel@nongnu.org; Mon, 13 Dec 2010 23:49:25 -0500 Subject: Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device From: Alex Williamson In-Reply-To: <20101214044658.GF9554@redhat.com> References: <20101004215311.17070.54862.stgit@s20.home> <20101108112227.GA1075@redhat.com> <1292270663.2857.129.camel@x201> <20101214044658.GF9554@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 13 Dec 2010 21:49:21 -0700 Message-ID: <1292302161.2857.144.camel@x201> 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: yamahata@valinux.co.jp, qemu-devel@nongnu.org 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