From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38619 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pd4in-00048g-Bt for qemu-devel@nongnu.org; Wed, 12 Jan 2011 12:43:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pd4hx-0003NH-Sk for qemu-devel@nongnu.org; Wed, 12 Jan 2011 12:42:07 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:64713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pd4hx-0003N2-Ks for qemu-devel@nongnu.org; Wed, 12 Jan 2011 12:42:05 -0500 Received: by qyl38 with SMTP id 38so1764981qyl.4 for ; Wed, 12 Jan 2011 09:42:04 -0800 (PST) Message-ID: <4D2DE7AA.3010202@codemonkey.ws> Date: Wed, 12 Jan 2011 11:40:58 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] spicevmv chardev, guest agents and paravirtual mouse References: <4D2DD2F1.6030801@redhat.com> In-Reply-To: <4D2DD2F1.6030801@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: spice-devel , "qemu-devel@nongnu.org" 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 >