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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 3 Dec 2014, Wei Liu wrote:
> 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).

That looks like a better solution


> > 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.
 
Right. It would be nice to get rid of any estimations by:
- making hvmloader use normal ram
- making qemu increase maxmem
- removing all the estimation from libxl

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