[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] KVM call minutes for Mar 15
Date: Tue, 15 Mar 2011 11:28:27 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/15/2011 09:53 AM, Chris Wright wrote:
QAPI -- http://wiki.qemu.org/Features/QAPI
- please review!
- Anthony would like to see feedback and plans to commit in a week
   (assuming agreement and no major issues in review)
- some concern about the maintainability of code generation
   - but still nothing concrete on the list, need to review and discuss
     on the list
- some concern that implementation details may change the wire protocol
   - introduces a new mechanism for new signals (mask by default and
     enabled explicitly)
   - disagreement over when/how to introduce new extensions

I'm going to try to figure out a better way to do this. For the short term, we don't have an immediate need for the new signaling mechanism but I think I've been adequately convinced that we need something better for 0.15.

- libvirt feedback?
   - no protocol level changes
     - old and new versions are testable with test suite and proves this
- c library implementation is critical to have unit tests and test
   driven development
   - thread safe?
     - no shared state, no statics.
     - threading model requires lock for the qmp session
   - licensiing?
     - LGPL
   - forwards/backwards compat?
     - designed with that in mind see wiki:


One neat feature of libqmp is that once libvirt has a better QMP passthrough interface, we can create a QmpSession that uses libvirt. It would look something like:

QmpSession *libqmp_session_new_libvirt(virDomainPtr dom);

The QmpSession returned by this call can then be used with all of the libqmp interfaces. This means we can still exercise our test suite with a guest launched through libvirt. It also should make the libvirt pass through interface a bit easier to consume by third parties.

QCFG -- http://wiki.qemu.org/Features/QCFG
- command line args translation to objects is complex and buggy
- schema + code generator to formalize this
- formally describe each command line option and generate code
   to build and validate objects
- provides systematic way to document command line options
- automatically
- device_add does multiple conversions to go from qmp to qemuopts to
- move to basic c structures, and autogenerated marshalling code
- no plan to do this work soon, late in 0.15 cycle
   - same as qapi, fork a tree, do mass conversion and merge for 0.16 cycle
- qmp server mode to take all configuation commands before actually
   starting the guest
- can provide a config file
- qdev...
   - could just bridge to setting and getting qdev properties
   - OR get to point where device objects go directly to qdev device init

So we'd do something like:

{ 'device': 'ISASerial', 'properties': { 'iobase': 'int', 'irq': 'int', 'chardev': 'CharDriverState' } }

And we can document all of the parameters in the same fashion as everything else. We can extract that documentation to provide QMP-level documentation, CLI-level documentation, and even online documentation for qdev.

The only question in my mind is what the C interface ought to be. It could be:

DeviceState * qdev_create_isa_serial(ISASerialProperties *props, Error **errp);


DeviceState * libqmp_qdev_create_isa_serial(ISASerialProperties *props, Error **errp);

Or we could expand it:

DeviceState * qdev_create_isa_serial(int64_t iobase, int64_t irq, CharDriverState * chardev, Error **errp);

And this is much nicer to use internally.

But, this is bad for libqmp because adding parameters breaks the C API. The libqmp API really wants to use a structure.

It's not clear to me whether we should have differing internal APIs vs. libqmp, or whether we should just use structures in QEMU.

Haven't put too much thought into it but that's pretty much a brain dump of where I am right now.

- why not move command line to qmp instead of new schema?
   - single schema
- considerations for -M (didn't capture all of these)
- for all the details:


Merging big changes
- in the past, evolving in tree has not worked well, leaving partial
- QAPI/QCFG method of doing changes in external tree hopes to set new precedent
- put together a detailed specification and make it available for review very early in the process.

I think this is a critical step too.

   - preserve patch/review on list
   - do full conversion
   - provide strong testing to show it works

Kemari merge plans
- just needs some ACKs
- Juan, Anthony, anybody else who is familiar with migration to review?

switch from gpxe to ipxe
- possible 0.15 release w/ ipxe (Alex looking into it)
- Michael Brown been helpful in fixing bugs, so compat
- Alex will send out mail soon on the details
- ipxe releases?  not yet, there are plans for it, should be coming RSN
- Stefan volunteers to help test


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]