On Mon, Jan 9, 2017 at 5:04 AM, Andrew Cooper <andrew.coop...@citrix.com>
wrote:
> On 09/01/17 11:52, Jan Beulich wrote:
> >>>> On 09.01.17 at 12:36, <rcojoc...@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
