Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq page only one time

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/06/15 10:46, Andrew Cooper wrote:
> On 08/06/15 04:43, 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>
> The issue here is that we are running the restore algorithm over a
> domain which has already been running in Xen for a while.  This is a
> brand new usecase, as far as I am aware.
>
> Does the qemu process associated with this domain get frozen while the
> secondary is being reset, or does the process get destroyed and recreated.
>
> I have a gut feeling that it would be safer to clear all of the page
> other than the event channel, but that depends on exactly what else is
> going on.  We absolutely don't want to do is have an update to this page
> from the primary with an in-progress IOREQ.

Or actually worse, an update from the primary with a different event
channel in it.  There is no requirement or guarantee that the bufioreq
event channels are the same on either side.

~Andrew

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