Re: [Xen-devel] [PATCH] common/vm_event: synchronize vCPU state in vm_event_resume()

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 08/09/2016 12:40 PM, Razvan Cojocaru 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().
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
> ---
>  xen/common/vm_event.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 941345b..22cafd4 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -388,6 +388,12 @@ 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.
> +         */
> +        sync_vcpu_execstate(v);
> +
> +        /*
>           * In some cases the response type needs extra handling, so here
>           * we call the appropriate handlers.
>           */
> 

Actually, reading the email Tim has sent in the meantime, I should only
call sync_vcpu_execstate() if I know for sure that the vCPU is paused.
My tests have passed because all the events I subscribed to were
requiring the vCPU to be paused, but obviously that's not always the case.

Will wait for more input, then submit V2.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel