From patchwork Thu May 18 11:51:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luwei Kang X-Patchwork-Id: 9733973 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 89291600CC for ; Thu, 18 May 2017 11:53:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 788B22848E for ; Thu, 18 May 2017 11:53:29 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6D59B2874E; Thu, 18 May 2017 11:53:29 +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 F0E852848E for ; Thu, 18 May 2017 11:53:28 +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 1dBJyJ-0000CL-Jx; Thu, 18 May 2017 11:51:59 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dBJyI-0000CF-A7 for xen-devel@lists.xen.org; Thu, 18 May 2017 11:51:58 +0000 Received: from [193.109.254.147] by server-9.bemta-6.messagelabs.com id 07/3E-03557-DDA8D195; Thu, 18 May 2017 11:51:57 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAKsWRWlGSWpSXmKPExsVywNykQvdul2y kweZNXBZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa0Z7zyP2gl+CFbtW72JvYLzM28XIxSEkMJ1R 4vyz90xdjJwcEgK8EkeWzWCFsAMk3k67zQpR1MAoce38cUYIZw+jRPP5HcwQzi5GiVl7prKAt AgJrGGUuLFMDcRmE9CSeLL7ORuILSKgLNH76zcLSAOzwFpGif2bWthBEsICbhIzXv9hgihyl+ i82MAMYVtJrNiyBCzOIqAq8eDcLzCbVyBYYs/cJ0C9HEDLKiTmNiuAhDkF7CUO9WwH28UoICb x/dQasHJmAXGJW0/mQ70mILFkz3lmCFtU4uXjf6wQ4yUlJn36AmWLS6y5PB/O7tz3kw2iXlHi 7/pWRoiZOhILdn9ig7C1JZYtfM0McZqgxMmZT6DhoCjxcOYc9gmMsrOQnDELSfssJO2zkLQvY GRZxahenFpUllqka6aXVJSZnlGSm5iZo2toYKaXm1pcnJiempOYVKyXnJ+7iREY8wxAsINx3g n/Q4ySHExKoryHC2QjhfiS8lMqMxKLM+KLSnNSiw8xynBwKEnwfu8EygkWpaanVqRl5gCTD0x agoNHSYT3J0iat7ggMbc4Mx0idYpRUUqc9w5IQgAkkVGaB9cGS3iXGGWlhHkZgQ4R4ilILcrN LEGVf8UozsGoJMx7FWQKT2ZeCdz0V0CLmYAWNz+QBllckoiQkmpgTKiJtxReJK+ce8Qi5m65N gvPzp8yC9ntC35uutnzp+Zv1J49cf452WF3Lu5urUhbyhngGOrjdZdjdYvqnqRl4h+yhIJ5/z 47x2X8QXeKl0vL2Vchkiv0GD+xcpue3DN/C/dsL8f/bIWRv52VIlvXRIR1lL+/U7f58JUtP3Q 2Mi68WLF4i5GHEktxRqKhFnNRcSIAgIpTXnMDAAA= X-Env-Sender: luwei.kang@intel.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1495108314!90605457!1 X-Originating-IP: [192.55.52.120] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 42586 invoked from network); 18 May 2017 11:51:56 -0000 Received: from mga04.intel.com (HELO mga04.intel.com) (192.55.52.120) by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 18 May 2017 11:51:56 -0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2017 04:51:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.38,358,1491289200"; d="scan'208"; a="1149665352" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga001.fm.intel.com with ESMTP; 18 May 2017 04:51:54 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 18 May 2017 04:51:54 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 18 May 2017 04:51:54 -0700 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.193]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0319.002; Thu, 18 May 2017 19:51:52 +0800 From: "Kang, Luwei" To: Jan Beulich Thread-Topic: [PATCH v2] x86/vpmu: add cpu hot unplug notifier for vpmu Thread-Index: AQHSz5he6cI7hhwaIUeYZBSrUojSL6H5RvuAgACnnvA= Date: Thu, 18 May 2017 11:51:51 +0000 Message-ID: <82D7661F83C1A047AF7DC287873BF1E167D01B03@SHSMSX101.ccr.corp.intel.com> References: <1495036625-24071-1-git-send-email-luwei.kang@intel.com> <591D8063020000780015AC63@prv-mh.provo.novell.com> In-Reply-To: <591D8063020000780015AC63@prv-mh.provo.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "andrew.cooper3@citrix.com" , "boris.ostrovsky@oracle.com" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH v2] x86/vpmu: add cpu hot unplug notifier for vpmu 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 17.05.17 at 17:57, wrote: > > @@ -581,9 +582,14 @@ static void vpmu_arch_destroy(struct vcpu *v) > > > > if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy ) > > { > > - /* Unload VPMU first. This will stop counters */ > > - on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu), > > - vpmu_save_force, v, 1); > > + /* > > + * Unload VPMU first if VPMU_CONTEXT_LOADED being set. > > + * This will stop counters. > > + */ > > + if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) ) > > + on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu), > > + vpmu_save_force, v, 1); > > + > > vpmu->arch_vpmu_ops->arch_vpmu_destroy(v); > > } > > } > > So this is a good step towards what was requested during v1 review, provided it is correct (I'll let Boris comment). You didn't, > however, do anything about the other unguarded last_pcpu uses (in vpmu_load() and upwards from the code above in > vpmu_arch_destroy()). These _may_ be implicitly fine, but if so please at least add suitable ASSERT()s. > Hi Jan, Thanks for your reply. I think I understand the issue you mentioned. But sorry, I am not very clear what is your solution from your description. At first, I want to change like this: In summary, I think it is enough to solve the issue in vpmu_load() and vpmu_arch_destroy(). After cpu_callback() function, per_cpu(last_vcpu, vpmu->last_pcpu) will be NULL and VPMU_CONTEXT_LOADED will be clear. In vpmu_arch_destroy(), there will not make remote call to clear last. In vpmu_load(), remote call will guarded by VPMU_CONTEXT_LOADED flag check. As for vpmu->last_pcpu, we can't use some random online one to produce false. What is your opinion? Thanks, Luwei Kang --- a/xen/arch/x86/cpu/vpmu.c +++ b/xen/arch/x86/cpu/vpmu.c @@ -859,6 +859,7 @@ static int cpu_callback( { vpmu_save_force(vcpu); vpmu_reset(vpmu, VPMU_CONTEXT_LOADED); + per_cpu(last_vcpu, cpu) = NULL; // OR: this_cpu(last_vcpu) = NULL; } As you mentioned in before comments, it has been done in vpmu_save_force(). So this change is unnecessary.