From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: [RFC Patch v3 03/18] don't zero out ioreq page
Date: Fri, 5 Sep 2014 17:33:18 +0800
Message-ID: <5409835E.5050204@cn.fujitsu.com>
References: <1409908261-18682-1-git-send-email-wency@cn.fujitsu.com>
	<1409908261-18682-4-git-send-email-wency@cn.fujitsu.com>
	<9AAE0902D5BC7E449B7C8E4E778ABCD0455320@AMSPEX01CL01.citrite.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0455320@AMSPEX01CL01.citrite.net>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Paul Durrant <Paul.Durrant@citrix.com>, xen devel <xen-devel@lists.xen.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jiang Yunhong <yunhong.jiang@intel.com>, Eddie Dong <eddie.dong@intel.com>, Ian Jackson <Ian.Jackson@citrix.com>, Yang Hongyang <yanghy@cn.fujitsu.com>, Lai Jiangshan <laijs@cn.fujitsu.com>
List-Id: xen-devel@lists.xenproject.org

At 09/05/2014 05:25 PM, Paul Durrant Write:
>> -----Original Message-----
>> From: Wen Congyang [mailto:wency@cn.fujitsu.com]
>> Sent: 05 September 2014 10:11
>> To: xen devel
>> Cc: Ian Jackson; Ian Campbell; Eddie Dong; Jiang Yunhong; Lai Jiangshan; Yang
>> Hongyang; Wen Congyang; Paul Durrant
>> Subject: [RFC Patch v3 03/18] don't zero out ioreq page
>>
>> ioreq page may contain some pending I/O requests, and we need to
>> handle the pending I/O req after migration.
>>
>> TODO:
>> 1. update qemu to handle the pending I/O req
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> Cc: Paul Durrant <paul.durrant@citrix.com>
>> ---
>>  tools/libxc/xc_domain_restore.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/tools/libxc/xc_domain_restore.c
>> b/tools/libxc/xc_domain_restore.c
>> index fb4ddfc..21a6177 100644
>> --- a/tools/libxc/xc_domain_restore.c
>> +++ b/tools/libxc/xc_domain_restore.c
>> @@ -2310,8 +2310,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
>> uint32_t dom,
>>      }
>>
>>      /* These comms pages need to be zeroed at the start of day */
>> -    if ( xc_clear_domain_page(xch, dom, tailbuf.u.hvm.magicpfns[0]) ||
>> -         xc_clear_domain_page(xch, dom, tailbuf.u.hvm.magicpfns[1]) ||
>> +    if ( xc_clear_domain_page(xch, dom, tailbuf.u.hvm.magicpfns[1]) ||
>>           xc_clear_domain_page(xch, dom, tailbuf.u.hvm.magicpfns[2]) )
> 
> If we're not nuking pfn[0] then we probably shouldn't nuke pfn[1] either (buffererd ioreq).
> 

IIRC, in my early test, if we clear pfn[1], secondary vm doesn't response(I use vnc connect to secondary vm).
But I test it again, secondary vm doesn't response even if we don't clear pfn[1]. I will clear pfn[1] in
the next version.


> Does qemu need any modification? I don't think it makes any assumptions about the initial state of ioreqs so all you may have to do is make sure each vcpu event channel is kicked on resume (which is harmless even if there's no pending ioreq... qemu will just ignore it and wait again).

Do you mean hypervisor kickes each vcpu event channel on resume? I will try it.

Thanks
Wen Congyang

> 
>   Paul
> 
>>      {
>>          PERROR("error zeroing magic pages");
>> --
>> 1.9.3
> 
> .
>