[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/19/2017 12:22 PM, Wei Liu wrote:
> On Wed, Jul 19, 2017 at 11:40:19AM +0200, Sergej Proskurin wrote:
>> 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",
>>     assertion=assertion@entry=0xffffacd76c38
>> "!libxl_defbool_is_default(db)",
>>     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,
>> info=0xffffc5d472b0,
>>     out=0xffffc5d47788) at libxl_arm.c:116
>> #6  0x0000ffffacd39764 in libxl_set_memory_target (ctx=0xaaab014bf050,
>> domid=1,
>>     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
>> xl_mem.c:90
>> #9  0x0000aaaac5f72528 in main (argc=3, argv=0xffffc5d47a20) at xl.c:369
>> (gdb)
>> ---
>>
>> 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
>> version
>  
> Can you give this a try?
>
> ---8<---
> From bc3d96fa10e9eae7d9af92be66eb6b89b4c86a53 Mon Sep 17 00:00:00 2001
> From: Wei Liu <wei.liu2@xxxxxxxxxx>
> Date: Wed, 19 Jul 2017 11:19:15 +0100
> Subject: [PATCH] libxl: introduce arch domain configuration save function
>
> It appears that we should save the ARM GIC version and the ACPI config
> in the saved guest config file so that we can reference them later.
>
> Introduce an arch domain configuration save helper and fill that in
> for ARM.
>
> Reported-by: Sergej Proskurin <proskurin@xxxxxxxxxxxxx>
> Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> ---
> Not even compile tested on ARM...
> ---
>  tools/libxl/libxl_arch.h     |  5 +++++
>  tools/libxl/libxl_arm.c      | 12 ++++++++++++
>  tools/libxl/libxl_internal.c |  3 +++
>  tools/libxl/libxl_x86.c      |  6 ++++++
>  4 files changed, 26 insertions(+)
>
> diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> index 5e1fc6060e..a300707a23 100644
> --- a/tools/libxl/libxl_arch.h
> +++ b/tools/libxl/libxl_arch.h
> @@ -71,6 +71,11 @@ int libxl__arch_extra_memory(libxl__gc *gc,
>                               const libxl_domain_build_info *info,
>                               uint64_t *out);
>  
> +_hidden
> +void libxl__arch_update_domain_configuration(libxl__gc *gc,
> +                                             libxl_domain_config *dst,
> +                                             const libxl_domain_config *src);
> +
>  #if defined(__i386__) || defined(__x86_64__)
>  
>  #define LAPIC_BASE_ADDRESS  0xfee00000
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 8dd798bfdb..738f95be98 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -1067,6 +1067,18 @@ void libxl__arch_domain_build_info_acpi_setdefault(
>      libxl_defbool_setdefault(&b_info->acpi, false);
>  }
>  
> +void libxl__arch_update_domain_configuration(libxl__gc *gc,
> +                                             libxl_domain_config *dst,
> +                                             const libxl_domain_config *src)
> +{
> +    dst->b_info.arch_arm.gic_version = src->b_info.arch_arm.gic_version;
> +
> +    if (!libxl_defbool_is_default(src->b_info.acpi)) {
> +        bool val = libxl_defbool_val(src->b_info.acpi);
> +        libxl_defbool_set(&dst->b_info.acpi, val);
> +    }
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index f492dae5ff..4b11ff47ff 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -16,6 +16,7 @@
>  #include "libxl_osdeps.h" /* must come before any other headers */
>  
>  #include "libxl_internal.h"
> +#include "libxl_arch.h"
>  
>  void libxl__alloc_failed(libxl_ctx *ctx, const char *func,
>                           size_t nmemb, size_t size) {
> @@ -573,6 +574,8 @@ void libxl__update_domain_configuration(libxl__gc *gc,
>  
>      /* video ram */
>      dst->b_info.video_memkb = src->b_info.video_memkb;
> +
> +    libxl__arch_update_domain_configuration(gc, dst, src);
>  }
>  
>  /*
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index 455f6f0bed..c2a0185b82 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -587,6 +587,12 @@ void libxl__arch_domain_build_info_acpi_setdefault(
>      libxl_defbool_setdefault(&b_info->acpi, true);
>  }
>  
> +void libxl__arch_update_domain_configuration(libxl__gc *gc,
> +                                             libxl_domain_config *dst,
> +                                             const libxl_domain_config *src)
> +{
> +}
> +
>  /*
>   * Local variables:
>   * mode: C

Yeap, that did it! At least for mem-set on ARMv8.

However, I discovered that mem-max does not yet work entirely:

---
root@avocet:~# xl list
Name                                        ID   Mem VCPUs      State  
Time(s)
Domain-0                                     0  1024     6    
r-----      38.9
domu1                                        1   511     2    
-b----       0.3
root@avocet:~# xl mem-max 1 550m
root@avocet:~# xl mem-set 1 520m
libxl: error: libxl_mem.c:272:libxl_set_memory_target: Domain
1:memory_dynamic_max must be less than or equal to memory_static_max

cannot set domid 1 dynamic max memory to : 520m
---

According to the error messages from above, I assume this patch will not
fix the issues on ARMv7 yet, right?

Thanks so far :)

Cheers,
~Sergej

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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