Re: Ubuntu 16.04.1 LTS kernel 4.4.0-57 over-allocation and xen-access fail

[Tamas K Lengyel <tamas@tklengyel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2947 bytes --]

On Mon, Jan 9, 2017 at 5:04 AM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 09/01/17 11:52, Jan Beulich wrote:
> >>>> On 09.01.17 at 12:36, <rcojocaru@bitdefender.com> 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?
>
> Because there is no other API available for doing rings like this.
>
> IMO, it is and always was a mistake to ever have rings like this in GFN
> space, but that ship has sailed (and come back with several XSAs over
> the years).  (Apparently, it was done this way originally so the RAM the
> ring took up was accounted to the domain, but there are easy ways to get
> the accounting correct without the attack surfaces).
>
> I have some very vague plans to introduce a new mapping API, for frames
> which mustn’t be accessable to the guest, but also to support exporting
> stats from Xen via shared memory rather than hypercall.  I should
> probably see about writing up a design for this, and seeing if someone
> has time to look into it.
>

+1, definitely let us know, this would be highly desirable for vm_event. It
would also make implementing multi-page rings a lot easier if we didn't
have to muck with magic pfns in the guest physmap.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 3885 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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