From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHNsR-0002LO-1M for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:06:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHNsM-0002Bo-5d for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:06:26 -0400 Received: from [199.232.76.173] (port=56440 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHNsM-0002BX-0Z for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:06:22 -0400 Received: from mx2.redhat.com ([66.187.237.31]:41964) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MHNsL-0004pN-7p for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:06:21 -0400 Date: Thu, 18 Jun 2009 17:12:27 -0300 From: Glauber Costa Subject: Re: [Qemu-devel] sending pci information over the wire Message-ID: <20090618201227.GI3517@poweredge.glommer> References: <20090618193946.GH3517@poweredge.glommer> <4A3A9D89.5000305@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A3A9D89.5000305@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: armbru@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On Thu, Jun 18, 2009 at 03:03:21PM -0500, Anthony Liguori wrote: > Glauber Costa wrote: >> Hi folks, >> >> I have some trial code here for a proposal, which I'd like to hear your >> opinions about (Well, I _had_, because I'm totally stupid and git reset'd --hard >> the wrong location, that happened to contain part of the code for it) >> >> Let me start by explaining what I'm trying to accomplish, and say that I myself >> am not sure this is the best approach, it is just a crazy idea that poped up. >> >> Right now, migration of pci devices work by a bit of luck. This is because the >> other side of the wire can enumerate the devices in a different order, causing >> them to end up at different addresses. Markus approach of pci_addr= patches >> do help that fact. >> >> However, theoretically, there can be a case in which we: >> * start receiving guest, with parameters determined by pci_addr= >> * start live migration >> * add a device. >> > > Once we have a machine config (and please, let's avoid the 2017 jokes > please), I imagine that the machine config will be transferred as a > non-live section. > > That will solve this problem quite nicely. Sure. Question is, whether or not there is any value in doing this now. I may argue that this could raise issues early, and the rework needed to make it work can pave the way for a machine config, making things easier for it. Or maybe not.