[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH V3] common/vm_event: synchronize vCPU state in vm_event_resume()
On Aug 11, 2016 03:29, "Razvan Cojocaru" <rcojocaru@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
>
> ---
> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|