From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43924 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PSZiE-00068U-Ge for qemu-devel@nongnu.org; Tue, 14 Dec 2010 13:34:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PSZiD-0000qi-DB for qemu-devel@nongnu.org; Tue, 14 Dec 2010 13:34:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:65209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PSZiD-0000qd-5h for qemu-devel@nongnu.org; Tue, 14 Dec 2010 13:34:57 -0500 Subject: Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device From: Alex Williamson In-Reply-To: <20101214122630.GB19950@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> Content-Type: text/plain; charset="UTF-8" Date: Tue, 14 Dec 2010 11:34:53 -0700 Message-ID: <1292351693.2862.9.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 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. We're really only broken wrt migration if a device under a bridge calls 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