From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCY9z-00075R-2F for qemu-devel@nongnu.org; Mon, 23 Nov 2009 07:36:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCY9t-00072z-F3 for qemu-devel@nongnu.org; Mon, 23 Nov 2009 07:36:49 -0500 Received: from [199.232.76.173] (port=54010 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCY9t-00072q-8w for qemu-devel@nongnu.org; Mon, 23 Nov 2009 07:36:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28552) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCY9s-0008Ml-NP for qemu-devel@nongnu.org; Mon, 23 Nov 2009 07:36:45 -0500 Date: Mon, 23 Nov 2009 14:36:40 +0200 From: Gleb Natapov Message-ID: <20091123123640.GL2999@redhat.com> References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <20091123082659.GC2999@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 01:25:32PM +0100, Juan Quintela wrote: > Gleb Natapov wrote: > > On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote: > >> Paolo Bonzini wrote: > >> > > >> >>I don't see how this fixes anything. If you used feature bits, how do > >> >>you migrate from a version that has a feature bit that an older version > >> >>doesn't know about? Do you just ignore it? > >> > > >> >I'd go with chunk instead of feature bits, specifying them like in > >> >the PNG specification: > >> > >> You mean, each device would have multiple sections? We already use > >> chunks for each device state. > >> > > Each device can send device info in multiple formats (each format with > > its own ID) and destination will choose the one it supports. > > RAM anyone? You send 1GB of info in different formats, just in case :) > RAM is migrated very differently from devices. No need to extend this for RAM. > In this case, I think that the only two realistic solutions are to > increase negotiation during migration: > > - source -> target: I can save this devices with this versions: > "cpu" 10 - 12 > "apic" 3 > "ide" 2-4 > "virtio-net" 5-10 > .... > - target -> source: > * I don't support "virtio-net" at all -> failed migration > * send it as: > "cpu" 11 > "apic" 3 > "ide" 2 > "virtio-net" 10 > thankyou very much :) > > The other (more simple solution) is: > > - source -> target: > my machine types are: pc-0.10, pc-0.11 > my devices are: "cpu", "apic", "ide", "virtio-net" > - target-> source > * I dont' have "virtio-net" -> fail, or > * send it as pc-0.10, please > 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. > 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. > > Having subversions for downstream is a different problem that needs to > be fixed. > > Later, Juan. -- Gleb.