From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56300 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pd6U3-0006iv-Kr for qemu-devel@nongnu.org; Wed, 12 Jan 2011 14:35:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pd6U1-0004GV-UZ for qemu-devel@nongnu.org; Wed, 12 Jan 2011 14:35:51 -0500 Received: from mail-qw0-f45.google.com ([209.85.216.45]:35544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pd6U1-0004GQ-Pc for qemu-devel@nongnu.org; Wed, 12 Jan 2011 14:35:49 -0500 Received: by qwk4 with SMTP id 4so974327qwk.4 for ; Wed, 12 Jan 2011 11:35:48 -0800 (PST) Message-ID: <4D2E0250.6090402@codemonkey.ws> Date: Wed, 12 Jan 2011 13:34:40 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Spice-devel] [Qemu-devel] spicevmv chardev, guest agents and paravirtual mouse References: <4D2DD2F1.6030801@redhat.com> <4D2DE7AA.3010202@codemonkey.ws> <4D2DFA1C.9010901@redhat.com> In-Reply-To: <4D2DFA1C.9010901@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: Hans de Goede Cc: spice-devel , Gerd Hoffmann , "qemu-devel@nongnu.org" 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