Re: [Qemu-devel] [Xen-devel] [PATCH] increase maxmem before calling xc_domain_populate_physmap

[Wei Liu <wei.liu2@citrix.com>]

On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote:
[...]
> >>>>           hw_error("xc_domain_getinfo failed");
> >>>>       }
> >>>>-    if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb +
> >>>>-                            (nr_pfn * XC_PAGE_SIZE / 1024)) < 0) {
> >>>>+    max_pages = info.max_memkb * 1024 / XC_PAGE_SIZE;
> >>>>+    free_pages = max_pages - info.nr_pages;
> >>>>+    real_free = free_pages;
> >>>>+    if (free_pages > VGA_HOLE_SIZE) {
> >>>>+        free_pages -= VGA_HOLE_SIZE;
> >>>>+    } else {
> >>>>+        free_pages = 0;
> >>>>+    }
> >I don't think we need to subtract VGA_HOLE_SIZE.
> 
> If you do not use some slack (like 32 here), xen does report:
> 
> 
> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS
> (d5) [2014-11-29 17:07:21] Creating MP tables ...
> (d5) [2014-11-29 17:07:21] Loading ACPI ...
> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for domain
> 5: 1057417 > 1057416
> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0

This message is a bit red herring.

It's hvmloader trying to populate ram for firmware data. The actual
amount of extra pages needed depends on the firmware.

In any case it's safe to disallow hvmloader from doing so, it will just
relocate some pages from ram (hence shrinking *mem_end).

> extent: id=5 memflags=0 (0 of 1)
> (d5) [2014-11-29 17:07:21] vm86 TSS at 00098c00
> (d5) [2014-11-29 17:07:21] BIOS map:
> 
> 
> However while QEMU startup ends with 32 "free" pages (maxmem - curmem)
> this quickly changes to 23.  I.E. there are 7 more places that act like a
> call
> to xc_domain_populate_physmap_exact() but do not log errors if there is
> no free pages.  And just to make sure I do not fully understand what is
> happening here, after the message above, the domain appears to work
> fine and ends up with 8 "free" pages (code I do not know about ends up
> releasing populated pages).
> 
> So my current thinking is to have QEMU leave a few (9 to 32 (64?)) pages
> "free".
> 

Unless we know before hand how many pages hvmloader needs this number is
estimation at best.

Wei.