Re: [Xen-devel] [Hackathon minutes] PV network improvements

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 21 May 2013, Tim Deegan wrote:
> 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? :)

It's a good thing: even though it could be better our users don't seem
to mind. :)


> > 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.

Right. I would consider the performance of "backend with all the memory
mapped" as the limit we should try to achieve even without having all
the memory mapped. But if it turns out that we are very far from it, we
might want to consider allowing it as an option in the meantime.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel