From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Novotny Subject: Re: [PATCH] Disallow setting maxmem to higher value than total physical memory size Date: Wed, 01 Sep 2010 16:21:01 +0200 Message-ID: <4C7E614D.4060604@redhat.com> References: <4C7E47B2.9010805@redhat.com> <1283345049.12544.9494.camel@zakaz.uk.xensource.com> <4C7E4EAD.3060106@redhat.com> <1283348230.12544.9506.camel@zakaz.uk.xensource.com> <4C7E60D0.8050706@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C7E60D0.8050706@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "'xen-devel@lists.xensource.com'" List-Id: xen-devel@lists.xenproject.org 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, RHCE Virtualization Team (xen userspace), Red Hat