From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55186 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pujiy-0003Ui-Jm for qemu-devel@nongnu.org; Wed, 02 Mar 2011 05:56:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pujiw-0008QL-So for qemu-devel@nongnu.org; Wed, 02 Mar 2011 05:56:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pujiw-0008Pi-Jw for qemu-devel@nongnu.org; Wed, 02 Mar 2011 05:56:06 -0500 Message-ID: <4D6E2240.8060001@redhat.com> Date: Wed, 02 Mar 2011 12:56:00 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features References: <4D6BD085.8000001@redhat.com> <4D6CE170.6060108@redhat.com> <4D6D01E2.1070908@redhat.com> <4D6E1B28.8090400@redhat.com> In-Reply-To: <4D6E1B28.8090400@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: Juan Quintela , QEMU Developers , Michael Roth , Anthony Liguori , Gerd Hoffmann , Adam Litke , Amit Shah , spice-devel@lists.freedesktop.org On 03/02/2011 12:25 PM, Jes Sorensen wrote: > On 03/01/11 15:25, Dor Laor wrote: >> On 03/01/2011 02:40 PM, Anthony Liguori wrote: >>> >>> On Mar 1, 2011 7:07 AM, "Dor Laor">> > Qemu is the one that should spawn them and they should be transparent >>> from the management. This way running qemu stays the same and qemu just >>> need to add the logic to get a SIGCHILD and potentially re-execute an >>> dead son process. >>> >>> Spice is the logical place to start, no? It's the largest single >>> dependency we have and it does some scary things with qemu_mutex. I >>> would use spice as a way to prove the concept. >> >> I agree it is desirable to the this for spice but it is allot more >> complex than virtagent isolation. Spice is performance sensitive and >> contains much more state. It needs to access the guest memory for >> reading the surfaces. It can be solved but needs some major changes. >> Adding spice-devel to the discussion. > > I had a few thoughts about this already, which I think will work for > both spice and vnc. What we could do is to expose the video memory via > shared memory. That way a spice or vnc daemon could get direct access to > the memory, this would limit communication to keyboard/mouse events, as > well as video mode info, and possibly notifications to the client about > which ranges of memory have been updated. > > Using shared memory this way should allow us to implement the video > clients without performance loss, in fact it should be beneficial since > it would allow them to run fully separate from the host daemon. Why do you call it a daemon? Each VM instance should have only one, the 'host daemon' naming is misleading. The proper solution long term is to sandbox qemu in a way that there privileged mode and non privileged mode. It might be implemented using separate address space or not. Most operations like vnc/rpc/spice/usb should be run with less privileges. The main issue is that doing it right will take time and we'll want virt-agent be merged before the long term solution is ready. The best approach would be gradual development > > Cheers, > Jes >