[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1 COLO Pre 02/12] libxc/restore: zero ioreq page only one time



On 02/06/15 10:26, Yang Hongyang wrote:
> ioreq page contains evtchn which will be set when we resume the
> secondary vm the first time. The hypervisor will check if the
> evtchn is corrupted, so we cannot zero the ioreq page more
> than one time.
>
> The ioreq->state is always STATE_IOREQ_NONE after the vm is
> suspended, so it is OK if we only zero it one time.
>
> Signed-off-by: Yang Hongyang <yanghy@xxxxxxxxxxxxxx>
> Signed-off-by: Wen congyang <wency@xxxxxxxxxxxxxx>
> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Is the qemu process for the secondary running at this point?  If so,
this is very much unsafe.

~Andrew

> ---
>  tools/libxc/xc_sr_restore_x86_hvm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/libxc/xc_sr_restore_x86_hvm.c 
> b/tools/libxc/xc_sr_restore_x86_hvm.c
> index 6f5af0e..06177e0 100644
> --- a/tools/libxc/xc_sr_restore_x86_hvm.c
> +++ b/tools/libxc/xc_sr_restore_x86_hvm.c
> @@ -78,7 +78,8 @@ static int handle_hvm_params(struct xc_sr_context *ctx,
>              break;
>          case HVM_PARAM_IOREQ_PFN:
>          case HVM_PARAM_BUFIOREQ_PFN:
> -            xc_clear_domain_page(xch, ctx->domid, entry->value);
> +            if ( !ctx->restore.buffer_all_records )
> +                xc_clear_domain_page(xch, ctx->domid, entry->value);
>              break;
>          }
>  


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.