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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Wed, Apr 10, 2013 at 02:13:39PM +0100, Ian Campbell wrote:
> On Tue, 2013-04-09 at 15:08 +0100, Daniel Kiper wrote:
> > 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.
>
> This is why I previously queried whether memory hotplug ought not to be
> a conscious admin decision.

Sure but I do not understand how this is related to above.
Addtitionally, which admin do you mean? Guest or host?

Daniel

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