From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHOO6-0007Ra-FX for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:39:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHOO1-0007Qk-QZ for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:39:10 -0400 Received: from [199.232.76.173] (port=46265 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHOO1-0007Qh-Ll for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:39:05 -0400 Received: from mail-qy0-f191.google.com ([209.85.221.191]:63989) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MHOO1-0004oF-BI for qemu-devel@nongnu.org; Thu, 18 Jun 2009 16:39:05 -0400 Received: by qyk29 with SMTP id 29so1699398qyk.4 for ; Thu, 18 Jun 2009 13:39:04 -0700 (PDT) Message-ID: <4A3AA5D8.8050303@codemonkey.ws> Date: Thu, 18 Jun 2009 15:38:48 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] sending pci information over the wire References: <20090618193946.GH3517@poweredge.glommer> <4A3A9D89.5000305@codemonkey.ws> <20090618201227.GI3517@poweredge.glommer> In-Reply-To: <20090618201227.GI3517@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: > Sure. > > Question is, whether or not there is any value in doing this now. > Doing what you proposed would be difficult to support long term. I don't think it qualifies as an interim solution. You would have to pass host configuration information in the migration protocol and that's a fundamental change to the way migration works in QEMU today. If you assume the management application knows about the devices added, then it also knows about what the new arguments should be for QEMU. Maybe we should think about ways to delay the launching of QEMU (or at least the argument parsing) until after migration has completed. Then, we have the ability to transfer the command line arguments (through a separate channel) similar to how ssh migration used to work. We're really close to a machine config for pc though, I'm not sure that that's not a quicker solution. Regards, Anthony Liguori