Thank you for your reply
I encounter other confusions,
1)when I read the code of restore() in checkpoint.py for paravirt
and restore() calls for the dominfo.completeRestore(),which call
_registerWatches(), and then call refreshShutdown(),
and in refreshShutdown(),if elif xeninfo['shutdown']: and if reason
== 'suspend' ,self._unwatchVM()will be called ,
if reason == 'suspend':
self._stateSet(DOM_STATE_SUSPENDED)
# Don't destroy the domain. XendCheckpoint will do
# this once it has finished. However, stop watching
# the VM path now, otherwise we will end up with one
# watch for the old domain, and one for the new.
self._unwatchVm()
and then ,why do we call _registerWatches() before refreshShutdown(),i
am confused about it,
and what is the function of dominfo.completeRestore()? it
introducedomain(),and storeDomDetails() and registerWatches()and
,refreshShutdown(),and why should it refreshShutdown()?and is it that in
refreshShutdown(),the old domain is cleaned and destoryed, or the new
domain is dealt with? i am confused
2) and the code of save() in the checkpoint.py, how does the
saveInputHandler synchronize with the XC_SAVE ? how many times do they
synchronize with each other？ only ,XC_SAVE sends "suspend" to
saveInputHandler, and then saveInputHandler send "done" to XC_SAVE
,is it right?
def saveInputHandler(line, tochild):
log.debug("In saveInputHandler %s", line)
if line == "suspend":
log.debug("Suspending %d ...", dominfo.getDomid())
dominfo.shutdown('suspend')
dominfo.waitForShutdown()
dominfo.migrateDevices(network, dst,
DEV_MIGRATE_STEP2,domain_name)
log.info("Domain %d suspended.", dominfo.getDomid())
dominfo.migrateDevices(network, dst,
DEV_MIGRATE_STEP3,domain_name)
#send signal to device model for save
if hvm:
log.info("release_devices for hvm domain")
dominfo._releaseDevices(True)
tochild.write("done\n")
tochild.flush()
log.debug('Written done')
and how many times does XC_SAVE synchronize with Handler, i read the
code , and just find only one time ,is it right?
3) and what is the function of the dominfo.migrateDevices with
DEV_MIGRATE_STEP2 and DEV_MIGRATE_STEP3, i read the code ,but still
confused, does it put the information of the devices into the
checkpoint file , or what?
4) and how does xen deal with the requests of devices in the ring and
gnttb and backend ,how does it store them? i have not find the code to
deal with it?
could you help me
Thanks in advance
Daniel Stodden 写道:
Hi.
On Fri, 2008-02-29 at 14:44 +0800, tgh wrote:
hi
I read checkpoint code
when checkpoint or migration ends,guestos continues processing by
returning back from hypercall of suspend, that is ,take_machine_down()
call the post_suspend() to continue ,is it right?
while in post_suspend(),pfn_to_mfn_frame_list_list[] is converted by
virt_to_mfn(),why do this convert? i could not find where it has been
converted,and why should it be converted back?
No, not converted. Re-initialized.
Please compare post_suspend() with the original initialization at system
boot in setup_arch() (arch/x/kernel/setup-xen.c). It should come clear
then.
Observe that this is not canonicalization, because it is not the p2m,
but a directory containing the *machine frames* *carrying* the p2m.
Since the memory underlying the p2m has changed after resume, that
directory needs a reset.
and in the xc_domain_restore()in the dom0,pagetable has been
uncanonicalized, which is coupled with canonicalization in
xc_domain_save(),is it ? ,and what is the reasons for
pfn_to_mfn_frame_list_list[] virt_to_mfn in post_suspend()?
could you help me
Canonicalization forth and back is done by the migration code. Keeping
the allocated frame list up to date is done by the domain itself. I do
agree that this can be confusing indeed.
hth,
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home