From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 1/3] libxl: xl mem-max et consortes must update static-max in xenstore too Date: Wed, 10 Apr 2013 14:13:39 +0100 Message-ID: <1365599619.27868.53.camel@zakaz.uk.xensource.com> References: <1365107683-25564-1-git-send-email-daniel.kiper@oracle.com> <1365107683-25564-2-git-send-email-daniel.kiper@oracle.com> <20834.61063.415748.29907@mariner.uk.xensource.com> <20130409115459.GA29064@debian70-amd64.local.net-space.pl> <20836.4957.739568.272264@mariner.uk.xensource.com> <20130409140857.GA31533@debian70-amd64.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130409140857.GA31533@debian70-amd64.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper Cc: "xen-devel@lists.xensource.com" , Ian Jackson , "konrad.wilk@oracle.com" List-Id: xen-devel@lists.xenproject.org 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.