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

[Anthony Liguori]

On 01/12/2011 12:59 PM, Hans de Goede wrote:
> Hi,
>
> On 01/12/2011 06:40 PM, Anthony Liguori wrote:
> > 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?
>
> That depends on if the VNC copy/paste support was done right.

Nothing is done right in VNC.  But it should be possible to expose it 
through VNC nonetheless without impacting the protocol.  Let me explain.

> With right
> I mean that it should consist of the following messages:
> 1) A clipboard grab (send by guest -> client if ctrl+c pressed inside
>    the guest, other direction if ctrl-c is pressed in any app on the
>    client machine.) This should include a list of supported types the
>    app now owning the clipboard can offer the clipboard in. For example
>    text/plain-utf-8, text/html

In the case of VNC, the QEMU VNC server would advertise text/plain.

> 2) A clipboard release send when the clipboard owning app exits
> 3) A clipboard request, send by one side when it wants to get the
>    clipboard data, prereq: the other side owns the clipboard, the
>    request is for a type in the list of types advertised when grabbing
> 4) clipboard data, response to clipboard request, could also be a nack
>    when a release / request message cross each other.

So in the case of VNC, there is a copy and paste message which 
effectively maps to (3) and (4) combined into a single server or client 
message.  There is no ability to fail but that just means that the VNC 
implementation either ignores failure or always succeeds.

> > > 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.
>
>
> A paravirt mouse would need some sort of guest os support, yes. But
> not necessarily in the kernel. currently spice-vdagentd uses uinput
> to create an evdev device and send events from userspace. And the spice
> agent under windows does the same (although there the events are
> generated by the per user session agent process).
>
> I'm not saying this should not be in the kernel, just that it does
> not have to be in the kernel. It might even make sense to try and
> use such a ipc mechanism for this, that in one guest os it could be
> a kernel driver and in the other a userspace solution, but I'm not
> sure how feasible that it.

I'm not at all tied to it being in the kernel.  It's slightly nice not 
to require special support in userspace but I don't consider it a deal 
breaker.


> > > The VDAgentMouseState messages have one problem: They send the pointer
> > > position as-is, which introduces a dependency on the screen size.
>
> Yeah, if we could get rid of that, that would be great. We could even
> introduce a new mouse message type to the existing spice vdagent protocol
> and use capabilities to switch between the 2.

I think the typical trick is to scale the coordinates to some large 
resolution.  Would there be any issue doing this in vdagent today?

> > 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.
>
> I'm not sure what something like XML-RPC buys us here, other then
> dragging in a lot of extra dependencies. I'm not saying that I'm against
> using xmlrpc but I'm not sold on it either.
>
> Note while on the subject of design, I think that having some sort of
> capabilities negotiation so that we can provide compatibility between
> different versions is important.


Yes, xmlrpc provides a standard method of introspection that can be used 
for this.  I'm not really advocating XML-RPC, I just want a structured 
well specified RPC protocol.

Regards,

Anthony Liguori

> Regards,
>
> Hans