[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] ARM: Adjusting guest memory size through xl mem-{set|max} fails

Hi Wei,

On 07/18/2017 01:16 PM, Wei Liu wrote:
> On Mon, Jul 17, 2017 at 06:19:09PM +0200, Sergej Proskurin wrote:
>> Hi Julien,
>> On 07/17/2017 03:53 PM, Julien Grall wrote:
>>> (+Wei and Ian)
>>> Hi Sergej
>>> On 17/07/17 13:04, Sergej Proskurin wrote:
>>>> Hi all,
>>>> My setup comprises an ARMv7 (Arndale, Linux kernel v4.11.6) and an ARMv8
>>>> (LeMaker HiKey, Linux kernel v4.9.0) development board. On both boards,
>>>> I have Xen version 4.10-unstable running with the associated tools to
>>>> manage a domu.
>>>> Currently, I am trying to get xl mem-{set|max} to work on both
>>>> architectures. Unfortunately, both command invocations fail with the
>>>> following message (I remember using xl mem-{set|max} on ARMv7 before
>>>> with Xen version 4.7 and 4.8):
>>>> ---
>>>> xl: libxl.c:339: libxl_defbool_val: Assertion
>>>> `!libxl_defbool_is_default(db)' failed.
>>>> Aborted
>>>> ---
>>> I haven't myself tried to use xl mem-{set|max}. Looking at the assert,
>>> you hit because a boolean is not initialized. It would be interesting
>>> to know which one.
>>> I have CCed the tools maintainers to get more feedback.
> Can you provide a backtrace?
> $ ulimit -c unlimited
> $ xl mem-set
> That should generate a coredump, on which you can use gdb to get a
> backtrace.

I get the following core dumps on ARMv8:

(gdb) bt
#0  0x0000ffffacb509e8 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x0000ffffacb51cf0 in __GI_abort () at abort.c:89
#2  0x0000ffffacb4a3b8 in __assert_fail_base (
    fmt=0xffffacc376f0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    file=file@entry=0xffffacd769e0 "libxl.c", line=line@entry=339,
function=<optimized out>)
    at assert.c:92
#3  0x0000ffffacb4a470 in __GI___assert_fail (
    assertion=0xffffacd76c38 "!libxl_defbool_is_default(db)",
file=0xffffacd769e0 "libxl.c",
    line=339, function=<optimized out>) at assert.c:101
#4  0x0000ffffacce13f8 in libxl_defbool_val (db=...) at libxl.c:339
#5  0x0000ffffacd490f8 in libxl__arch_extra_memory (gc=0xffffc5d47790,
    out=0xffffc5d47788) at libxl_arm.c:116
#6  0x0000ffffacd39764 in libxl_set_memory_target (ctx=0xaaab014bf050,
    target_memkb=522240, relative=0, enforce=1) at libxl_mem.c:206
#7  0x0000aaaac5f86abc in set_memory_target (domid=1, mem=0xffffc5d47e64
"510m") at xl_mem.c:69
#8  0x0000aaaac5f86bac in main_memset (argc=3, argv=0xffffc5d47a20) at
#9  0x0000aaaac5f72528 in main (argc=3, argv=0xffffc5d47a20) at xl.c:369

As far as I understand, the problem seems to be in libxl_arm.c:116,
checking for info->acpi.

According to docs/man/xl.cfg.pod.5.in, the ACPI option is true for x86
while it's false for ARM by default. By setting acpi = 1 in domu.cfg,
the previous error disappears, yet I get the following error:

root@avocet:~# xl mem-set 2 510m
libxl: error: libxl_arm_acpi.c:89:libxl__estimate_madt_size: Unknown GIC
libxl: error: libxl_mem.c:208:libxl_set_memory_target: Couldn't get arch
extra constant memory size
: Function not implemented
cannot set domid 2 dynamic max memory to : 510m

When I set acpi = 1 on my ARMv7 board, I get the following error already
during the domain creation process:

root@thanatos:~# xl create domu.cfg
Parsing config from domu.cfg
libxl: error: libxl_dom.c:418:libxl__build_pre: Couldn't get arch extra
constant memory size: No su
ch file or directory
libxl: error: libxl_create.c:1217:domcreate_rebuild_done: Domain
3:cannot (re-)build domain: -3
libxl: error: libxl_domain.c:1003:libxl__destroy_domid: Domain
3:Non-existant domain
libxl: error: libxl_domain.c:962:domain_destroy_callback: Domain
3:Unable to destroy guest
libxl: error: libxl_domain.c:889:domain_destroy_cb: Domain 3:Destruction
of domain failed


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.