Re: [Xen-devel] [PATCH] Disallow setting maxmem to higher value than total physical memory size

[Michal Novotny <minovotn@xxxxxxxxxx>]

On 09/01/2010 04:18 PM, Michal Novotny wrote:
> On 09/01/2010 03:37 PM, Ian Campbell wrote:
> > On Wed, 2010-09-01 at 14:01 +0100, Michal Novotny wrote:
> > > On 09/01/2010 02:44 PM, Ian Campbell wrote:
> > > > On Wed, 2010-09-01 at 13:31 +0100, Michal Novotny wrote:
> > > >
> > > > > Hi,
> > > > > this is the patch to disallow changing the maxmem value to higher 
> > > > > value
> > > > > than total physical memory size since without this patch I was 
> > > > > able to
> > > > > set dom0 maxmem to higher (invalid) value which is not correct.
> > > > I think it is allowable for a domU though. Consider the scenario where
> > > > you have two hosts, one of which has more physical RAM than the other.
> > > Yeah, that's right. This scenario has been taken into mind and in fact
> > > this patch shouldn't do any harm on domU but it was mainly made for 
> > > dom0
> > > since dom0 default maxmem value is being set to 16 GiB on x86_64 
> > > machine
> > > which is not correct since it allows setting up up to 16 GiB RAM to 
> > > dom0
> > > although we have available only 8 GiB for example. Issuing `xm mem-set
> > > 10240` is therefore possible but it shouldn't be so it's trying to
> > > reserve 10240. The main issue is that xenstore was having maxmem value
> > > of 10240 instead of maximum value possible, i.e. value of 8192 in my
> > > case. Since xenstore itself was having the incorrect information it was
> > > implemented for xenstore to provide valid information too.
> > I'm saying that I think your patch does cause have harm on a domU, I
> > don't see anything which limits its actions to just dom0. Can you
> > explain why a domU is not effected by this change.
> >
> > As far as I can tell the patch will prevent the creation of a domU which
> > has a maxmem larger than the current host is capable of providing. The
> > maxmem setting is the maximum memory is the amount of memory which the
> > domain _could_ be given. This is different from the amount it currently
> > actually has which can be different due to ballooning etc.
> >
> > A domain must be configured with this maxmem value at boot time because
> > it may need to dynamically size some of data structures (e.g. the frame
> > table) to allow it to balloon up at a later date.
> Oh, ok. It's not limited to dom0 nevertheless I don't see anything to 
> be causing anything bad in domU. Of course, I can limit this to dom0 
> but for domU you can be having e.g. this:
> 1)
> dom0: total memory = 8192
> domU: memory = 4096, maxmem = 8192 (xm mem-max domU 16384 fails)
> 2)
> and when you migrate to host B:
> dom0: total memory = 16384
> domU: memory = 4096, maxmem = 8192
> 3)
> so when migrating back to host A you'll have:
> dom0: total memory = 8192
> domU: memory = 4096, maxmem = 8192
>
> But I don't think this behaviour is that bad since if you won't be 
> having the patch applied you could be able to set max_mem to value of 
> 16G in step 1 and then in step 2 (8G host machine) you could be able 
> to issue `xm mem-max domU 10240` which is not valid on host B (as in 
> step 2) so we could prevent this by setting up domain maxmem to be 
> 8192 which is the maximum on host B.
Oh, sorry. I meant `xm mem-set domU 10240` there.

Michal

--
Michal Novotny<minovotn@xxxxxxxxxx>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel