From: Anthony Liguori <anthony@codemonkey.ws>
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
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Date: Tue, 26 Apr 2011 08:15:38 -0500 [thread overview]
Message-ID: <4DB6C57A.70803@codemonkey.ws> (raw)
In-Reply-To: <4DB68CFD.2060501@redhat.com>
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
>
>
next prev parent reply other threads:[~2011-04-26 13:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 16:42 [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features Jes Sorensen
2011-02-28 17:44 ` Anthony Liguori
2011-03-01 12:07 ` Dor Laor
2011-03-01 12:40 ` Anthony Liguori
2011-03-01 14:25 ` Dor Laor
2011-03-01 14:29 ` Anthony Liguori
2011-03-02 10:25 ` Jes Sorensen
2011-03-02 10:56 ` Dor Laor
2011-03-02 11:02 ` Jes Sorensen
2011-03-02 10:58 ` Alon Levy
2011-03-02 11:04 ` Dor Laor
2011-03-02 12:39 ` Alon Levy
2011-04-26 9:14 ` Gerd Hoffmann
2011-04-26 13:15 ` Anthony Liguori [this message]
2011-03-02 11:05 ` Jes Sorensen
2011-03-02 10:28 ` Jes Sorensen
2011-03-02 10:42 ` Dor Laor
2011-03-02 10:47 ` Jes Sorensen
2011-03-02 10:21 ` Jes Sorensen
2011-03-02 10:19 ` Jes Sorensen
2011-03-02 13:13 ` Michael Roth
2011-03-02 13:18 ` Jes Sorensen
2011-03-02 13:49 ` Michael Roth
2011-03-03 13:29 ` Jes Sorensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DB6C57A.70803@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Jes.Sorensen@redhat.com \
--cc=agl@us.ibm.com \
--cc=aliguori@linux.vnet.ibm.com \
--cc=amit.shah@redhat.com \
--cc=dlaor@redhat.com \
--cc=kraxel@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=spice-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).