From patchwork Tue Jan 10 09:06:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Razvan Cojocaru X-Patchwork-Id: 9506769 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 066A7601E9 for ; Tue, 10 Jan 2017 09:07:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F141828458 for ; Tue, 10 Jan 2017 09:07:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E5FB128487; Tue, 10 Jan 2017 09:07:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6D5D128458 for ; Tue, 10 Jan 2017 09:07:16 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQsMW-00056G-G3; Tue, 10 Jan 2017 09:05:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQsMU-00055H-R5 for xen-devel@lists.xenproject.org; Tue, 10 Jan 2017 09:04:58 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id A5/7B-12366-AB3A4785; Tue, 10 Jan 2017 09:04:58 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRWlGSWpSXmKPExsUSfTxjoe6OxSU RBs8XSFp83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBm/mw6yF+wSqej+08XYwLiSv4uRg0NIwF1i 8uqiLkZOIHMto8S8TX5djFxA9h1GiauTJrFBJDwkzv9ezAKRWMQosX7uISaQhLBAiMSSpR1gt ohAlMS71RdZIBpKJdY872QFsZkFNCXa3r8Gs9kEDCVWb2wBG8or4CTx5dQZdhCbRUBVoqnlMd gcUYFwiY5d19ghagQlTs58wgJyKKeAncScg6UQI9Ul/sy7xAxhy0tsfzsHzJYQyJFY8n0LE0i 5hICUxP9WJZCTJQQms0j8f/qKFaJGRuLRxJtsExhFZyHZMAvJ2FlIxi5gZF7FqF6cWlSWWqRr opdUlJmeUZKbmJmja2hgqpebWlycmJ6ak5hUrJecn7uJERgTDECwg/FWn/MhRkkOJiVR3uMTS iKE+JLyUyozEosz4otKc1KLDzHKcHAoSfCuWASUEyxKTU+tSMvMAUYnTFqCg0dJhHcXSJq3uC AxtzgzHSJ1ilGXY9qzxU+ZhFjy8vNSpcR5l4AUCYAUZZTmwY2AJYpLjLJSwryMQEcJ8RSkFuV mlqDKv2IU52BUEubdDTKFJzOvBG7TK6AjmICOiLQrBjmiJBEhJdXAyDlVKMulrJCp9yqDTsWV gLZp74qeli7dVaWxtS7oydapRvnPc0UeXnt9Q7Enuvy2oV7DpcMfuZVntC28plY1P3KDzyn5y a8ZGUKPzLZYLWoj/L6cwdaodULegrtzN0eeEU7UWvFbIu6W8Pee7sMXWlbMnBFxeXXcPNXc7s rEBVsnl985ePP+QSWW4oxEQy3mouJEAIB/wFsPAwAA X-Env-Sender: rcojocaru@bitdefender.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1484039095!78972485!1 X-Originating-IP: [91.199.104.161] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2214 invoked from network); 10 Jan 2017 09:04:56 -0000 Received: from mx01.bbu.dsd.mx.bitdefender.com (HELO mx01.bbu.dsd.mx.bitdefender.com) (91.199.104.161) by server-7.tower-206.messagelabs.com with DHE-RSA-AES128-GCM-SHA256 encrypted SMTP; 10 Jan 2017 09:04:56 -0000 Received: (qmail 4372 invoked from network); 10 Jan 2017 11:04:54 +0200 Received: from unknown (HELO mx-sr.buh.bitdefender.com) (10.17.80.103) by mx01.bbu.dsd.mx.bitdefender.com with AES256-GCM-SHA384 encrypted SMTP; 10 Jan 2017 11:04:54 +0200 Received: from smtp01.buh.bitdefender.com (smtp.bitdefender.biz [10.17.80.75]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 56E6C7FBEC for ; Tue, 10 Jan 2017 11:04:54 +0200 (EET) Received: (qmail 27875 invoked from network); 10 Jan 2017 11:04:54 +0200 Received: from rcojocaru.dsd.ro (HELO ?10.10.14.59?) (rcojocaru@bitdefender.com@10.10.14.59) by smtp01.buh.bitdefender.com with SMTP; 10 Jan 2017 11:04:54 +0200 To: Andrew Cooper , xen-devel References: <790e8423-00b5-79ac-f0e4-f0ec92d79c32@bitdefender.com> <58fb1e1a-0fdd-f31a-77e4-e136fa0931de@citrix.com> From: Razvan Cojocaru Message-ID: <661a3921-e18f-8236-dde3-93d9327a657a@bitdefender.com> Date: Tue, 10 Jan 2017 11:06:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <58fb1e1a-0fdd-f31a-77e4-e136fa0931de@citrix.com> X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.6 on smtp01.buh.bitdefender.com, sigver: 7.69037 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.15.8.1074, Dats: 438256, Stamp: 3], Multi: [Enabled, t: (0.000011, 0.013614)], BW: [Enabled, t: (0.000010)], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, t: (0.004820), Flags: 85D2ED72; NN_LEGIT_VALID_REPLY; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled, t: (0.007626,0.000153)], URL: [Enabled, t: (0.000005, 0.000001)], RTDA: [Enabled, t: (0.034507), Hit: No, Details: v2.4.3; Id: 5eu5o9.1b61q342j.c5vg], total: 0(775) X-BitDefender-CF-Stamp: none Cc: Tamas K Lengyel Subject: Re: [Xen-devel] Ubuntu 16.04.1 LTS kernel 4.4.0-57 over-allocation and xen-access fail X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 01/09/2017 02:54 PM, Andrew Cooper wrote: > On 09/01/17 11:36, Razvan Cojocaru wrote: >> Hello, >> >> 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 > > Thinking further about this, what happens if you avoid removing the page > on exit? > > The first populate succeeds, and if you leave the page populated, the > second time you come around the loop, it should not be of type XTAB, and > the map should succeed. Sorry for the late reply, had to put out another fire yesterday. I've taken your recommendation to roughly mean this: vm_event_ring_unlock(ved); but this unfortunately still fails to map the page the second time. Do you mean to simply no longer munmap() the ring page from libxc / the client application? Thanks, Razvan diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index ba9690a..805564b 100644 --- a/xen/common/vm_event.c +++ b/xen/common/vm_event.c @@ -100,8 +100,11 @@ static int vm_event_enable( return 0; err: + /* destroy_ring_for_helper(&ved->ring_page, ved->ring_pg_struct); + */ + ved->ring_page = NULL; vm_event_ring_unlock(ved); return rc; @@ -229,9 +232,12 @@ static int vm_event_disable(struct domain *d, struct vm_event_domain *ved) } } + /* destroy_ring_for_helper(&ved->ring_page, ved->ring_pg_struct); + */ + ved->ring_page = NULL; vm_event_cleanup_domain(d);