[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] code read problems



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.