Re: [Qemu-devel] KVM call minutes for Feb 15

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/15/2011 10:26 AM, Chris Wright wrote:
> QAPI and QMP
> - Anthony adding a new wiki page to describe all of this
>    

http://wiki.qemu.org/Features/QAPI

> - specified in formal schema using JSON
>    - includes documenation in javadoc-like syntax
>    - can generate api (possibly protocol) docs
>    - documenting each command and expected errors
> - creates marshalling functions and C interfaces
> - can generate C library
>    - facilitates unit tests/regression tests
> - new and old code both exist in Anthony's tree
>    - allows unit tests to run on both to verify
>    - will remove old and force a flag day on merging in for 0.15
> - still need to convert human monitor commands
>    - goal to convert all of human monitor to QMP
> - events?
>    - still not consumable from internal use
>    - model signals and slots
>      - similar to notifier lists, but can pass arbitrary data
>      - client connects to signal via QMP
>    - how to extend?
>      - optional parameters (ABI bump)
>        - no way to know if client is aware of and consuming the optional
> 	parameters
>      - add new events
>        - client required to register for new events when the know about
> 	them, server can generate different logic based on clients
> 	capability
> - first release may not include shared library (lack of libconf/autotool)
>    - could
>    

Just to be clear, this is just not in my current priority list.  I'm 
much more focused on having full unit tests, documentation, and all HMP 
commands converted.  If there's time, I will try to do this.

> - QMP session in default well-known location
>    - allows iteration of all running QMP sessions
>    - per-user directory to handle user-level isolation
>
> qdev future
> - have an object model, but can't do polymorphism (i.e. bus level)
> - could use more oop style, use GObject, use C++...no great ideas
> - no major qdev plans for 0.15
>    

For me, if anyone wants to tackle this, I'd love to have a discussion.

> - would be useful to have the ability to do device level unit testing
>    - cleaner device model, better encapsulation
>    - this is both the device side interfaces, but also interfaces back to qemu
>    - ability to do something like a virtual PCI bus to be a test harness
>      to interact with a device
>    - back to the GObject, oop, C++ questions?
>      - IDL based code generation to generate VMState in effort to make
>        migration more verifiable
>      - VMState
>        - need to focus on serialized guest visible state
>          - start with all state and remove obviously internal only state
> 	- start with only guest visible state (structure separation)
>        - verfiable
> - need a qdev tree maintainer?
> - some disagreement on exactly how much
> - qdev autodoc patches? (posted and ack'd multiple times)
>
> bad patches committed that are not on list
> - please inform of specifics incidents, this should not be happening
>
> SeaBIOS update?
> - w/out we will have features that can't be used
> - need a release..
>    - 0.15 will need good planning and dates and communication with Kevin
>
> 0.14-rc2 tagged please review for any missing patches, 0.14.0 likely
> tagged late today
>
> revisit new ->  old migration
> - Amit offers virtio-serial patches and some legwork
>    

So, to me, migration correctness trumps compatibility.  I don't think 
compatibility is useful if it means that a guest may fail during 
migration.  We have subsections as a way to support the cases where it's 
safe to migrate to an old version only if a feature is not being used or 
a corner case is not currently happening.  This is the best way to 
approach the problem.

If a subsection won't work, that means you want to migrate when you're 
completely sure that migrating will break a guest.  That doesn't seem 
reasonable at all to me.

I think in the last discussion on Amit's patches, I had suggested that 
subsections could be used to allow migration when there wasn't any 
queued data.  I think this is the best we can do while preserving 
correctness.

Regards,

Anthony Liguori

> - tabled discussion to list, possibly next week's call
>
>