From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCZyD-00043s-UG for qemu-devel@nongnu.org; Mon, 23 Nov 2009 09:32:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCZy9-0003vk-QP for qemu-devel@nongnu.org; Mon, 23 Nov 2009 09:32:49 -0500 Received: from [199.232.76.173] (port=58812 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCZy9-0003vc-Mm for qemu-devel@nongnu.org; Mon, 23 Nov 2009 09:32:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:10884) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCZy9-0001Pb-CQ for qemu-devel@nongnu.org; Mon, 23 Nov 2009 09:32:45 -0500 Date: Mon, 23 Nov 2009 16:32:42 +0200 From: Gleb Natapov Message-ID: <20091123143242.GO2999@redhat.com> References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <20091123082659.GC2999@redhat.com> <20091123123640.GL2999@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Paolo Bonzini , qemu-devel@nongnu.org On Mon, Nov 23, 2009 at 03:09:35PM +0100, Juan Quintela wrote: > Gleb Natapov wrote: > > On Mon, Nov 23, 2009 at 01:25:32PM +0100, Juan Quintela wrote: > >> Gleb Natapov wrote: > >> > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote: > > > Yes, I proposed to send device state in multiple formats specifically to > > prevent negotiation step, but may be proper negotiation is not so > > bad/complex after all. > > Advantages of proper negotation is that target can told you "no". It > does'nt matter the number of formats that you send, if the target don't > understand them, it is not going to work. > The only difference is when it will be known that migration is not possible: before event attempting it or during migration. > >> My problem implementing optional features/sections/... is not the > >> savevm/VMState bits. At the end, implementing that is easy. What is > >> more dificult is once that a device have 5 features, what are the valid > >> combinations. i.e. if you have pci and msix features, msix requires > >> pci. In this case, the dependency is trivial, but in others that > >> hasen't to be so obvious. > > It doesn't matter what device support and how it is configured. This can > > be handled by each device separately. i.e if destination detects that > > source had MSIX enabled for the device but destination hasn't it will > > signal an error. > > And guess what, with current code migration is going to "suceed" on the > source host and fail on the target host. Then current code is buggy. It should be possible to abort migration in the middle if device can't understand the data it received. -- Gleb.