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

[Anthony Liguori]

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:
>
>        http://wiki.qemu.org/Features/QAPI

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
>    objects
> - 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);

And:

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:
>
>    http://wiki.qemu.org/Features/QCFG
>
> Merging big changes
> - in the past, evolving in tree has not worked well, leaving partial
>    conversions
> - 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

Regards,

Anthony Liguori