Re: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, November 21, 2012 1:32 AM
> To: Dan Magenheimer
> Cc: Ian Campbell; xen-devel@xxxxxxxxxxxxx; Dave Mccracken; Konrad Wilk; 
> ZhigangWang; Keir (Xen.org);
> Tim Deegan
> Subject: RE: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of 
> existing) hypercall
> 
> >>> On 20.11.12 at 18:52, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> >>  From: Tim Deegan [mailto:tim@xxxxxxx]
> >> Subject: Re: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of
> > existing) hypercall
> >>
> >> At 08:33 -0800 on 20 Nov (1353400380), Dan Magenheimer wrote:
> >> > per-domain.  Especially since that would improve launch of only a small
> >> > and shrinking class of domains (PV && superpages=1 && mem="huge"),
> >> > can we please consider it a possible future enhancement, not a 
> >> > showstopper?
> >>
> >> Please, no.  Either you need this benighted hypercall, or you don't.
> >> If you really need it, do it properly.
> >
> > Hi Tim --
> >
> > I must respectfully disagree.
> >
> > For years, Xen has been accepting features that work on a 64-bit
> > hypervisor but not on a 32-bit hypervisor.  And new features such
> > as memory-sharing/paging _could_ be designed to help PV domains and
> > have completely ignored PV but have still been accepted.  There is
> > clearly precedent for new features that don't enhance every
> > possible case.
> >
> > The claim feature dramatically decreases a real customer problem in
> > the vast majority of our customer environments with no loss of
> > functionality in the small remaining percentage.  This real problem
> > is getting continually worse as system physical RAM and domain memory
> > requirements increase.  So, yes, _we_ do need it.
> 
> A meaningful difference is that those other features have tools
> side users, while you add (from the perspective of the Xen tree)
> dead code. That is, it wouldn't have any chance of getting checked
> for correctness when committed (other than for not breaking
> existing code), and it will bit rot pretty quickly. Or did you mean
> to supply tools side integration before expecting this to be
> considered for applying?

Oracle uses xm and a proprietary toolstack.  I don't normally
work on the toolstack (and other Oracle folk that do are tied up
with a release right now)... I can probably come up with an
xm/xend patch but I expect an xm/xend patch won't be well-received.

> In any case, while the hypervisor side changes look acceptable,
> I'm afraid that without (mostly) convincing (almost) all of the
> maintainers, there's no perspective of this getting committed.

Thanks very much, Jan, for your repeated reviews and I'm
very pleased that you think the hypervisor patch is acceptable.

I was under the impression that the hypervisor was supposed
to be toolstack-independent.  I think I've thoroughly explained
Oracle's real customer need here... if advocates of other
toolstacks don't understand it, it's not from lack of my
trying.  (More words have been spilled on this topic now than
possibly any other 200 lines in Xen!)

If other maintainers wish to impose their toolstack requirements
on other vendors' toolstacks and/or block hypervisor enhancements
that don't fit with their idea of a toolstack's needs,  I
suppose that is a question that will need to be raised to the
Xen Advisory Board, and that is above my pay grade.

Happy (U.S.) Thanksgiving!
Dan

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