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

[Don Slutz <dslutz@verizon.com>]

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