[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