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

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



On 01/09/2017 01:52 PM, Jan Beulich wrote:
>>>> On 09.01.17 at 12:36, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> 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
> 
> I don't think there's any weirdness here - if the guest ballooned
> itself to the exact boundary it is permitted to allocate, there's
> no way for another page to be allocated for it, no matter whether
> that's being requested by the guest itself or the tool stack. Before
> thinking of possible solutions, could you remind me why it is that
> the ring page gets put in guest pfn space in the first place? Isn't
> the ring used for communication between tool stack and hypervisor?

I couldn't say what the design reasons for putting the ring in guest
memory were - it's been like that way before my (and Tamas') time with
Xen, and I think we both thought there were good reasons for it. I agree
that having it in guest memory is less than ideal (as it has proven to be).


Thanks,
Razvan

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

 


Rackspace

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