From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38320 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PFUtR-0008Mc-KO for qemu-devel@nongnu.org; Mon, 08 Nov 2010 11:48:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PFUtQ-0004gr-E3 for qemu-devel@nongnu.org; Mon, 08 Nov 2010 11:48:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PFUtQ-0004g8-79 for qemu-devel@nongnu.org; Mon, 08 Nov 2010 11:48:28 -0500 Date: Mon, 8 Nov 2010 18:48:20 +0200 From: "Michael S. Tsirkin" Message-ID: <20101108164819.GD7962@redhat.com> References: <20101004215311.17070.54862.stgit@s20.home> <20101108112227.GA1075@redhat.com> <1289227932.19902.11.camel@x201> <20101108162633.GA7962@redhat.com> <1289234219.19902.22.camel@x201> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1289234219.19902.22.camel@x201> Subject: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: yamahata@valinux.co.jp, qemu-devel@nongnu.org, gleb@redhat.com, armbru@redhat.com On Mon, Nov 08, 2010 at 09:36:59AM -0700, Alex Williamson wrote: > On Mon, 2010-11-08 at 18:26 +0200, Michael S. Tsirkin wrote: > > On Mon, Nov 08, 2010 at 07:52:12AM -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. > > > > I don't really see why do we put the dev path > > > > in the bus object: why not let device supply its name? > > > > > > Because the device name is not unique. This came about from the > > > discussion about how to create a canonical device path that Gleb and > > > Markus are again trying to hash out. If we go up to the bus and get the > > > bus address, we have a VM unique name. Unfortunately, it's difficult to > > > define what the bus should print in all cases (ISA), but since they > > > don't do hotplug and typically don't allocate ramblocks, we can mostly > > > ignore it for this use case. > > > > > > > And I think this will affect nested bridges. However they are currently > > > > broken anyway: we really must convert to topological names as bus number > > > > is guest-assigned - they don't have to be unique, even. > > > > > > Yes, nested bridges are a problem. How can the seg/bus/devfn not be > > > unique? > > > > Bus numbers for nested bridges are guest assigned. We start with 0 after reset. > > Right, invalid bus numbers are not unique. Well, you can call them invalid, but this is the only number there is until guest assigns something :) > > > > What does fixing this involve? Just changing pcibus_get_dev_path? > > > > > > How do you plan to fix it? Don't forget that migration depends on these > > > names, so some kind of compatibility layer would be required. Thanks, > > > > > > Alex > > > > Replace bus number with slot numbers of parent bridges up to the root. > > This works for root bridge in a compatible way because bus number there > > is hard-coded to 0. > > IMO nested bridges are broken anyway, no way to be compatible there. > > > > > > Gleb, Markus, I think the following should be sufficient for PCI. What > > do you think? Also - do we need to update QMP/monitor to teach them to > > work with these paths? > > > > This is on top of Alex's patch, completely untested. > > This function was originally intended to be recursive, so that each bus > could call the parent until we hit a canonical name. It just so happens > that the root bus provides that for non-nested devices. So I think > instead we should have a different function for bridges that appends to > what the root get_dev_path returns. > > Alex This won't be compatible: the format that we have is DDDD:BB:SS.F which means that string concatenation can not get you from bus path to device path (remember that bridge is a PCI device too). And frankly if we can make it non-recursive I'd rather have it that way. We are not solving the tower of hanoi here. -- MST