[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq page only one time
> -----Original Message----- > From: Wen Congyang [mailto:wency@xxxxxxxxxxxxxx] > Sent: 12 June 2015 11:26 > To: Paul Durrant; Yang Hongyang; Andrew Cooper; xen-devel@xxxxxxxxxxxxx > Cc: Wei Liu; Ian Campbell; guijianfeng@xxxxxxxxxxxxxx; > yunhong.jiang@xxxxxxxxx; Eddie Dong; rshriram@xxxxxxxxx; Ian Jackson > Subject: Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero ioreq > page only one time > > On 06/12/2015 03:41 PM, Paul Durrant wrote: > >> -----Original Message----- > >> From: Wen Congyang [mailto:wency@xxxxxxxxxxxxxx] > >> Sent: 12 June 2015 04:22 > >> To: Paul Durrant; Yang Hongyang; Andrew Cooper; xen- > devel@xxxxxxxxxxxxx > >> Cc: Wei Liu; Ian Campbell; guijianfeng@xxxxxxxxxxxxxx; > >> yunhong.jiang@xxxxxxxxx; Eddie Dong; rshriram@xxxxxxxxx; Ian Jackson > >> Subject: Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero > ioreq > >> page only one time > >> > >> On 06/11/2015 09:25 PM, Paul Durrant wrote: > >>>> -----Original Message----- > >>>> From: Yang Hongyang [mailto:yanghy@xxxxxxxxxxxxxx] > >>>> Sent: 11 June 2015 13:59 > >>>> To: Paul Durrant; Wen Congyang; Andrew Cooper; xen- > >> devel@xxxxxxxxxxxxx > >>>> Cc: Wei Liu; Ian Campbell; guijianfeng@xxxxxxxxxxxxxx; > >>>> yunhong.jiang@xxxxxxxxx; Eddie Dong; rshriram@xxxxxxxxx; Ian Jackson > >>>> Subject: Re: [Xen-devel] [PATCH v2 COLOPre 03/13] libxc/restore: zero > >> ioreq > >>>> page only one time > >>>> > >>>> > >>>> > >>>> On 06/11/2015 06:20 PM, Paul Durrant wrote: > >>>>>> -----Original Message----- > >>>>>> From: Wen Congyang [mailto:wency@xxxxxxxxxxxxxx] > >>>>>> Sent: 11 June 2015 09:48 > >>>>>> To: Paul Durrant; Andrew Cooper; Yang Hongyang; xen- > >>>> devel@xxxxxxxxxxxxx > >>>>>> Cc: Wei Liu; Ian Campbell; guijianfeng@xxxxxxxxxxxxxx; > >>>> [...] > >>>>> > >>>>>> > >>>>>> In our implementation, we don't start a new emulator. The codes > can > >>>> work, > >>>>>> but some bugs may be not triggered. > >>>>>> > >>>>> > >>>>> How do you reconcile the incoming QEMU save record with the > running > >>>> emulator state? > >>>> > >>>> We introduce a qmp command "xen-load-devices- > >>>> state"(libxl__qmp_restore) which > >>>> can restore the emulator state. The step of resotre emulator state at a > >>>> checkpoint is: > >>>> > >>>> 1. libxl__qmp_stop -> vm_stop() in qemu > >>>> 2. libxl__qmp_restore -> load_vmstate() in qemu > >>>> 3. libxl__qmp_resume -> vm_start() in qemu > >>>> > >>> > >>> Ok, that sounds like the ideal time to hook back into Xen by creating a > new > >> ioreq server. > >> > >> I have some questions about ioreq server: > >> 1. If we use old version xen and newest version qemu, is it OK? Is default > >> ioreq server created when the guest is created. > xen_create_ioreq_server() > >> does > >> nothing, and xen_get_ioreq_server_info() will get the default ioreq > server > >> information. > >> Is it right? > > > > No. It's not compatible in that direction. A new Xen will work with an old > QEMU but not the other way round. > > > >> 2. Why we create a default ioreq server when getting the hvm param if > there > >> is already a > >> not default ioreq server? > > > > If something reads the 'legacy' HVM params then that is Xen's trigger to > create the default server. Any 'new' emulator should be using the ioreq > server hypercalls so the default server will not be needed. > > If there are two ioreq servers: default ioreq server, and a ioreq server > created by emulator. The guest can work it correctly in > this case? You mean a secondary emulator? Yes, that's why there is the notion of default ioreq server... to allow a secondary emulator to be used even when an old QEMU is in use. > Is there any application(not emulator) that uses the libxenctrl > directly? > What do you mean by application? Toolstacks may use libxenctrl. Paul > Thanks > Wen Congyang > > > > >> 3. In the far end, we will clear the ioreq page, and this ioreq page is > >> used > for > >> default > >> ioreq server, is it right? > > > > Yes, AFAIK it's only the 'magic' pages that get cleared at the far end - and > that includes the default server pages. Other ioreq servers will have their > pages cleared on re-insertion to the P2M at the source end when the server > is disabled. > > > > Paul > > > >> > >> Thanks > >> Wen Congyang > >> > >>> > >>> Paul > >>> > >>>>> > >>>>> Paul > >>>>> > >>>>>> Thanks > >>>>>> Wen Congyang > >>>>>> > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Wen Congyang > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Paul > >>>>>>>>> > >>>>>>>>>> We will set to the guest to a new state, the old state should be > >>>>>> dropped. > >>>>>>>>>> > >>>>>>>>>> Thanks > >>>>>>>>>> Wen Congyang > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Paul > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks > >>>>>>>>>>>> Wen Congyang > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Paul > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>> Wen Congyang > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ~Andrew > >>>>>>>>>>>>>>> . > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> . > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> . > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Xen-devel mailing list > >>>>>>>>>> Xen-devel@xxxxxxxxxxxxx > >>>>>>>>>> http://lists.xen.org/xen-devel > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Xen-devel mailing list > >>>>>>>>> Xen-devel@xxxxxxxxxxxxx > >>>>>>>>> http://lists.xen.org/xen-devel > >>>>>>>>> . > >>>>>>>>> > >>>>>>> > >>>>>>> . > >>>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Xen-devel mailing list > >>>>> Xen-devel@xxxxxxxxxxxxx > >>>>> http://lists.xen.org/xen-devel > >>>>> . > >>>>> > >>>> > >>>> -- > >>>> Thanks, > >>>> Yang. > >>> . > >>> > > > > . > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |