From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49159 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PdSgY-0002j0-VJ for qemu-devel@nongnu.org; Thu, 13 Jan 2011 14:18:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PdSgX-0003ZP-C6 for qemu-devel@nongnu.org; Thu, 13 Jan 2011 14:18:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61600) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PdSgX-0003ZC-1p for qemu-devel@nongnu.org; Thu, 13 Jan 2011 14:18:13 -0500 Date: Thu, 13 Jan 2011 21:18:07 +0200 From: Alon Levy Subject: Re: spice vdagent protocol, was Re: [Qemu-devel] KVM call minutes for Jan 11 Message-ID: <20110113191805.GA6243@playa.redhat.com> References: <20110111155340.GC25929@x200.localdomain> <20110111183301.GO4581@playa.tlv.redhat.com> <1294930894.2197.78.camel@aglitke> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1294930894.2197.78.camel@aglitke> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: qemu-devel@nongnu.org, spice-devel@freedesktop.org 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 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. * 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). Like I said in the beginning, I should go and read up on virtagent, and come back.. > > Thoughts? > There you go :) > -- > Thanks, > Adam > Alon