diff mbox

fix xen hvm direct kernel boot

Message ID 1461901436-6881-1-git-send-email-cyliu@suse.com (mailing list archive)
State New, archived
Headers show

Commit Message

Chunyan Liu April 29, 2016, 3:43 a.m. UTC
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 <cyliu@suse.com>
---
 hw/core/loader.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Comments

Stefano Stabellini April 29, 2016, 10:59 a.m. UTC | #1
Please use my kernel.org email address. Also CC relevant maintainers.

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 <cyliu@suse.com>
> ---
>  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);
> -- 
> 1.8.5.6
> 
>
Chunyan Liu May 4, 2016, 5:34 a.m. UTC | #2
Any comments?

>>> On 4/29/2016 at 11:43 AM, in message
<1461901436-6881-1-git-send-email-cyliu@suse.com>, Chunyan Liu <cyliu@suse.com>
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 <cyliu@suse.com> 
> --- 
>  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);
Stefano Stabellini May 30, 2016, 4:10 p.m. UTC | #3
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 <cyliu@suse.com>

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.
Chunyan Liu June 1, 2016, 8:44 a.m. UTC | #4
>>> On 5/31/2016 at 12:10 AM, in message
<alpine.DEB.2.10.1605301705170.3896@sstabellini-ThinkPad-X260>, Stefano
Stabellini <sstabellini@kernel.org> wrote: 
> 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 <cyliu@suse.com> 
>  
> 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? 

Seems that's right. But after that changes, when doing direct kernel boot,
it reports:
qemu-system-x86_64: /home/cyliu/git/qemu/include/exec/ram_addr.h:48:
ramblock_ptr: Assertion `offset_in_ramblock(block, offset)' failed.

Looking at it.

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

Patch

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);