From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qncr2-0004le-2o for qemu-devel@nongnu.org; Sun, 31 Jul 2011 16:43:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qncr0-0001uo-Sn for qemu-devel@nongnu.org; Sun, 31 Jul 2011 16:43:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qncr0-0001uf-Hp for qemu-devel@nongnu.org; Sun, 31 Jul 2011 16:43:18 -0400 Message-ID: <4E35BE5C.9040607@redhat.com> Date: Sun, 31 Jul 2011 23:43:08 +0300 From: Dor Laor MIME-Version: 1.0 References: <4E2DFAE5.1050304@codemonkey.ws> <4E2EB522.2000808@codemonkey.ws> <4E32BD96.9030806@redhat.com> <4E32C385.5020702@codemonkey.ws> <4E32CF52.9080203@redhat.com> <4E33340D.5050003@codemonkey.ws> <4E353314.8070403@redhat.com> <4E354043.6050203@redhat.com> <20110731184625.GA14622@lst.de> In-Reply-To: <20110731184625.GA14622@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , quintela@redhat.com, Ryan Harper , mst@redhat.com, qemu-devel@nongnu.org, Paolo Bonzini On 07/31/2011 09:46 PM, Christoph Hellwig wrote: > On Sun, Jul 31, 2011 at 02:45:07PM +0300, Dor Laor wrote: >>> No, definitely not. I think most people using non-x86 architectures >>> don't use the vmsave/vmload/migration features at all, but would >>> be annoyed if the perfectly functional device models they were >>> using got deleted... >> >> I didn't mean to erase the entire device, just the code for save/load which >> as you say, might not be used at all. > > Like the one in virtio? /me caught off guard. I wonder why it wasn't converted to VMSTATE before? virtio is one of the key devices, it's not just random forgotten one that might not care about migration. It's worth to utilize this discussion to realize whether vmstate is significant enough. From my brief browsing it looks like vmstate helps to reduce some plain errors with double save/load coding, ease the field encoding and handles subsections (which imho is the most important). It's true that we need to introduce capabilities to the live migration protocol and some other goodies but we might be able to do that with the existing method of gradual enhancement for VMSTATE to whatever form it may be.