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 alt
>>> 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
On Wed, Dec 17, 2014 at 11:53:41AM -0500, Boris Ostrovsky wrote:
> On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> >>We need to make sure that last_vcpu is not pointing to VCPU whose
> >>VPMU is being destroyed. Otherwise we
On 12/17/2014 11:21 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.
We have to do
On Wed, Dec 17, 2014 at 10:35:47AM -0500, Boris Ostrovsky wrote:
> We need to make sure that last_vcpu is not pointing to VCPU whose
> VPMU is being destroyed. Otherwise we may try to dereference it in
> the future, when VCPU is gone.
>
> We have to do this atomically since otherwise there is a (s
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to dereference it in
the future, when VCPU is gone.
We have to do this atomically since otherwise there is a (somewhat
theoretical) chance that between test and subsequent clearing
of la
