From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFQ9d-0005gc-E7 for qemu-devel@nongnu.org; Wed, 04 Apr 2012 09:21:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFQ9W-00034O-SS for qemu-devel@nongnu.org; Wed, 04 Apr 2012 09:21:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFQ9W-000344-Jx for qemu-devel@nongnu.org; Wed, 04 Apr 2012 09:21:34 -0400 Message-ID: <4F7C4AD6.6030105@redhat.com> Date: Wed, 04 Apr 2012 15:21:26 +0200 From: Igor Mammedov MIME-Version: 1.0 References: <4F7B610D.8000101@redhat.com> <20120404011843.GA2918@illuin> <4F7BFAEB.7070000@redhat.com> <4F7C282E.6090309@redhat.com> <20120404121418.GB2918@illuin> In-Reply-To: <20120404121418.GB2918@illuin> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call minutes April 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Paolo Bonzini , Dor Laor , qemu-devel@nongnu.org, KVM devel mailing list , Markus Armbruster On 04/04/2012 02:14 PM, Michael Roth wrote: > On Wed, Apr 04, 2012 at 01:53:34PM +0300, Dor Laor wrote: >> On 04/04/2012 01:37 PM, Michael Roth wrote: >>> >>> On Apr 4, 2012 2:42 AM, "Paolo Bonzini">> > wrote: >>>> >>>> Il 04/04/2012 03:18, Michael Roth ha scritto: >>>>> Attacking the IDL/schema side first is the more rationale approach. >>> From >>>>> there we can potentially generate ASN.1 BER/DER visitors for the >>> protocol >>>>> side, or potentially even just vmstate bindings as a start. I've >>> recently >>>>> started looking into the latter... it's completely feasible, the only >>>>> downside is it complicates the IDL due requiring support for a lot of >>>>> what are very much vmstate-specific items, but it should be possible to >>>>> do this in a manner where those annotations are self-contained and >>>>> ignorable if we opted to replace vmstate-style declarations. >>>> >>>> We can also keep the current vmstate descriptions, but access fields >>>> from the automatically-generated visitors instead of struct fields. >>>> This keeps the IDL simple. >>> >>> It may be worthwhile as an incremental step though, one nice thing about >>> automatically generated bindings is that with the QIDL Anthony >>> prototyped a while back we assume we serialize by default, so changes in >>> annotated structs automatically trigger changes in the generated >>> bindings unless you explicitly mark fields as immutable/derivable/etc, >>> which we can tie into the build or make check to automatically detect >>> and bring attention to changes in vmstate. This may be worth the effort >>> if we adopt the proposed 4 year migration support cycle for pc-1.0, >>> since that'll continue to rely on vmstate even after we move on to an >>> IDL and newer protocol. >> >> Beyond ASL/IDL I like to be sure that we're not just translating one >> format to other representation but instead we introduce some new >> functionality like: >> - Ability to negotiate the protocol version >> - Bi-direction data exchange, the sender will send data as a function >> of the target release >> - Include the machine type too > > I've been toying with the notion of having the target start up a QMP > limited server that the source talks to to orchestrate negotiation. We > could potentially even send the device state by taking our QIDL-generated > visitors and serializing state via QmpOutputVisitor. QMP can be made > aware of the format of the device state input by taking the intermediate > step of generating QAPI schemas via QIDL, and using the QAPI code > generators to generate the visitors rather than QIDL directly. This > would also address the protocol side: just use QMP rather than ASN.1.. > > It's not as compact, but device state is such a small amount of data > compared to memory/disk that I don't think it's worth optimizing that > aspect, though we could use compression at the protocol layer if we > were inclined. Anything more suited to an out-of-band protocol, like > memory/disk, could be orchestrated via this interface... source can ask > target for a port to handle such things, negotiate stuff like XBZRLE, > etc. > >> - Synchronize the entire qemu cmdline and don't relay on management to >> set it up. >> - Along the way, deal w/ hotplug events. > > My initial plan for the QIDL-generated visitors is to associate a QOM > property, "state", with each device, and to serialize device state by > walking the QOM composition tree, the main rationale being that if we > extend that serialization to include other QOM properties, I believe we > have everything we need to recreate all the devices on the target: > parent->child relationships, types, properties set via cmdline, > device state... > > A simpler alternative would be to leverage just send the cmdline > options over to the target and assume that it results in the same underlying > machine, then just send off the device state. Much simpler actually...but > the above approach should work regardless of changes to the command-line > options on the source... having an internally stable cmdline scheme > might work as well... Will command line take in account hot-plugged devices? > > I'm not sure what the right approach is here but whatever we decide on I think > being able to automatically generate visitors from annotations is a good > first-step and should tie into any forseeable approaches. > >> >>> >>>> >>>> Paolo >>>> >>> >> > -- ----- Igor