Re: [Xen-devel] Ubuntu 16.04.1 LTS kernel 4.4.0-57 over-allocation and xen-access fail

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 01/09/2017 02:54 PM, Andrew Cooper wrote:
> On 09/01/17 11:36, Razvan Cojocaru wrote:
>> Hello,
>>
>> We've come across a weird phenomenon: an Ubuntu 16.04.1 LTS HVM guest
>> running kernel 4.4.0 installed via XenCenter in XenServer Dundee seems
>> to eat up all the RAM it can:
>>
>> (XEN) [  394.379760] d1v1 Over-allocation for domain 1: 524545 > 524544
>>
>> This leads to a problem with xen-access, specifically libxc which does
>> this in xc_vm_event_enable() (this is Xen 4.6):
>>
>> ring_page = xc_map_foreign_batch(xch, domain_id, PROT_READ | PROT_WRITE,
>>                                  &mmap_pfn, 1);
>>
>> if ( mmap_pfn & XEN_DOMCTL_PFINFO_XTAB )
>> {
>>     /* Map failed, populate ring page */
>>     rc1 = xc_domain_populate_physmap_exact(xch, domain_id, 1, 0, 0,
>>                                                &ring_pfn);
>>     if ( rc1 != 0 )
>>     {
>>         PERROR("Failed to populate ring pfn\n");
>>         goto out;
>>     }
>>
>> The first time everything works fine, xen-access can map the ring page.
>> But most of the time the second time fails in the
>> xc_domain_populate_physmap_exact() call, and again this is dumped in the
>> Xen log (once for each failed attempt):
>>
>> (XEN) [  395.952188] d0v3 Over-allocation for domain 1: 524545 > 524544
> 
> Thinking further about this, what happens if you avoid removing the page
> on exit?
> 
> The first populate succeeds, and if you leave the page populated, the
> second time you come around the loop, it should not be of type XTAB, and
> the map should succeed.

While considering a long-term source-code level solution, could there be
a workaround we haven't thought to try yet to prevent the guest from
hogging all available memory?


Thanks,
Razvan

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