From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBT1o-0006WU-9e for qemu-devel@nongnu.org; Wed, 05 Oct 2011 11:05:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBT1n-0004gD-9y for qemu-devel@nongnu.org; Wed, 05 Oct 2011 11:05:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBT1n-0004fz-1b for qemu-devel@nongnu.org; Wed, 05 Oct 2011 11:04:59 -0400 Date: Wed, 5 Oct 2011 17:06:01 -0200 From: "Michael S. Tsirkin" Message-ID: <20111005190601.GC15444@redhat.com> References: <1316443309-23843-1-git-send-email-mdroth@linux.vnet.ibm.com> <20111003064653.GA15380@redhat.com> <4E89AFB4.8000103@us.ibm.com> <20111003132445.GB18920@redhat.com> <4E89BC1A.30208@codemonkey.ws> <4E8BBB4E.5000907@linux.vnet.ibm.com> <4E8C537D.2090007@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E8C537D.2090007@us.ibm.com> Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, Michael Roth , Stefan Berger On Wed, Oct 05, 2011 at 07:54:21AM -0500, Anthony Liguori wrote: > On 10/04/2011 09:05 PM, Stefan Berger wrote: > >On 10/03/2011 09:43 AM, Anthony Liguori wrote: > >>On 10/03/2011 08:24 AM, Michael S. Tsirkin wrote: > >>>On Mon, Oct 03, 2011 at 07:51:00AM -0500, Anthony Liguori wrote: > >>>>>Here are some suggestions: > >>>>> > >>>>>- Let's make the protocol be BER directly. > >>>>>As a first step, use a single octet string for > >>>>>the whole of data. Next, start splitting this up. > >>>> > >>>>This can't be done without breaking the old style migration > >>>>protocol. I don't have a problem with that but I do have a problem > >>>>with repeatedly breaking migration protocol. > >>> > >>>As long as this is within a release cycle, is this a real problem? > >> > >>I think if we try to fit it within a release we'll either end up with a 2 year > >>long release or a half-broken conversion. > >> > >>I'd rather buy ourselves time by supporting both formats. That way we can > >>remove the old format when we're satisfied with the ASN.1 encoding. > >Hm, if backwards compatibility is what we want to achieve (migrating from Qemu > >1.1 to Qemu 1.0) then at least the ASN.1 decoder / encoder should be all done in > >1.0, no? Otherwise what would it mean to if 1.0 just skipped types 1.1 sends and > >doesn't understand? > > Before we introduce ASN1, we ought to introduce migration > capabilities. FWIW we introduce it for tpm as first step. > Migration capabilities would be used to negotation > ASN.1 over the wire. I'm not yet really convinced we need capabilities at all. Would be sad to make asn depend on that. > That means that 1.1 would use the existing > protocol to talk to 1.0. We basically never had qemu that can talk across versions 100%. The compability we carry around is so much dead code. And no wonder: there's no way to parse the protocol without being bug for bug compatible. IMO let's just switch to a sane protocol first. Being compatible with that will be much easier. > >>There are multiple things to consider with compatibility: > >> > >>1) Creating compatible device models. This is a qdev problem and can't be > >>solved in the protocol. > >> > >>2) Ensuring we are sending all the data we need to. I think we solve this > >>problem by autogenerating Visitors from the C definitions of the device > >>structures. > >> > >I would have thought that we would write a function that takes the > >VMStateDescription as an argument and write ASN.1 BER or CER comprising: > >- a header containing the version of the device data > >- the minimum version required to read the device data > >- walk the array of VMStateFields and encode the the device data > > Sort of. You modify VMStateInfo to accept a visitor and name > parameter in load and put. Then you write an ASN.1 BER Visitor and > pass that visitor to VMStateInfo->load/put. > > Regards, > > Anthony Liguori > > > > >and similarly a function for walking the fields for decoding of each device state. > > > >So at least I am surprised to hear 'autogeneration' for this particular case... > > > >Stefan