[Qemu-devel] Re: [RFC][PATCH v1 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)

[Michael Roth]

On 03/25/2011 02:47 PM, Michael Roth wrote:
> These apply on top of Anthony's glib tree, commit 
> 03d5927deb5e6baebaade1b4c8ff2428a85e125c currently, and can also be obtained 
> from:
> git://repo.or.cz/qemu/mdroth.git qga_v1
>
> The QGA-specific patches are in pretty rough shape, and there are some 
> outstanding issues that I'll note below. I just wanted to put the general 
> approach out there for consideration. Patch-level comments/review are still 
> much-appreciated though.
>
> However, patches 1-5 are general json/QAPI-related fixes. Anthony, please 
> consider pulling these into your glib tree. The json fix-ups may need further 
> evaluation, but I'm confident they're at least an improvement. The QAPI ones 
> are trivial fix-ups.
>
> ISSUES/TODOS:
>
>   - QMP's async callbacks expect the command results to be de-marshalled beforehand. This 
> is completely infeasible to attempt outside of the code generator, so this is a big area 
> that needs to be addressed. So for now, only the 'guest-ping' command works, since it has 
> no return value. The dummy "guest-view-file" command will cause an error to be 
> reported to the client.

Well, not completely de-marshalled. Basically just need a way to pull 
whatever is stored in the response qdict's "return" field out without 
specifying the QTYPE in advance... which exists in 
qdict.c:qdict_get_obj(), it's just not currently exposed to outside 
callers. Alternatively, the callback function can take in the entire 
response's qdict and pull the value out using knowledge from the schema. 
Will look into this more, but not nearly involved as I first thought.

>   - qemu-ga guest daemon is currently not working over virtio-serial or isa-serial. This is probably 
> an issue with how I'm using glib's io channel interfaces, still investigating. This means the only 
> way to currently test is by invocing qemu-ga with "-c unix-listen -p<sockpath>", then 
> doing something like `socat /dev/ttyS0,raw,echo=0 unix-connect:<sockpath>`.
>   - guest-view-file is a stub, and will be broken out into an open/read/close 
> set of RPCs, possibly with a high-level interface built around those.