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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-05-21 at 17:58 +0100, Stefano Stabellini wrote:
> 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. :)

At least in the case of XenServer they are, as you know, actively moving
towards disaggregating. Other users such as XenClient, Qubeos, NSA etc
already do make use of disaggregation to a greater or lesser extent.

For the distros I think the lack of disaggregation is mostly our fault
as upstream for not making it easier to achieve, rather than a lack of
desire on the part of users. 

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

I think it is incredibly premature to be thinking about even considering
making this an option or anything other than a useful datapoint for
developers.

Ian.


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