Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/08/2011 08:00 AM, Avi Kivity wrote:
> On 03/08/2011 03:54 PM, Anthony Liguori wrote:
>>
>>> (and gah, do we really need a vfs/rpc in qemu?)
>>
>> Fun, eh :-)  Unfortunately, our friends at VMware provide a 
>> VixVM_CopyFileFromGuestToHost API so there's an expectation that we 
>> provide a similar interface.
>>
>
> Yes, but do we have to terminate it in qemu?

No, I'm in the process of writing up my latest proposal.

The idea is pretty simple.  QAPI generates code for libqmp that takes 
native arguments for a command and generates a QObject.  It also 
generates code for QEMU that takes a QObject and generates native 
arguments to pass to a function.

For guest commands, we combine the two such that we unmarshal the 
incoming QObject to native arguments, then pass it to another function 
that marshals the arguments to a QObject.  The QObject is then passed to 
the guest-agent which uses the same generated code as QEMU to unmarshal 
the qobject to native arguments and dispatch to a function.

That means the only new code we need for the guest agent is the 
JSON-over-virtio-serial transport.  To implement guest commands, we just 
add the command to the schema, implement the native arguments version in 
guest-agent, and that's it.

QEMU will buffer all input and output to the guest acting as a first 
line of defence from a security PoV.  That means that the guest doesn't 
get to talk directly to the management tools which removes that as a 
direct attack surface.

The nature of QEMU is such that if we do tagging correctly, we can also 
support live migration transparently to the guest too.

Regards,

Anthony Liguori

> Especially as I expect we don't really want to copy a file to the 
> host, but instead stream it to some other channel.
>