xl.cfg, memory options clarification

xl.cfg, memory options clarification

[Anthony PERARD]

Hi there,

There is an issue with the usage of "maxmem" options with qemu-upstream 
and it's probably do to my understanding of the options "memory", 
"videoram" and "maxmem" from a xl config file.

I though "memory" is the amount of RAM that a guest will have. So qemu 
upstream will have this value as an amount of RAM and when qemu ask for 
the videoram, ...

But if we begin to play with the "maxmem" option, then the guest become 
unusable, depending of the value of maxmem, we can have eithier a "MMIO 
emulation failed" or the bios does not see any disk.

I also try something else with the default qemu, having memory=128 and 
maxmem=1024. The guest boot, but after using it a bit Xen print:

(XEN) p2m_pod_demand_populate: Out of populate-on-demand memory! 
tot_pages 31733 pod_entries 231424
(XEN) domain_crash called from p2m-pod.c:1076
[...]
(XEN) Panic on CPU 0:
(XEN) Assertion 'lock->recurse_cnt < 0xfu' failed at spinlock.c:251

and reboot.

Is maxmem not suppose to be used with a guest ? Or is just broken.

 From all of that, I think I'll just make a change to the 
build_dm_args_new and give "-m $((maxmem - videoram))" instead of targetmem.

Regards,

-- 
Anthony PERARD

Re: xl.cfg, memory options clarification

[Olaf Hering]

On Fri, Mar 09, Anthony PERARD wrote:

> I though "memory" is the amount of RAM that a guest will have. So qemu
> upstream will have this value as an amount of RAM and when qemu ask for the
> videoram, ...

maxmem= is the amount of memory the guest OS thinks it has, the one it
has to configure itself for. Think of it as a virtual memory stick with
capacity n GiB.
memory= is the amount of memory the balloon driver in the guest OS is
supposed to leave for the guest OS.

Olaf

Re: xl.cfg, memory options clarification

[Ian Campbell]

On Fri, 2012-03-09 at 09:45 -0500, Anthony PERARD wrote:
> I also try something else with the default qemu, having memory=128 and 
> maxmem=1024. The guest boot, but after using it a bit Xen print:
> 
> (XEN) p2m_pod_demand_populate: Out of populate-on-demand memory! 
> tot_pages 31733 pod_entries 231424
> (XEN) domain_crash called from p2m-pod.c:1076

This might just be because a 128:1024 ratio is too much for PoD to cope
with? Or is your guest not running a balloon driver perhaps?

Using maxmem>memory for an HVM guest requires that the balloon driver
gets starts pretty early on in the guest boot up.

> [...]
> (XEN) Panic on CPU 0:
> (XEN) Assertion 'lock->recurse_cnt < 0xfu' failed at spinlock.c:251

This seems like a bug to me -- running out of PoD memory shouldn't crash
the host...

> and reboot.
> 
> Is maxmem not suppose to be used with a guest ? Or is just broken.
> 
>  From all of that, I think I'll just make a change to the 
> build_dm_args_new and give "-m $((maxmem - videoram))" instead of targetmem.

I think the value is probably correct but I guess there ought to be a
libxl__ function to just give you the right amount rather than
calculating it yourself -- perhaps Stefano can advise?

Ian.