[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.