Xen project Mailing List

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

On 09/01/17 11:52, 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?

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

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