Re: [Qemu-devel] [PATCH] fix xen hvm direct kernel boot

[Stefano Stabellini]

On Fri, 29 Apr 2016, Chunyan Liu wrote:
> Since commit a1666142: acpi-build: make ROMs RAM blocks resizeable,
> xen HVM direct kernel boot failed. Xen HVM direct kernel boot will
> insert a linuxboot.bin or multiboot.bin to /genroms, before this
> commit, in acpi_setup, for rom linuxboot.bin/multiboot.bin, it
> only needs 0x20000 size; after the commit, it will reserve x16
> size for resize, that is 0x200000 size. It causes xen_ram_alloc
> failed due to running out of memory.
> 
> To resolve it, either:
> 1. keep using original rom size instead of max size, don't reserve x16 size.
> 2. guest maxmem needs to be increased. (commit c1d322e6 "xen-hvm: increase
>    maxmem before calling xc_domain_populate_physmap" solved the problem for
>    a time, by accident. But then it is reverted in commit ffffbb369 due to
>    other problem.)
> 
> For 2, more discussion is needed about howto. So this patch tries 1, to
> use unresizable rom size in xen case in rom_set_mr.
> 
> Signed-off-by: Chunyan Liu <address@hidden>

Thank you for the patch!


>  hw/core/loader.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/core/loader.c b/hw/core/loader.c
> index c049957..5150101 100644
> --- a/hw/core/loader.c
> +++ b/hw/core/loader.c
> @@ -55,6 +55,7 @@
>  #include "exec/address-spaces.h"
>  #include "hw/boards.h"
>  #include "qemu/cutils.h"
> +#include "hw/xen/xen.h"
>  
>  #include <zlib.h>
>  
> @@ -818,7 +819,10 @@ static void *rom_set_mr(Rom *rom, Object *owner, const 
> char *name)
>      void *data;
>  
>      rom->mr = g_malloc(sizeof(*rom->mr));
> -    memory_region_init_resizeable_ram(rom->mr, owner, name,
> +    if (xen_enabled())
> +        memory_region_init_ram(rom->mr, owner, name, rom->datasize, 
> &error_fatal);
> +    else
> +        memory_region_init_resizeable_ram(rom->mr, owner, name,
>                                        rom->datasize, rom->romsize,
>                                        fw_cfg_resized,
>                                        &error_fatal);

Wouldn't it be better to change ram_block_add so that it calls
xen_ram_alloc with used_length rather than max_length?

I think that on Xen we want to only allocate used_length bytes, but
reserve max_length of address space.