From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Hackathon minutes] PV network improvements
Date: Tue, 21 May 2013 14:42:07 +0100 [thread overview]
Message-ID: <20130521134207.GA13181@ocelot.phlegethon.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1305211139170.4799@kaball.uk.xensource.com>
At 11:51 +0100 on 21 May (1369137063), Stefano Stabellini wrote:
> On Tue, 21 May 2013, Tim Deegan wrote:
> > At 19:31 +0100 on 20 May (1369078279), Wei Liu wrote:
> > > On Mon, May 20, 2013 at 03:08:05PM +0100, Stefano Stabellini wrote:
> > > > However it might still be worth considering as an option? The backend is
> > > > still trusted and protected from the frontend, but the frontend wouldn't
> > > > be protected from the backend.
> > > >
> > >
> > > I think Dom0 mapping all machine memory is a good starting point.
> >
> > I _strongly_ disagree. The opportunity for disaggregation and reduction
> > of privilege in backends is probably Xen's biggest techical advantage
> > and we should not be taking any backward steps there.
>
> While I agree with you, as a matter of fact the vast majority of Xen
> installations today do not use driver domains.
Sure, and that's a bad thing, right?
> However if the driver domains are "trusted"
> then I think they can also be trusted with a full memory map. After all
> it has been the case for all XenServer, OVM and SLES releases so far
> AFAIK.
...and that's a bad thing, right? :)
> Obviously in an ideal world we would be able to offer both at the same
> time, and maybe George's proposal is exactly what is going to achieve
> that. But I was describing the case that requires us to make a choice.
Righto. I don't think we need to worry about that yet. You're all
smart engineers, and I've heard a bunch of good ideas flying around that
address the costs of mapping and unmapping in backends.
Cheers,
Tim.
next prev parent reply other threads:[~2013-05-21 13:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 14:08 [Hackathon minutes] PV network improvements Stefano Stabellini
2013-05-20 14:49 ` George Dunlap
2013-05-20 18:33 ` Wei Liu
2013-05-21 8:22 ` Ian Campbell
2013-05-21 8:31 ` George Dunlap
2013-05-20 18:31 ` Wei Liu
2013-05-21 8:31 ` Ian Campbell
2013-05-21 9:26 ` Tim Deegan
2013-05-21 9:39 ` Wei Liu
2013-05-21 10:11 ` Tim Deegan
2013-05-21 10:01 ` George Dunlap
2013-05-21 10:06 ` Wei Liu
2013-05-21 10:51 ` Stefano Stabellini
2013-05-21 12:52 ` Konrad Rzeszutek Wilk
2013-05-21 13:32 ` Stefano Stabellini
2013-05-21 13:42 ` Tim Deegan [this message]
2013-05-21 16:58 ` Stefano Stabellini
2013-05-22 9:52 ` Tim Deegan
2013-05-22 9:55 ` Ian Campbell
2013-05-20 19:36 ` annie li
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=20130521134207.GA13181@ocelot.phlegethon.org \
--to=tim@xen.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xensource.com \
/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).