Xen guest broken following "use memdev for RAM" patch

Xen guest broken following "use memdev for RAM" patch

[Anthony PERARD]

Hi,

Since bd457782b3b0 ("x86/pc: use memdev for RAM") it isn't possible to
start Xen guest anymore.

The error from qemu:
    qemu-system-i386: xen: failed to populate ram at 0
that comes from xen_ram_alloc() in hw/i386/xen/xen-hvm.c

xen_ram_alloc() is used to populate ram for PCI rom devices for example,
but it is also called for the guest RAM. We try to detect when the call
is for the ram by comparing the memory region with the one we created
during initialisation.

During initialisation of QEMU  for a Xen guest, we create a memory
region for the RAM by calling memory_region_init_ram() in
xen_ram_init(). But that memory region isn't used by QEMU anymore (since
mc->default_ram_id is set).

For Xen, we don't want QEMU to allocate the RAM, so using the memdev
won't work.

Do you have a suggestion on
- how we can bypass the generic code that allocate ram?
- keep using something similar to what we have now with
  memory_region_init_ram()?
(with accel=xen)

Maybe we need a new hostmem backend which don't allocate any memory but
creates a memory region, to be used by Xen?

Thanks,

-- 
Anthony PERARD

Re: Xen guest broken following "use memdev for RAM" patch

[Igor Mammedov]

On Mon, 23 Mar 2020 17:10:39 +0000
Anthony PERARD <anthony.perard@citrix.com> wrote:

> Hi,
> 
> Since bd457782b3b0 ("x86/pc: use memdev for RAM") it isn't possible to
> start Xen guest anymore.
> 
> The error from qemu:
>     qemu-system-i386: xen: failed to populate ram at 0
> that comes from xen_ram_alloc() in hw/i386/xen/xen-hvm.c
> 
> xen_ram_alloc() is used to populate ram for PCI rom devices for example,
> but it is also called for the guest RAM. We try to detect when the call
> is for the ram by comparing the memory region with the one we created
> during initialisation.
> 
> During initialisation of QEMU  for a Xen guest, we create a memory
> region for the RAM by calling memory_region_init_ram() in
> xen_ram_init(). But that memory region isn't used by QEMU anymore (since
> mc->default_ram_id is set).
> 
> For Xen, we don't want QEMU to allocate the RAM, so using the memdev
> won't work.
> 
> Do you have a suggestion on
> - how we can bypass the generic code that allocate ram?
> - keep using something similar to what we have now with
>   memory_region_init_ram()?
> (with accel=xen)

Not that I like it but as a quick fix, does following work for you?

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index e2d98243bc..bbca43bf33 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -953,6 +953,10 @@ static void xenfv_machine_options(MachineClass *m)
     m->desc = "Xen Fully-virtualized PC";
     m->max_cpus = HVM_MAX_VCPUS;
     m->default_machine_opts = "accel=xen";
+    /*
+     * opt out of system RAM being allocated by generic code
+     */
+    m->default_ram_id = NULL;
 }
 
 DEFINE_PC_MACHINE(xenfv, "xenfv", pc_xen_hvm_init,


> 
> Maybe we need a new hostmem backend which don't allocate any memory but
> creates a memory region, to be used by Xen?

Maybe, but I don't know about Xen enough so it's hard to make a suggestion,
so lets try to think out of the way to figure out how to approach it.

(In general, I'd prefer to get rid of dependency on 'accel' in memory_region_init_ram())

adapting xen code to use memdev isn't straightforward, since xen_ram_init()
fixes up memory_region size, it could be user provided
  ram_size
or
  4G + ram_size - HVM_BELOW_4G_RAM_END

question is why do you need to use memory_region_init_ram() at all if you are not actually
doing any allocation?
 
> Thanks,
>