From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37266 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSo6I-0002FC-Rt for qemu-devel@nongnu.org; Wed, 15 Dec 2010 04:56:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSo6F-00030L-CJ for qemu-devel@nongnu.org; Wed, 15 Dec 2010 04:56:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSo6F-000302-5W for qemu-devel@nongnu.org; Wed, 15 Dec 2010 04:56:43 -0500 Date: Wed, 15 Dec 2010 11:56:18 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device Message-ID: <20101215095618.GB28825@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> <20101214045715.GG9554@redhat.com> <1292303064.2857.151.camel@x201> <20101214122630.GB19950@redhat.com> <1292351693.2862.9.camel@x201> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1292351693.2862.9.camel@x201> 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 On Tue, Dec 14, 2010 at 11:34:53AM -0700, Alex Williamson wrote: > On Tue, 2010-12-14 at 14:26 +0200, Michael S. Tsirkin wrote: > > On Mon, Dec 13, 2010 at 10:04:24PM -0700, Alex Williamson wrote: > > > > > > I've only ever seen config[PCI_SECONDARY_BUS] be non-zero for an > > > assigned device, so I'm pretty sure we're not going to hurt migration, > > > but the code is clearly wrong and I'd like to make sure we don't trip on > > > a migration failure for a minor device config space change. > > > > Which reminds me: maybe just mark nested bridges as non-migrateable > > for now? Care writing such a patch? > > Hmm, this is trickier than it sounds. Hmm, since 0 is put in the path instead of the bridge number, will the correct bridge be restored? > We're really only broken wrt > migration if a device under a bridge calls qemu_ram_alloc. I guess there's more broken-ness. What exactly breaks qemu_ram_alloc? > Any device > is free to do this, but typically it only happens via > pci_add_option_rom() (not counting vga as typical). So maybe the better > approach for now is to prevent the problem by disallowing option ROMs > for devices below a bridge. We obviously risk devices coming along that > allocate RAM on their own, but we could still allow the most common > issue with almost no lost functionality (assuming no one wants to boot > off that nested device). Thoughts? Thanks, > > Alex