From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: dlaor@redhat.com
Cc: Juan Quintela <quintela@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
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
Subject: Re: [Qemu-devel] QEMU: Discussion of separating core functionality vs supportive features
Date: Wed, 02 Mar 2011 12:02:43 +0100 [thread overview]
Message-ID: <4D6E23D3.3080603@redhat.com> (raw)
In-Reply-To: <4D6E2240.8060001@redhat.com>
On 03/02/11 11:56, Dor Laor wrote:
> On 03/02/2011 12:25 PM, Jes Sorensen wrote:
>> On 03/01/11 15:25, Dor Laor wrote:
>> 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.
I refer to it as a daemon because it is something the client(s) will
connect to. But yes, there will be a daemon per VM.
> 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
Yes I agree, I don't think this will happen overnight, and blocking
virtagent with this would be bad.
Cheers,
Jes
next prev parent reply other threads:[~2011-03-02 11:02 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 [this message]
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
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=4D6E23D3.3080603@redhat.com \
--to=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).