From: Joao Martins <joao.m.martins@oracle.com>
To: Jim Fehlig <jfehlig@suse.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xen.org
Subject: Re: [libvirt] [PATCH 2/2] libxl: fix dom0 maximum memory setting
Date: Wed, 8 Feb 2017 16:59:04 +0000 [thread overview]
Message-ID: <589B4E58.4070304@oracle.com> (raw)
In-Reply-To: <589B4218.4070302@suse.com>
On 02/08/2017 04:06 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> On 02/02/2017 10:31 PM, Jim Fehlig wrote:
>>> When the libxl driver is initialized, it creates a virDomainDef
>>> object for dom0 and adds it to the list of domains. Total memory
>>> for dom0 was being set from the max_memkb field of libxl_dominfo
>>> struct retrieved from libxl, but this field can be set to
>>> LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
>>> explicitly set by the user.
>>>
>>> This patch adds some simple parsing of the Xen commandline,
>>> looking for a dom0_mem parameter that also specifies a 'max' value.
>>> If not specified, dom0 maximum memory is effectively all physical
>>> host memory.
>>>
>>> Signed-off-by: Jim Fehlig <jfehlig@suse.com>
>>> ---
>>> src/libxl/libxl_conf.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++
>>> src/libxl/libxl_conf.h | 3 ++
>>> src/libxl/libxl_driver.c | 2 +-
>>> 3 files changed, 79 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index b5186f2..bfe0e92 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -34,6 +34,7 @@
>>> #include "internal.h"
>>> #include "virlog.h"
>>> #include "virerror.h"
>>> +#include "c-ctype.h"
>>> #include "datatypes.h"
>>> #include "virconf.h"
>>> #include "virfile.h"
>>> @@ -1530,6 +1531,80 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
>>>
>>> }
>>>
>>> +/*
>>> + * dom0's maximum memory can be controled by the user with the 'dom0_mem' Xen
>>> + * command line parameter. E.g. to set dom0's initial memory to 4G and max
>>> + * memory to 8G: dom0_mem=4G,max:8G
>>> + *
>>> + * If not constrained by the user, dom0 can effectively use all host memory.
>>> + * This function returns the configured maximum memory for dom0 in kilobytes,
>>> + * either the user-specified value or total physical memory as a default.
>>> + */
>>> +unsigned long long
>>> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg)
>>> +{
>>> + char **cmd_tokens = NULL;
>>> + char **mem_tokens = NULL;
>>> + size_t i;
>>> + size_t j;
>>> + unsigned long long ret;
>>> + libxl_physinfo physinfo;
>>> +
>>> + if (cfg->verInfo->commandline == NULL ||
>>> + !(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
>>> + goto physmem;
>>> +
>>> + for (i = 0; cmd_tokens[i] != NULL; i++) {
>>> + if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
>>> + continue;
>>> +
>>> + if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
>>> + break;
>>> + for (j = 0; mem_tokens[j] != NULL; j++) {
>>> + if (STRPREFIX(mem_tokens[j], "max:")) {
>>> + char *p = mem_tokens[j] + 4;
>>> + unsigned long long multiplier = 1;
>>> +
>>> + while (c_isdigit(*p))
>>> + p++;
>>> + if (virStrToLong_ull(mem_tokens[j] + 4, &p, 10, &ret) < 0)
>>> + break;
>>> + if (*p) {
>>> + switch (*p) {
>>> + case 'k':
>>> + case 'K':
>>> + multiplier = 1024;
>>> + break;
>>> + case 'm':
>>> + case 'M':
>>> + multiplier = 1024 * 1024;
>>> + break;
>>> + case 'g':
>>> + case 'G':
>>> + multiplier = 1024 * 1024 * 1024;
>>> + break;
>>> + }
>>> + }
>>> + ret = (ret * multiplier) / 1024;
>>> + goto cleanup;
>>> + }
>>> + }
>>> + }
>>> +
>>> + physmem:
>>> + /* No 'max' specified in dom0_mem, so dom0 can use all physical memory */
>>> + libxl_physinfo_init(&physinfo);
>>> + libxl_get_physinfo(cfg->ctx, &physinfo);
>> Despite being an unlikely event, libxl_get_physinfo can fail here - I think you
>> need to check the return value here.
>
> Bummer. I was hoping this function could always return a sane value for dom0 max
> memory. But I'm not really sure what that would be if libxl_get_physinfo failed.
>
Yeah, We probably have some serious concerns if this fails. And given that
libxlAddDom0 happens early while bootstrapping the libxl module, it might be
good to warn the user (following similar pattern throughout the rest of the code):
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("libxl_get_physinfo_info failed"));
or perhaps simply VIR_WARN?
>>> + ret = (physinfo.total_pages * cfg->verInfo->pagesize) / 1024;
>>> + libxl_physinfo_dispose(&physinfo);
>>> +
>>> + cleanup:
>>> + virStringListFree(cmd_tokens);
>>> + virStringListFree(mem_tokens);
>>> + return ret;
>>> +}
>>> +
>>> +
>>> #ifdef LIBXL_HAVE_DEVICE_CHANNEL
>>> static int
>>> libxlPrepareChannel(virDomainChrDefPtr channel,
>>> diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
>>> index 69d7885..c4ddbfe 100644
>>> --- a/src/libxl/libxl_conf.h
>>> +++ b/src/libxl/libxl_conf.h
>>> @@ -173,6 +173,9 @@ libxlDriverNodeGetInfo(libxlDriverPrivatePtr driver,
>>> int libxlDriverConfigLoadFile(libxlDriverConfigPtr cfg,
>>> const char *filename);
>>>
>>> +unsigned long long
>>> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg);
>>> +
>>> int
>>> libxlMakeDisk(virDomainDiskDefPtr l_dev, libxl_device_disk *x_dev);
>>> int
>>> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
>>> index 921cc93..e54b3b7 100644
>>> --- a/src/libxl/libxl_driver.c
>>> +++ b/src/libxl/libxl_driver.c
>>> @@ -615,7 +615,7 @@ libxlAddDom0(libxlDriverPrivatePtr driver)
>>> if (virDomainDefSetVcpus(vm->def, d_info.vcpu_online) < 0)
>>> goto cleanup;
>>> vm->def->mem.cur_balloon = d_info.current_memkb;
>>> - virDomainDefSetMemoryTotal(vm->def, d_info.max_memkb);
>>> + virDomainDefSetMemoryTotal(vm->def, libxlDriverGetDom0MaxmemConf(cfg));
>>
>> And perhaps checking here too on whether "libxlDriverGetDom0MaxmemConf(cfg) < 0" ?
>
> ATM, libxlDriverGetDom0MaxmemConf returns an unsigned long long. I could change
> the signature to
>
> int
> libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg,
> unsigned long long *maxmem)
>
> but again I'm not really sure what to do with maxmem in case of failure. Perhaps
> just set it to current_memkb?
Yeap, that's what I was thinking too.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-08 16:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 22:31 [PATCH 0/2] libxl: a few domain maximum memory fixes Jim Fehlig
2017-02-02 22:31 ` [PATCH 1/2] libxl: fix reporting of maximum memory Jim Fehlig
2017-02-02 22:31 ` [PATCH 2/2] libxl: fix dom0 maximum memory setting Jim Fehlig
2017-02-08 13:39 ` [libvirt] " Joao Martins
2017-02-08 16:06 ` Jim Fehlig
2017-02-08 16:59 ` Joao Martins [this message]
2017-02-08 22:23 ` Jim Fehlig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=589B4E58.4070304@oracle.com \
--to=joao.m.martins@oracle.com \
--cc=jfehlig@suse.com \
--cc=libvir-list@redhat.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).