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>
---
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
