>>> On 10.08.16 at 09:35, <rcojoc...@bitdefender.com> wrote: > --- 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);
It seems to me that the latest with this change using a simple atomic_t won't suffice anymore - you'd now really need to make sure the user mode tools can't resume that vCPU behind your back, which aiui can only be achieved by using a suitable lock (perhaps a read/write one if reading the pause count is more common than updating it). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel