From patchwork Thu Feb 9 17:11:38 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Razvan Cojocaru X-Patchwork-Id: 9565219 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 E5D3E601C3 for ; Thu, 9 Feb 2017 17:14:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D52962853F for ; Thu, 9 Feb 2017 17:14:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C903928544; Thu, 9 Feb 2017 17:14:39 +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 621BF2853F for ; Thu, 9 Feb 2017 17:14:39 +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 1cbsGI-0000nS-7C; Thu, 09 Feb 2017 17:12:02 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbsGG-0000n0-DY for xen-devel@lists.xen.org; Thu, 09 Feb 2017 17:12:00 +0000 Received: from [193.109.254.147] by server-3.bemta-6.messagelabs.com id BA/20-22349-FD2AC985; Thu, 09 Feb 2017 17:11:59 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRWlGSWpSXmKPExsUSfTxjoe69RXM iDNpPW1os+biYxYHR4+ju30wBjFGsmXlJ+RUJrBkvv01lL3glWbHleFID4zrhLkZODiEBd4kl 5zYxdjFyAdlrGCXufGtihnCuMkocOLGaBabq3tdjTBCJfYwSe99cZAZJsAkYSqze2MIGYosIS Etc+3yZEcRmFnCVOHf9AFizsIC/xP1rC8HqWQRUJWad+gVm8wp4SrxY1QdWIyEgJ3Hy2GRWCD tH4tfhFvYuRg4gW0rif6sSyF4JgfssEkeOvmWDqJGReDTxJtsERoEFjAyrGDWKU4vKUot0DS3 0kooy0zNKchMzc3QNDcz0clOLixPTU3MSk4r1kvNzNzECA4sBCHYw3twYcIhRkoNJSZRXtmBO hBBfUn5KZUZicUZ8UWlOavEhRhkODiUJ3tULgXKCRanpqRVpmTnAEIdJS3DwKInw/loAlOYtL kjMLc5Mh0idYlSUEud9BdInAJLIKM2Da4PF1SVGWSlhXkagQ4R4ClKLcjNLUOVfMYpzMCoJ83 IDo1SIJzOvBG76K6DFTECLr5+eBbK4JBEhJdXAGJ349tf/2PXVyvZZb59eFvjoKvI6M+rJvoa FQVfjVyx/sedrwpeMucHsc++EvU/expDs33L21CfJ2hoGQ1GbiKtFM14eW7TTLzvxdr6SxKxv vRqRlW6znrkp/NO4Jb3xwKpmq9SLhW1rGavMJI7HauTpOohKxnupFOjOXXUuaObXjl/M679dV mIpzkg01GIuKk4EACVr8AimAgAA X-Env-Sender: rcojocaru@bitdefender.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1486660318!73851628!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 32813 invoked from network); 9 Feb 2017 17:11:58 -0000 Received: from mx01.bbu.dsd.mx.bitdefender.com (HELO mx01.bbu.dsd.mx.bitdefender.com) (91.199.104.161) by server-14.tower-27.messagelabs.com with DHE-RSA-AES128-GCM-SHA256 encrypted SMTP; 9 Feb 2017 17:11:58 -0000 Received: (qmail 31407 invoked from network); 9 Feb 2017 19:11:57 +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; 9 Feb 2017 19:11:57 +0200 Received: from smtp02.buh.bitdefender.net (smtp.bitdefender.biz [10.17.80.76]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 6E00A7FBED for ; Thu, 9 Feb 2017 19:11:57 +0200 (EET) Received: (qmail 21823 invoked from network); 9 Feb 2017 19:11:57 +0200 Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz) (rcojocaru@bitdefender.com@10.10.14.109) by smtp02.buh.bitdefender.net with AES128-SHA256 encrypted SMTP; 9 Feb 2017 19:11:56 +0200 From: Razvan Cojocaru To: xen-devel@lists.xen.org Date: Thu, 9 Feb 2017 19:11:38 +0200 Message-Id: <1486660298-11961-1-git-send-email-rcojocaru@bitdefender.com> X-Mailer: git-send-email 1.9.1 X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 3.1.6 on smtp02.buh.bitdefender.net, sigver: 7.69552 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.15.8.1074, Dats: 440055, Stamp: 3], Multi: [Enabled, t: (0.000009, 0.009335)], BW: [Enabled, t: (0.000008)], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, t: (0.003381), Flags: 85D2ED72; NN_LARGER; NN_S_ENLARGE; NN_MORE_INFO_ADN; NN_SLOTS_IPX; NN_NO_CONTENT_TYPE; NN_LEGIT_SUMM_400_WORDS; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled, t: (0.006218,0.000107)], URL: [Enabled, t: (0.000005)], RTDA: [Enabled, t: (1.362800), Hit: No, Details: v2.4.3; Id: 2m1gj0t.1b8hpihtq.491j], total: 0(775) X-BitDefender-CF-Stamp: none Cc: tamas@tklengyel.com, Razvan Cojocaru Subject: [Xen-devel] [PATCH V3] common/vm_event: Prevent guest locking with large max_vcpus 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: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP It is currently possible for the guest to lock when subscribing to synchronous vm_events if max_vcpus is larger than the number of available ring buffer slots. This patch no longer blocks already paused VCPUs, fixing the issue for this use case, and wakes up as many blocked VCPUs as there are slots available in the ring buffer, eliminating the blockage for asynchronous events. Signed-off-by: Razvan Cojocaru Acked-by: Tamas K Lengyel --- Changes since V2: - Fixed typo: re-enabled commented-out code (for testing). --- xen/common/vm_event.c | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index 82ce8f1..45046d1 100644 --- a/xen/common/vm_event.c +++ b/xen/common/vm_event.c @@ -127,26 +127,11 @@ static unsigned int vm_event_ring_available(struct vm_event_domain *ved) static void vm_event_wake_blocked(struct domain *d, struct vm_event_domain *ved) { struct vcpu *v; - int online = d->max_vcpus; unsigned int avail_req = vm_event_ring_available(ved); if ( avail_req == 0 || ved->blocked == 0 ) return; - /* - * We ensure that we only have vCPUs online if there are enough free slots - * for their memory events to be processed. This will ensure that no - * memory events are lost (due to the fact that certain types of events - * cannot be replayed, we need to ensure that there is space in the ring - * for when they are hit). - * See comment below in vm_event_put_request(). - */ - for_each_vcpu ( d, v ) - if ( test_bit(ved->pause_flag, &v->pause_flags) ) - online--; - - ASSERT(online == (d->max_vcpus - ved->blocked)); - /* We remember which vcpu last woke up to avoid scanning always linearly * from zero and starving higher-numbered vcpus under high load */ if ( d->vcpu ) @@ -160,13 +145,13 @@ static void vm_event_wake_blocked(struct domain *d, struct vm_event_domain *ved) if ( !v ) continue; - if ( !(ved->blocked) || online >= avail_req ) + if ( !(ved->blocked) || avail_req == 0 ) break; if ( test_and_clear_bit(ved->pause_flag, &v->pause_flags) ) { vcpu_unpause(v); - online++; + avail_req--; ved->blocked--; ved->last_vcpu_wake_up = k; } @@ -280,8 +265,9 @@ void vm_event_put_request(struct domain *d, int free_req; unsigned int avail_req; RING_IDX req_prod; + struct vcpu *curr = current; - if ( current->domain != d ) + if ( curr->domain != d ) { req->flags |= VM_EVENT_FLAG_FOREIGN; #ifndef NDEBUG @@ -316,8 +302,9 @@ void vm_event_put_request(struct domain *d, * See the comments above wake_blocked() for more information * on how this mechanism works to avoid waiting. */ avail_req = vm_event_ring_available(ved); - if( current->domain == d && avail_req < d->max_vcpus ) - vm_event_mark_and_pause(current, ved); + if( curr->domain == d && avail_req < d->max_vcpus && + !atomic_read(&curr->vm_event_pause_count) ) + vm_event_mark_and_pause(curr, ved); vm_event_ring_unlock(ved);