From patchwork Thu Feb 9 06:57:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Razvan Cojocaru X-Patchwork-Id: 9564123 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 4F63360236 for ; Thu, 9 Feb 2017 07:00:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 178CF2851F for ; Thu, 9 Feb 2017 07:00:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0C09E28536; Thu, 9 Feb 2017 07:00:25 +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 026BF2851F for ; Thu, 9 Feb 2017 07:00:23 +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 1cbifk-0001jr-Bn; Thu, 09 Feb 2017 06:57:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cbifi-0001jl-Lv for xen-devel@lists.xen.org; Thu, 09 Feb 2017 06:57:38 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id 84/25-16730-1E21C985; Thu, 09 Feb 2017 06:57:37 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRWlGSWpSXmKPExsUSfTxjoe5DoTk RBjMXilgs+biYxYHR4+ju30wBjFGsmXlJ+RUJrBld/7+wFMyVrPh4LK+B8a1QFyMnh5CAu8Tm 3zeYIew1jBLtHR5djFxA9lVGietL7jNCJNwkrly+yAaR2McoMf1GE1gHm4ChxOqNLWwgtoiAt MS1z5fBGpgFXCXOXT/AAmILC/hLzOzYwg5iswioSsx/cxisnlfAQ2LV4aVgtoSAnMTJY5NZIe wciVMnngHFOYBsKYn/rUogeyUE7rFI/Nm1mBmiRkbi0cSbbBMYBRYwMqxi1ChOLSpLLdI1MtB LKspMzyjJTczM0TU0MNbLTS0uTkxPzUlMKtZLzs/dxAgMq3oGBsYdjM0n/A4xSnIwKYnyRvyf HSHEl5SfUpmRWJwRX1Sak1p8iFGGg0NJgve64JwIIcGi1PTUirTMHGCAw6QlOHiURHg5gEEux FtckJhbnJkOkTrFqCglzhsJkhAASWSU5sG1waLqEqOslDAvIwMDgxBPQWpRbmYJqvwrRnEORi Vh3ocg23ky80rgpr8CWswEtPj66Vkgi0sSEVJSDYzxj0UXvJz9ssD/yvlrFeeb1xy233OAle/ FNTGeDo62XrEpzKoPGh+e6Cxj+Lkp9a6hwjO+bpmf273OuK2cHVAV1Gwzia959zvbb4+0bKpn qpn/PfGN45bOBfuruQXqkzRX+BVM0Fvxlks/QnXtJdanHz2YCve0zJuxdYXqTK4fht+W7mJ5c GyuEktxRqKhFnNRcSIAHus/eqUCAAA= X-Env-Sender: rcojocaru@bitdefender.com X-Msg-Ref: server-5.tower-31.messagelabs.com!1486623456!81458572!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 29067 invoked from network); 9 Feb 2017 06:57:37 -0000 Received: from mx01.bbu.dsd.mx.bitdefender.com (HELO mx01.bbu.dsd.mx.bitdefender.com) (91.199.104.161) by server-5.tower-31.messagelabs.com with DHE-RSA-AES128-GCM-SHA256 encrypted SMTP; 9 Feb 2017 06:57:37 -0000 Received: (qmail 28804 invoked from network); 9 Feb 2017 08:57:35 +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 08:57:35 +0200 Received: from smtp03.buh.bitdefender.org (smtp.bitdefender.biz [10.17.80.77]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 513277FC29 for ; Thu, 9 Feb 2017 08:57:35 +0200 (EET) Received: (qmail 4460 invoked from network); 9 Feb 2017 08:57:35 +0200 Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz) (rcojocaru@bitdefender.com@10.10.14.109) by smtp03.buh.bitdefender.org with AES128-SHA256 encrypted SMTP; 9 Feb 2017 08:57:34 +0200 From: Razvan Cojocaru To: xen-devel@lists.xen.org Date: Thu, 9 Feb 2017 08:57:24 +0200 Message-Id: <1486623444-5679-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 smtp03.buh.bitdefender.org, sigver: 7.69546 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.15.8.1074, Dats: 440016, Stamp: 3], Multi: [Enabled, t: (0.000010, 0.016590)], BW: [Enabled, t: (0.000010)], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, t: (0.005266), 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.008099,0.000198)], URL: [Enabled, t: (0.000005)], RTDA: [Enabled, t: (0.409688), Hit: No, Details: v2.4.3; Id: 5euo87.1b8ethp0j.8g1d], total: 0(775) X-BitDefender-CF-Stamp: none Cc: tamas@tklengyel.com, Razvan Cojocaru Subject: [Xen-devel] [PATCH V2] 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 --- 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..76c4e2c 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);