Re: [Qemu-devel] spicevmv chardev, guest agents and paravirtual mouse

[Anthony Liguori]

On 01/12/2011 10:12 AM, Gerd Hoffmann wrote:
>   Hi folks,
>
> Looks like the spicevmc patch kicked the guest qagent discussion, so 
> lets start with this, although it isn't related much to the agent issue
> itself ...
>
>
> The spicevmc chardev just pipes data from a chardev user within qemu
> to libspice and adds a "type" tag to it so libspice knows now to wind
> up the other end.  There are several types:
>
> (1) vdagent, the spice guest agent.  Will discuss this in detail
>     below.
>
> (2) smartcard, this basically pipes the smartcard protocol over spice.
>     Patches for smartcard support are on the list and should be almost
>     ready for merge now. If you want connect a remote smart card reader
>     to your guest you can use a tcp chardev, which will build a data
>     pipeline like this:
>
>        ccid-passthrough <-> tcp chardev <-> tcp protocol <->
>          vcsclient <-> libcacard
>
>     Or you can use the spicevmc chardev to use spice as transport:
>
>        ccid-passthrough <-> spicevmc chardev <-> spice protocol <->
>        spice client <-> libcacard
>
>     If someone comes up with a vnc extention one could create something
>     simliar for vnc tunneling:
>
>        ccid-passthrough <-> vnctunnel chardev <-> vnc protocol <->
>        gtk-vnc widget <-> libcacard
>
> (3) usb forwarding.  Hans is busy with this.  No working code yet.
>     Will probably work pretty simliar to smartcard.
>
> (4) termial forwarding.  Just an idea right now.  Nowdays that the spice
>     client side moves to gtk it would be easy to embed a termial widget,
>     therby allowing easy access to the serial console using something
>     like this:
>
>        -chardev spicevmc,id=console,type=terminal
>        -device isa-serial,index=0,chardev=console
>
> So even if you put the guest agent discussion completely aside the
> spicevmc chardev clearly has its uses.
>
>
> Ok, now for the spice vdagent.  Alon posted the link to the specs in
> the spice wiki already, here it is again:
>    http://spice-space.org/page/Whiteboard/AgentProtocol
>
> The header file with the protocol specification comes with the
> spice-protocol package, here is a direct link:
>    http://cgit.freedesktop.org/spice/spice-protocol/tree/spic/vd_agent.h
>
> Linux agent code is here:
>    http://cgit.freedesktop.org/~jwrdegoede/vdagent-linux/
>
> The protocol can be multiplexed via VDIChunkHeader->port.  spice
> actually does that as the mouse messages (VDAgentMouseState) are
> generated by the spice server itself.  Everything else is just piped
> from the guest to the spice client (and back).  The protocol also has
> capabilities (VDAgentAnnounceCapabilities).
>
> There isn't much spice-specific stuff in there.  The clipboard bits
> for example should work unmodified with vnc, one would just have to
> hack up a vnc extention to tunnel the agent protocol over vnc (and vnc
> client support of course).

VNC already supports copy/paste as part of the protocol so can the agent 
protocol be terminated in QEMU such that the server can make use of the 
standard protocol extensions?

> I think the only spice-specific bit in the protocol is the display
> enumeration in the VDAgentMonitorsConfig and VDAgentMouseState
> messages.  The numbers there simply reference the spice display
> channel number of the display in question, which just doesn't exist
> outside spice.  Of course one can just ignore that for now as there is
> no multihead support outside spice anyway ...
>
>
> Also related: paravirtual mouse.  I'd suggest to go for something new,
> based on virtio-serial, doing just the mouse and nothing else.

I'd agree.  I think we want something that actually terminates in the 
kernel for Linux guests since then we can expose it as an evdev device.  
No special X driver would be needed.

Is this something that makes sense for Spice in the future?

> The VDAgentMouseState messages have one problem: They send the pointer
> position as-is, which introduces a dependency on the screen size.
> Spice deals with it, and although that is a little bit ugly it isn't a
> big issue either as spice knows how big the screens are.  When using
> this outside spice context this becomes nasty though.
>
> Also I think it is a bad idea to mix guest agent stuff with the
> paravirtual mouse.  The mouse events need to get routed to the
> X-Server, whereas the agent stuff is handled by some other daemon.
> Also the multiplexing the spice server has to do to inject the mouse
> messages supports that view IMHO.
>
> Related note: It is probably a good idea to also separate stuff which
> is handled best by a system-wide guest daemon (such as reboot
> requests, package installs, whatever, vdagent doesn't do that kind of
> management btw) and stuff which needs to be handled by a per-user
> daemon which has access to the user's X-Session (clipboard, ...).

Definitely.  VMware uses two separate daemons--one that runs in a system 
context and one that runs per user X session.

> Ok, how to go forward now?  Here is what I think we should do:
>
> (1) Merge spicevmc chardev.  Needed anyway for compatibility and
>     for the other use cases outlined above.
> (2) Design a paravirtual mouse device.  Make sure it fullfills the
>     spice requirements, which are basically:
>       * support multiple displays.
>       * don't eat tons of cpu like usb-tablet does.
> (3) spice can use the new pvmouse now and depricate sending mouse
>     events via vdagent protocol.
> (4) In parallel review the vdagent protocol, then either extend or
>     redesign it for other use cases.

I'm okay with this as long as there is a commitment from the Spice team 
to convert on a common framework.  I'd like to have a little more 
discussion about agent design first to make sure that we're on the same 
page.

For instance, Spice makes use of a 1-off protocol whereas something like 
virt-agent uses an established RPC protocol (XML-RPC).  I'm not tied to 
using any particular protocol, but I think it's very important to use a 
standardized, well specified protocol.

Regards,

Anthony Liguori

> Let the Flam^WDiscussions begin,
>
>   Gerd