From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41850 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Puk0R-0003bz-9V for qemu-devel@nongnu.org; Wed, 02 Mar 2011 06:14:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Puk0Q-0005YW-7t for qemu-devel@nongnu.org; Wed, 02 Mar 2011 06:14:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pujrc-0003Nl-Cy for qemu-devel@nongnu.org; Wed, 02 Mar 2011 06:05:04 -0500 Message-ID: <4D6E245A.5070800@redhat.com> Date: Wed, 02 Mar 2011 13:04:58 +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> <20110302105859.GC18908@playa.tlv.redhat.com> In-Reply-To: <20110302105859.GC18908@playa.tlv.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 , Juan Quintela , Michael Roth , QEMU Developers , Anthony Liguori , Gerd Hoffmann , Adam Litke , Amit Shah , spice-devel@lists.freedesktop.org On 03/02/2011 12:58 PM, Alon Levy wrote: > On Wed, Mar 02, 2011 at 11:25:44AM +0100, 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. >> > > I think that would work well for spice. Spice uses shared memory from the > pci device for both the framebuffer and surfaces/commands, but this is Is that the only DMA do you do? That's good for this model. > not really relevant at this level. What about IO and irq? that would add > additional latencies, no? because each io exit would need to be ipc'ed over > to the spice/vnc process? and same way in the other direction, requesting > qemu to trigger an interrupt in the next vm entry. The qxl device can be in the privileged qemu (as a start) and it will handle irqs directly. Even today you need to notify the spice server thread, so nothing will change > >> Cheers, >> Jes >>