From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58811 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PdT6c-0002x3-GQ for qemu-devel@nongnu.org; Thu, 13 Jan 2011 14:45:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PdT6T-0000X7-V9 for qemu-devel@nongnu.org; Thu, 13 Jan 2011 14:45:10 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:34829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PdT6T-0000Uj-Ra for qemu-devel@nongnu.org; Thu, 13 Jan 2011 14:45:01 -0500 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0DJKmZj008185 for ; Thu, 13 Jan 2011 14:20:53 -0500 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 71A7E4DE803E for ; Thu, 13 Jan 2011 14:41:52 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0DJivut2371810 for ; Thu, 13 Jan 2011 14:44:57 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0DJiupZ028994 for ; Thu, 13 Jan 2011 17:44:56 -0200 Subject: Re: spice vdagent protocol, was Re: [Qemu-devel] KVM call minutes for Jan 11 From: Adam Litke In-Reply-To: <20110113191805.GA6243@playa.redhat.com> References: <20110111155340.GC25929@x200.localdomain> <20110111183301.GO4581@playa.tlv.redhat.com> <1294930894.2197.78.camel@aglitke> <20110113191805.GA6243@playa.redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 13 Jan 2011 13:44:50 -0600 Message-ID: <1294947890.2197.93.camel@aglitke> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: qemu-devel@nongnu.org, spice-devel@freedesktop.org On Thu, 2011-01-13 at 21:18 +0200, Alon Levy wrote: > On Thu, Jan 13, 2011 at 09:01:34AM -0600, Adam Litke wrote: > > On Tue, 2011-01-11 at 20:33 +0200, Alon Levy wrote: > > > > Spice guest agent: > > > > - virt agent, matahari, spice agent...what is in spice agent? > > > > - spice char device > > > > - mouse, copy 'n paste, screen resolution change > > > > - could be generic (at least input and copy/paste) > > > > - send protocol details of what is being sent > > > > - need to look at how difficult it is to split it out from spice > > > > (how to split out in qemu vs. libspice) > > > > - goal to converge on common framework > > > > - more discussion on char device vs. protocol > > > > - eg. mouse_set breaks if mouse channel is part pv and part spice specific > > > > - Alon will send link to protocol and try to propose new interfaces > > > > > > http://spice-space.org/page/Whiteboard/AgentProtocol > > > > > > That's the corrent documentation. Notably the clipboard is a todo there, I'll > > > try to get that filled in. I'll continue this discussion on a separate thread later. > > > > Thanks for sending this out Alon. The use cases you have outlined are > > very similar to the ones we have for virtagent. The main differences I > > can see so far are the the data encoding strategy and the spice agent's > > method for delivery of events (mouse, etc). > > > Let me start by saying I'm not yet familiar with virtagent, I need to read > up on it (really didn't expect to try to merge with it at this point, not > that that isn't a good discussion). > > > Virtagent implements an RPC interface and uses xmlrpc-c to encode data > > in XML. This approach seems more general-purpose, extensible and easier > > to manage over the long term than relying on a custom binary > > representation. > > > > Agree with the benefits, but there are other alternatives like I outlined > in the thread that Gerd started, like a binary representation generated from > declarative description. Totally agree with using a single definition to > generate marshalling / demarshalling code. Not saying we can't work with > xmlrpc for qemu<->guest but for qemu<->client I think it is too wasteful. > > > As for event delivery, virtagent does not yet have an interface to allow > > external programs to subscribe to events. I am sure this can be done in > > a generic way that is backwards-compatible with the current spice > > architecture. Such an interface should allow arbitrary programs to > > subscribe to events but have no dependencies on those programs. I am > > not sure if something like D-Bus would be appropriate for Linux guests. > > We'd need to consider Windows too. > > > > Really not sure what you mean by events here, maybe I missed something. I was trying to get at the method by which a generic guest agent could forward things like mouse coordinates to Spice. Unfortunately, I sent this out before I noticed the other thread which covered this topic well. > > I see no reason why the core qemu use cases (shutdown, exec, copyfile) > > and the spice use cases (mouse, copy-paste, graphics reconfiguration) > > cannot (and should not) be satisfied by a single agent. Going forward, > > I think we'd need to agree on the wire protocol and guest-side event > > subscription. > > At first glance, i'd say: > * development - how would we develop a shared agent? two forks and a upstream > that no one cares about? shared repository? seems easier to me to use > a shared protocol and separate agents. Also better bug wise (bug in our > code doesn't bring down your agent) to have separate agents. Plugins are > not any better bug wise (segfault is a segfault). Also languages become a > problem (our agents are in C++/C atm win/lin). So in summary I think it > is better to have a shared qemu code (this has to be a single exe) and > protocol perhaps. I think it is critical that we have a single shared agent. The agent must be part of the default install of most future guests for any host->guest API to be useful. I will defer to discussions in the main thread regarding the structure of the daemon(s). > * security - we don't need our agent to be able to execute or to copy files > or to shutdown, so we'd need some mechanism to turn those off. There is > another different agent (going over virtio-serial too) used for RHEV > which probably does need these kind of features, so maybe need to involve > them in this discussion too. (RHEV isn't open source yet but aims to be > AFAIK). One idea that has been discussed is to restrict agent actions to programs/scripts that exist in an virtagent.d/ directory (similar to how udev rules are configured). Virtagent could install a set of scripts in /lib/virtagent/actions.d/ which can be overridden (or disabled) by the user in /etc/virtagent/actions.d/. If the 'shutdown' action is missing, then the agent will not be able to perform shutdowns. -- Thanks, Adam