On Aug 11, 2016 03:29, "Razvan Cojocaru" <rcojoc...@bitdefender.com> wrote: > > 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 <rcojoc...@bitdefender.com>
Acked-by: Tamas K Lengyel <ta...@tklengyel.com> > > --- > 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. > */ > -- > 1.9.1 >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
