From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48346 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PeqSg-0000mV-27 for qemu-devel@nongnu.org; Mon, 17 Jan 2011 09:53:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PeqSf-0004UG-2C for qemu-devel@nongnu.org; Mon, 17 Jan 2011 09:53:37 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:51201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PeqSe-0004Te-Rx for qemu-devel@nongnu.org; Mon, 17 Jan 2011 09:53:37 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0HEdN94023541 for ; Mon, 17 Jan 2011 07:39:23 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0HErSPj087134 for ; Mon, 17 Jan 2011 07:53:28 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0HErQfP000730 for ; Mon, 17 Jan 2011 07:53:27 -0700 Message-ID: <4D3457E2.8000603@linux.vnet.ibm.com> Date: Mon, 17 Jan 2011 08:53:22 -0600 From: Michael Roth 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> In-Reply-To: <4D3449C5.1030006@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: 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/2011 07:53 AM, Gerd Hoffmann wrote: > Hi, > >> OVERVIEW: >> >> There are a wide range of use cases motivating the need for a guest >> agent of some sort to extend the functionality/usability/control >> offered by QEMU. Some examples include graceful guest shutdown/reboot >> and notifications thereof, copy/paste syncing between host/guest, >> guest statistics gathering, file access, etc. > > 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. 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. 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, things like resolutions changes and clipboard contents could be communicated as asynchronous events to virtagent via this socket, in place of a separate daemon, and virtagent could have RPCs that can route/translate host->guest calls to the user-level daemons. Depending on the event, event-handling would either get consumed within virtagent, or punted to qemu's QMP event layer, which may need to be extended depending on the types of events we want to handle. The events would terminate within QEMU, but handlers could hook into external services. So that's the rough plan, but would be happy to hear any other thoughts on how we might approach this. > > cheers, > Gerd > >