From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52977 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfC9E-0007g6-JW for qemu-devel@nongnu.org; Tue, 18 Jan 2011 09:03:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfC9D-00031N-AB for qemu-devel@nongnu.org; Tue, 18 Jan 2011 09:03:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfC9D-00031B-0n for qemu-devel@nongnu.org; Tue, 18 Jan 2011 09:02:59 -0500 Message-ID: <4D359D8A.3000908@redhat.com> Date: Tue, 18 Jan 2011 15:02:50 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <4D3449C5.1030006@redhat.com> <4D3457E2.8000603@linux.vnet.ibm.com> In-Reply-To: <4D3457E2.8000603@linux.vnet.ibm.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: Michael Roth Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, abeekhof@redhat.com, marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org, Jes.Sorensen@redhat.com, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, markus_mueller@de.ibm.com On 01/17/11 15:53, Michael Roth wrote: > On 01/17/2011 07:53 AM, Gerd Hoffmann wrote: >> What is your plan to handle system-level queries+actions (such as >> reboot) vs. per-user stuff (such as cut+paste)? > > This is an area that hasn't been well-defined yet and is definitely open > for suggestions. One option would be to have two virtio-serial channels, one for the system and one for the user stuff. gdm could grant the desktop user access to the user channel like it does with sound devices and simliar stuff, so the user agent has access to it. Another option is to have some socket where the user agent can talk to the system agent and have it relay the requests. Maybe it is also possible to use dbus for communication between the system agent and user agent (and maybe other components). Maybe it even makes sense to run the dbus protocol over the virtio-serial line? Disclaimer: I know next to nothing about dbus details. > For host->guest RPCs the current plan is to always have the RPC executed > at the system level, but for situations involving a specific user we > fork and drop privileges with the RPC, and report back the status of the > fork/exec. The fork'd process would then do what it needs to do, then if > needed, communicate status back to the system-level daemon via some IPC > mechanism (most likely a socket we listen to in addition to the serial > channel) that can be used to send an event. The system-level daemon then > communicates these events back to the host with a guest->host RPC. Hmm. A bit heavy to fork+exec on every rpc. might be ok for rare events though. > Processes created independently of the system-level daemon could report > events in the same manner, via this socket. I think this might suit the > vdagent client model for Spice as well, Yes, vdagent works this way, except that *all* communication goes through that socket, i.e. events/requests coming from the host for the user-level agent are routed through that socket too. It is the only sane way to handle clipboard support IMHO as there is quite some message ping-pong involved to get a clipboard transaction done. How does xmlrpm transmit binary blobs btw? cheers, Gerd