From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFEs8-0006G0-T5 for qemu-devel@nongnu.org; Tue, 03 Apr 2012 21:18:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFEs6-0007e0-Tf for qemu-devel@nongnu.org; Tue, 03 Apr 2012 21:18:52 -0400 Received: from mail-iy0-f173.google.com ([209.85.210.173]:51764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFEs6-0007ds-M2 for qemu-devel@nongnu.org; Tue, 03 Apr 2012 21:18:50 -0400 Received: by iafj26 with SMTP id j26so500434iaf.4 for ; Tue, 03 Apr 2012 18:18:48 -0700 (PDT) Sender: fluxion Date: Tue, 3 Apr 2012 20:18:43 -0500 From: Michael Roth Message-ID: <20120404011843.GA2918@illuin> References: <4F7B610D.8000101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F7B610D.8000101@redhat.com> Subject: Re: [Qemu-devel] KVM call minutes April 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dor Laor Cc: Markus Armbruster , KVM devel mailing list , qemu-devel@nongnu.org On Tue, Apr 03, 2012 at 11:43:57PM +0300, Dor Laor wrote: > On 04/03/2012 05:43 PM, Markus Armbruster wrote: > >I'm afraid my notes are rather rough... > > > >* 1.1 > > soft freeze apr 15th (less than two weeks) > > hard freeze may 1 > > three months cycle for 1.2 > > stable machine types only every few releases? "pc-next" > > > >* Maintainers, got distracted and my notes make no sense, sorry > > > >* MSI injection to KVM irqchips from userspace devices models > > > >* qemu-kvm tree: working towards upstream merge > > > > not much left, mostly device assignment > > > >* Migration: vmstate and visitors, decoupling the wire format > > why not ASN.1 > > Curiosity kills me of waiting for next week's meeting to get the answer I believe when this had come up in the past the plan was to use ASN.1 for the wire protocol, but not to address the decoupling problem. Theoretically it could handle both, but I believe that requires defining device structures using ASN.1 definitions, which probably isn't suitable for devices since it results in high level structures which require special accessors (at least for the libraries I've looked at) An IDL compiler that generates visitors based on a simple device code annotations still seems to be the leading option. Previously I'd jumped the gun a bit by piggy-backing off vmstate to get at the protocol side, but that permanently baked QEMUFile markers into the wire protocol which was the wrong approach. 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. > > > > >* qtest: test cases wanted > > > >