[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et consortes must update static-max in xenstore too

On Tue, Apr 09, 2013 at 02:10:53PM +0100, Ian Jackson wrote:
> Daniel Kiper writes ("Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et 
> consortes must update static-max in xenstore too"):
> > On Mon, Apr 08, 2013 at 05:21:27PM +0100, Ian Jackson wrote:
> > > Doesn't this, together with your previous patch, conflate the "static
> > > maximum" (ie, boot-time memory size which in the absence of memory
> > > hotplug can never be exceeded), with the "xen maximum" (ie the
> > > enforced memory limit) ?
> > >
> > > I thought that the static-max xenstore key was used for the former.
> >
> > To some extent. However, static-max has always a bit larger value
> > than "xen maximum". xl uses static-max to enforce limits on guests
> > but it is just an info for guest itself. "xen maximum" is a kind
> > of hard limit which could not be exceeded and is enforced on guest
> > by Xen hypervisor.
> The reason for xl using static-max is that in the absence of memory
> hotplug, attempting to raise a guest above static-max will not work.
> And this check takes effect in xl.

OK but now it is quiet difficult (or close to impossible) to know
in advance that a given guest supports memory hotplug or not. That
is why I think that static-max should be unconditionally changed or
the guest should write something in xenstore to inform that it supports
memory hotplug and relevant check should be waived.

> So that's not "enforcing a limit on guests".

OK, it should be phrased that xl checks that itself does not exceeds limits.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.