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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux