From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCbQ9-0000Ai-Jr for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:05:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCbQ5-00009p-4y for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:05:45 -0500 Received: from [199.232.76.173] (port=52514 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCbQ5-00009m-1e for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:05:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28779) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCbQ4-0002Wk-2b for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:05:40 -0500 Date: Mon, 23 Nov 2009 18:05:34 +0200 From: Gleb Natapov Message-ID: <20091123160534.GW2999@redhat.com> References: <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <20091123082659.GC2999@redhat.com> <20091123123640.GL2999@redhat.com> <20091123143242.GO2999@redhat.com> <4B0AA165.60900@codemonkey.ws> 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 05:01:58PM +0100, Juan Quintela wrote: > Anthony Liguori wrote: > > Gleb Natapov wrote: > >>>>> 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. > >> > > > > It can, post_load() can error which will terminate the migration. > > This can be used to validate fields beyond whether they fit into the > > type specified. > > Yes, but "source" never sees that. > it is like: > > source: > set things > foreach device > sent state > end > > target: > set things > while data > receive device > > If it fails in one of the lastest devices. Source decrees migration > "success" before target ends reading data. You can test it, put a > return -1 in any of the post_load() functions, and you would see that > migration suceeds in the source and fails in the target. > > Mark was the one that explained me this bug. > According to Anthony this is not a bug. Management has all the means to resolve this situation properly. The bug would be if dst and src both run or both exit. -- Gleb.