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:18:56 +0200 Message-ID: <4C7E60D0.8050706@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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1283348230.12544.9506.camel@zakaz.uk.xensource.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 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. > > Which xenstore node are you talking about? > > > Oh, I confused xenstore and `xm list -l` output there. Sorry for that. I also tried to trigger the long listing using xl (using xl list -l) but I was having no luck to do so. The maxmem value is not available in xenstore but for `xm list -l` the value is there, you can try running: `xm list -l | grep maxmem` and before my patch applied you could see (maxmem 16777215) there. With my patch applied the correct value will be in this SXPR node. I tried following for xl utility: # xl list 0 Name ID Mem VCPUs State Time(s) Domain-0 0 6958 4 r----- 74.2 # xl list 0 -l Usage: xl [-v] list [options] [Domain] List information about all/some domains. Options: -l, --long Output all VM details -v, --verbose Prints out UUIDs # xl list -l 0 # so obviously there's no option to get the long domain listing using the libxl but it's useful to parse domain information (e.g. using shell scripts) that you can get using e.g .`xm list 0 -l` command. >>> You may which to boot a domain on the smaller host, (i.e. booting >>> ballooned with a current_pages suitable for the small host) and then >>> migrate it to the large machine where you then want to be able to >>> balloon to a value larger than was even possible on the previous >>> machine. >>> >>> If maxmem is not configured to the largest amount you consider you might >>> want to give the domain then this scenario fails but it should work. >>> >>> >> Well, if maxmem is not configured for PV domain you mean? >> > Sorry, I meant "If maxmem is not able to be configured to a value larger > than the physical memory on the current host...". > I see what you mean but I guess I already replied above. If we preserve the possibility to setup maxmem to higher value than dom0 physical memory is then `xm mem-max domU HigherValueThanPhysMem` will be possible to be issued which would lead to setup the invalid value in `xm list -l` output. Or should I just ignore the possibility domU maxmem could be set to higher value than host machine could provide and should I limit my check to dom0 only? Michal -- Michal Novotny, RHCE Virtualization Team (xen userspace), Red Hat