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

[Wen Congyang <wency@cn.fujitsu.com>]

On 06/02/2015 06:16 PM, Andrew Cooper wrote:
> 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@cn.fujitsu.com>
>> Signed-off-by: Wen congyang <wency@cn.fujitsu.com>
>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> 
> Is the qemu process for the secondary running at this point?  If so,
> this is very much unsafe.

No, we restore the secondary vm while it has been suspended.
The problem is that: the ioreq page containes evtchn which is
used by hypervisor to notify qemu. Before migration finished,
we can clear it because the evtchn is invalid, and qemu will
allocate it and save it in ioreq page later.

Thanks
Wen Congyang

> 
> ~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;
>>          }
>>  
> 
> .
>