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).
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.
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, ...).
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.
Let the Flam^WDiscussions begin,
Gerd
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
