vm_event: synchronize vCPU state in vm_event_resume()
authorRazvan Cojocaru <rcojocaru@bitdefender.com>
Fri, 12 Aug 2016 14:51:36 +0000 (16:51 +0200)
committerJan Beulich <jbeulich@suse.com>
Fri, 12 Aug 2016 14:51:36 +0000 (16:51 +0200)
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>
xen/common/vm_event.c

index e2111c5a2f60897de655a34b55a22e557e7c449d..8398af7203b7f9e88773298d90b15651455157f8 100644 (file)
@@ -387,6 +387,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.