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

[Don Slutz <dslutz@xxxxxxxxxxx>]

On 12/03/14 07:20, Stefano Stabellini wrote:
> 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
I went with a "leave some slack" so that the error message above is not 
output.
When a change to hvmloader is done so that the message does not appear 
during
normal usage, the extra pages in QEMU can be dropped.


> > > 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
Sounds like a plan for 4.6

    -Don Slutz

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