Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Andres Lagar-Cavilla [mailto:andreslc@xxxxxxxxxxxxxx]
> Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of 
> problem and alternate
> solutions
> 
> >>> Just as a summary as this is getting to be a long thread - my
> >>> understanding has been that the hypervisor is suppose to toolstack
> >>> independent.
> >>
> >> Let's keep calm.  If people were arguing "xl (or xapi) doesn't need this
> >> so we shouldn't do it"
> >
> > Well Tim, I think this is approximately what some people ARE arguing.
> > AFAICT, "people" _are_ arguing that "the toolstack" must have knowledge
> > of and control over all memory allocation.  Since the primary toolstack
> > is "xl", even though xl does not currently have this knowledge/control
> > (and, IMHO, never can or should), I think people _are_ arguing:
> >
> > "xl (or xapi) SHOULDn't need this so we shouldn't do it".
> >
> >> that would certainly be wrong, but I don't think
> >> that's the case.  At least I certainly hope not!
> >
> > I agree that would certainly be wrong, but it seems to be happening
> > anyway. :-(  Indeed, some are saying that we should disable existing
> > working functionality (eg. in-guest ballooning) so that the toolstack
> > CAN have complete knowledge and control.
> 
> If you refer to my opinion on the bizarre-ness of the balloon, what you say 
> is not at all what I mean.
> Note that I took great care to not break balloon functionality in the face of 
> paging or sharing, and
> vice-versa.
> 
> Andres

And just to be clear, no, Andres, I was referring to George's statement
in http://lists.xen.org/archives/html/xen-devel/2012-12/msg01492.html 
where he says about a guest kernel doing ballooning:

"Well, it shouldn't be allowed to do it..."

I appreciate your great care to ensure backwards compatibility
and fully agree that both these functionalities (ballooning
and paging/sharing) are useful and valuable for significant
segments of the Xen customer base.  And for some smaller segment
they may need to safely co-exist and even, in the future, interact.

So... peace?

Dan

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