From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:47493)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QEi7G-0005Jk-MG
	for qemu-devel@nongnu.org; Tue, 26 Apr 2011 09:15:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QEi7B-0003Hk-Np
	for qemu-devel@nongnu.org; Tue, 26 Apr 2011 09:15:46 -0400
Received: from mail-yi0-f45.google.com ([209.85.218.45]:36394)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QEi7B-0003He-K5
	for qemu-devel@nongnu.org; Tue, 26 Apr 2011 09:15:41 -0400
Received: by yib19 with SMTP id 19so268336yib.4
	for <qemu-devel@nongnu.org>; Tue, 26 Apr 2011 06:15:41 -0700 (PDT)
Message-ID: <4DB6C57A.70803@codemonkey.ws>
Date: Tue, 26 Apr 2011 08:15:38 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
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>	<4D6E245A.5070800@redhat.com>
	<4DB68CFD.2060501@redhat.com>
In-Reply-To: <4DB68CFD.2060501@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality
 vs	supportive features
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>, Jes Sorensen <Jes.Sorensen@redhat.com>, dlaor@redhat.com, Michael Roth <mdroth@linux.vnet.ibm.com>, QEMU Developers <qemu-devel@nongnu.org>, Anthony Liguori <aliguori@linux.vnet.ibm.com>, Adam Litke <agl@us.ibm.com>, Amit Shah <amit.shah@redhat.com>, spice-devel@lists.freedesktop.org

On 04/26/2011 04:14 AM, Gerd Hoffmann wrote:
> Hi,
>
>>> 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.
>
> Yes. Spice does both reads and writes though, so a way to tag pages as
> dirty is needed.

Just implementing Spice as it currently is in a separate process isn't 
going to be useful IMHO.

I would think that the best approach would be to parse all of the ring 
requests in QEMU itself, and issue higher level commands to a separate 
process.  You can still have the video memory segment mapped in a 
separate process but QEMU should know enough about what's going on to 
take care of dirtying the memory.

Sort of like how we deal with SCSI passthrough.  We interpret enough of 
the command to hand it off to something else and then handle the return 
logic.

Having QEMU as an intermediary is important to preserve our current 
security model.  We shouldn't be passing unsanitized guest input to an 
external process.

Regards,

Anthony Liguori


> cheers,
> Gerd
>
>