From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHNpb-0005ki-Qp for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:03:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHNpW-0005c0-Vj for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:03:31 -0400 Received: from [199.232.76.173] (port=48431 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHNpW-0005bu-Sr for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:03:26 -0400 Received: from mx20.gnu.org ([199.232.41.8]:51017) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MHNpW-0003hC-9x for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:03:26 -0400 Received: from mail-qy0-f191.google.com ([209.85.221.191]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MHNpV-0006EL-LG for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:03:25 -0400 Received: by qyk29 with SMTP id 29so1671815qyk.4 for ; Thu, 18 Jun 2009 13:03:24 -0700 (PDT) Message-ID: <4A3A9D89.5000305@codemonkey.ws> Date: Thu, 18 Jun 2009 15:03:21 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] sending pci information over the wire References: <20090618193946.GH3517@poweredge.glommer> In-Reply-To: <20090618193946.GH3517@poweredge.glommer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: armbru@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com 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. Regards, Anthony Liguori