[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 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?

Jan


_______________________________________________
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®.