Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent

[Gerd Hoffmann <kraxel@redhat.com>]

On 01/17/11 15:53, Michael Roth wrote:
> On 01/17/2011 07:53 AM, Gerd Hoffmann wrote:
>> What is your plan to handle system-level queries+actions (such as
>> reboot) vs. per-user stuff (such as cut+paste)?
>
> This is an area that hasn't been well-defined yet and is definitely open
> for suggestions.

One option would be to have two virtio-serial channels, one for the 
system and one for the user stuff.  gdm could grant the desktop user 
access to the user channel like it does with sound devices and simliar 
stuff, so the user agent has access to it.

Another option is to have some socket where the user agent can talk to 
the system agent and have it relay the requests.

Maybe it is also possible to use dbus for communication between the 
system agent and user agent (and maybe other components).  Maybe it even 
makes sense to run the dbus protocol over the virtio-serial line? 
Disclaimer: I know next to nothing about dbus details.

> For host->guest RPCs the current plan is to always have the RPC executed
> at the system level, but for situations involving a specific user we
> fork and drop privileges with the RPC, and report back the status of the
> fork/exec. The fork'd process would then do what it needs to do, then if
> needed, communicate status back to the system-level daemon via some IPC
> mechanism (most likely a socket we listen to in addition to the serial
> channel) that can be used to send an event. The system-level daemon then
> communicates these events back to the host with a guest->host RPC.

Hmm.  A bit heavy to fork+exec on every rpc.  might be ok for rare 
events though.

> Processes created independently of the system-level daemon could report
> events in the same manner, via this socket. I think this might suit the
> vdagent client model for Spice as well,

Yes, vdagent works this way, except that *all* communication goes 
through that socket, i.e. events/requests coming from the host for the 
user-level agent are routed through that socket too.

It is the only sane way to handle clipboard support IMHO as there is 
quite some message ping-pong involved to get a clipboard transaction done.

How does xmlrpm transmit binary blobs btw?

cheers,
   Gerd