This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Disallow setting maxmem to higher value than tot

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Disallow setting maxmem to higher value than total physical memory size
From: Michal Novotny <minovotn@xxxxxxxxxx>
Date: Wed, 01 Sep 2010 16:18:56 +0200
Cc: "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 01 Sep 2010 07:18:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1283348230.12544.9506.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C7E47B2.9010805@xxxxxxxxxx> <1283345049.12544.9494.camel@xxxxxxxxxxxxxxxxxxxxxx> <4C7E4EAD.3060106@xxxxxxxxxx> <1283348230.12544.9506.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
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:

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:
dom0: total memory = 8192
domU: memory = 4096, maxmem = 8192 (xm mem-max domU 16384 fails)
and when you migrate to host B:
dom0: total memory = 16384
domU: memory = 4096, maxmem = 8192
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.


-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

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 Novotny<minovotn@xxxxxxxxxx>, RHCE
Virtualization Team (xen userspace), Red Hat

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>