From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v3] x86/VPMU: Clear last_vcpu when destroying VPMU Date: Wed, 17 Dec 2014 12:57:22 -0500 Message-ID: <5491C402.80201@oracle.com> References: <1418830547-2218-1-git-send-email-boris.ostrovsky@oracle.com> <5491BD3D02000078000C40D3@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5491BD3D02000078000C40D3@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 12/17/2014 12:28 PM, Jan Beulich wrote: >>>> Boris Ostrovsky 12/17/14 4:10 PM >>> >> + /* Need to clear last_vcpu in case it points to v */ >> + (void)cmpxchg(last, v, NULL); > > In a (later) reply to v2 I had indicated that it doesn't seem safe to so here but > rely on an IPI in the other path altering that value. Can you explain why you > think this is safe without changing the others to CPU-atomic accesses too? So the local access to last_vcpu in vpmu_load() may be still raced on (I was thinking that access in vpmu_load() would on the same processor as vpmu_destroy(), which is obviously not the case). So I will have to go back to IPI (I don't want to use cmpxchg in vpmu_load()). -boris