[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |