From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=38284 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PujsB-0001Oz-Pe
	for qemu-devel@nongnu.org; Wed, 02 Mar 2011 06:05:40 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Jes.Sorensen@redhat.com>) id 1PujsA-0003ke-Ie
	for qemu-devel@nongnu.org; Wed, 02 Mar 2011 06:05:39 -0500
Received: from mx1.redhat.com ([209.132.183.28]:18332)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Jes.Sorensen@redhat.com>) id 1PujsA-0003k1-5k
	for qemu-devel@nongnu.org; Wed, 02 Mar 2011 06:05:38 -0500
Message-ID: <4D6E2478.3090006@redhat.com>
Date: Wed, 02 Mar 2011 12:05:28 +0100
From: Jes Sorensen <Jes.Sorensen@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality
	vs	supportive features
References: <4D6BD085.8000001@redhat.com>
	<AANLkTik-9oDv2UyRzVQQtKNumJnVT9pp_0U_5z+A9PSv@mail.gmail.com>
	<4D6CE170.6060108@redhat.com>
	<AANLkTin8qCDOjFQZ_heMc9fYqDBa+ErjtyzXYcRuXhgU@mail.gmail.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
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: dlaor@redhat.com, Juan Quintela <quintela@redhat.com>, Michael Roth <mdroth@linux.vnet.ibm.com>, QEMU Developers <qemu-devel@nongnu.org>, Anthony Liguori <aliguori@linux.vnet.ibm.com>, Gerd Hoffmann <kraxel@redhat.com>, Adam Litke <agl@us.ibm.com>, Amit Shah <amit.shah@redhat.com>, spice-devel@lists.freedesktop.org

On 03/02/11 11:58, Alon Levy wrote:
> On Wed, Mar 02, 2011 at 11:25:44AM +0100, Jes Sorensen wrote:
>> 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
> 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.

I am glad the shmem approach will work for Spice. There would be
something there with IRQs etc, I agree. but there are methods to help
that too, we could use a shared memory event ring for example.

Cheers,
Jes