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 > > > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
