| Message ID | 1470907777-9212-1-git-send-email-rcojocaru@bitdefender.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Aug 11, 2016 03:29, "Razvan Cojocaru" <rcojocaru@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 <rcojocaru@bitdefender.com> Acked-by: Tamas K Lengyel <tamas@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 >
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. */
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 <rcojocaru@bitdefender.com> --- Changes since V2: - Updated the commit text. --- xen/common/vm_event.c | 7 +++++++ 1 file changed, 7 insertions(+)