From patchwork Thu Aug 11 09:29:37 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Razvan Cojocaru X-Patchwork-Id: 9274803 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 BE66F60231 for ; Thu, 11 Aug 2016 09:32:03 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AAF98285B4 for ; Thu, 11 Aug 2016 09:32:03 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9F370285B5; Thu, 11 Aug 2016 09:32:03 +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 9CFFD285B7 for ; Thu, 11 Aug 2016 09:32:02 +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 1bXmJC-0006Fc-Jb; Thu, 11 Aug 2016 09:29:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bXmJB-0006FW-2h for xen-devel@lists.xen.org; Thu, 11 Aug 2016 09:29:49 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 3B/26-05127-C854CA75; Thu, 11 Aug 2016 09:29:48 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRWlGSWpSXmKPExsUSfTxjoW6365p wg3OrTS2WfFzM4sDocXT3b6YAxijWzLyk/IoE1oxdDZfZC3ZwVzxc/oO1gbGLs4uRk0NIwENi 4Ykupi5GLiB7LaPEnIbfUM41Roknn++ydTFygFX9eMgMEd/PKDGj9wYrSDebgKHE6o0tbCC2i IC0xLXPlxlBbGYBV4lz1w+wgPQKCwRItK70BzFZBFQlzq+xAKngBZr4Z3sjWKeEgJzEyWOTWS HsHIkjk7axg5RLCEhJ/G9VAtkqIdDNIrG/byM7RI2MxKOJN9kmMAosYGRYxahRnFpUllqka2S ul1SUmZ5RkpuYmaNraGCql5taXJyYnpqTmFSsl5yfu4kRGFT1DAyMOxivbvE7xCjJwaQkyisc szpciC8pP6UyI7E4I76oNCe1+BCjDAeHkgRvmsuacCHBotT01Iq0zBxgeMOkJTh4lER4bUHSv MUFibnFmekQqVOMilLivFNBEgIgiYzSPLg2WExdYpSVEuZlZGBgEOIpSC3KzSxBlX/FKM7BqC TMWw0yhSczrwRu+iugxUxAi0+YgS0uSURISTUwzs1veHXKV/vNjK+vz7rr177NsP0b465+r5X pqPzRU1rVct4m3PMU577o3uli2LAo5zqjwqnf/vpzJrh8vvvyxddpuTPacgXiHBeaWcyJnPmz ha/tvuXbIIbFZjLidiI9vhPUOP6ki4tEaVRLmDp9epa57L/8R+UTZfcnJN46/efVypD6xcY+S izFGYmGWsxFxYkAv7haPaQCAAA= X-Env-Sender: rcojocaru@bitdefender.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1470907787!50368514!1 X-Originating-IP: [91.199.104.161] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.84; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31199 invoked from network); 11 Aug 2016 09:29:47 -0000 Received: from mx01.bbu.dsd.mx.bitdefender.com (HELO mx01.bbu.dsd.mx.bitdefender.com) (91.199.104.161) by server-3.tower-206.messagelabs.com with DHE-RSA-AES128-GCM-SHA256 encrypted SMTP; 11 Aug 2016 09:29:47 -0000 Received: (qmail 16104 invoked from network); 11 Aug 2016 12:29:46 +0300 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; 11 Aug 2016 12:29:46 +0300 Received: from smtp01.buh.bitdefender.com (smtp.bitdefender.biz [10.17.80.75]) by mx-sr.buh.bitdefender.com (Postfix) with ESMTP id 2DA557FB88 for ; Thu, 11 Aug 2016 12:29:46 +0300 (EEST) Received: (qmail 18413 invoked from network); 11 Aug 2016 12:29:46 +0300 Received: from xen.dsd.ro (HELO xen.dsd.bitdefender.biz) (rcojocaru@bitdefender.com@10.10.14.109) by smtp01.buh.bitdefender.com with AES128-SHA256 encrypted SMTP; 11 Aug 2016 12:29:46 +0300 From: Razvan Cojocaru To: xen-devel@lists.xen.org Date: Thu, 11 Aug 2016 12:29:37 +0300 Message-Id: <1470907777-9212-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 smtp01.buh.bitdefender.com, sigver: 7.66791 X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: Build: [Engines: 2.15.6.911, Dats: 430100, Stamp: 3], Multi: [Enabled, t: (0.000008, 0.001640)], BW: [Enabled, t: (0.000007,0.000001)], RBL DNSBL: [Disabled], APM: [Enabled, Score: 500, t: (0.002552), Flags: 85D2ED72; NN_NO_CONTENT_TYPE; NN_NO_LINK_NMD; NN_LEGIT_BITDEFENDER; NN_LEGIT_S_SQARE_BRACKETS; NN_LEGIT_MAILING_LIST_TO], SGN: [Enabled, t: (0.016098)], URL: [Enabled, t: (0.000006)], RTDA: [Enabled, t: (0.013590), Hit: No, Details: v2.3.11; Id: 2m1ghjn.1apqaoe9n.bboe], total: 0(775) X-BitDefender-CF-Stamp: none Cc: tamas@tklengyel.com, Razvan Cojocaru Subject: [Xen-devel] [PATCH V3] common/vm_event: synchronize vCPU state in vm_event_resume() 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 Vm_event_vcpu_pause() needs to use vcpu_pause_nosync() in order for the current vCPU to not get stuck. A consequence of this is that the custom vm_event response handlers will not always see the real vCPU state in v->arch.user_regs. This patch makes sure that the state is always synchronized in vm_event_resume, before any handlers have been called. This problem especially affects vm_event_set_registers(). Simply checking vm_event_pause_count to make sure the vCPU is paused suffices since there's only one ring / consumer at a time, and events are being processed one-by-one, so the toolstack won't unpause the vCPU behind our backs. Signed-off-by: Razvan Cojocaru Acked-by: Tamas K Lengyel --- Changes since V2: - Updated the commit text. --- xen/common/vm_event.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index 941345b..53cab90 100644 --- a/xen/common/vm_event.c +++ b/xen/common/vm_event.c @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved) v = d->vcpu[rsp.vcpu_id]; /* + * Make sure the vCPU state has been synchronized for the custom + * handlers. + */ + if ( atomic_read(&v->vm_event_pause_count) ) + sync_vcpu_execstate(v); + + /* * In some cases the response type needs extra handling, so here * we call the appropriate handlers. */