could you reply in english, i could not read your letter Thanks clp@eclinso.com 写道:> Vielen Dank für Ihre Nachricht. > > Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre E-Mail ab dem 10-03-07 bearbeiten. > > In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er wird Ihnen gerne weiterhelfen. > > Sie erreichen Herrn Lüdi unter: > Phone +41 61 6666 406 > E-Mail fl@eclinso.com > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 2008-02-26 at 19:22 +0800, tgh wrote:> could you reply in english, i could not read your letterDon''t bother. Just an autoreply generated to tell you the guy is on vacation. Regarding your problem: There is not much you can do to get some sort execution traces enabled automatically. You probably want to enable debugging when building Xen and the libraries. Then maybe add a couple of debug-print statements to the code, whereever you see fit. I believe migration support in xend and libxc should be understandable in isolation. The tricky parts are definitely done in C. Last time I checked, xend mainly performed a single call to the tools and library. Also note that random instrumentation of all code executed for translating and mapping of the domU address space within the hypervisor would probably soon get more verbose than you asked for, since some of the functions involved can be called at a comparatively high frequency. Rule 1 when digging your way through complex systems: Divide and Conquer. Division comes first. Understand one thing at a time, starting at a comparatively high-level, then selectively dig deeper. regards, daniel> clp@eclinso.com 写道: > > Vielen Dank für Ihre Nachricht. > > > > Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre > E-Mail ab dem 10-03-07 bearbeiten. > > > > In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er > wird Ihnen gerne weiterhelfen. > > > > Sie erreichen Herrn Lüdi unter: > > Phone +41 61 6666 406 > > E-Mail fl@eclinso.com-- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
That was an automatic generated out-of-office mail in german language. It says, clp is not available until March 10th and in urgent cases, Mr. Fabio Luedl can help you out. On Tuesday 26 February 2008 12:22:40 tgh wrote:> could you reply in english, i could not read your letter > > Thanks > > clp@eclinso.com 写道: > > Vielen Dank für Ihre Nachricht. > > > > Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre E-Mail ab > > dem 10-03-07 bearbeiten. > > > > In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er wird > > Ihnen gerne weiterhelfen. > > > > Sie erreichen Herrn Lüdi unter: > > Phone +41 61 6666 406 > > E-Mail fl@eclinso.com > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/02/2008, Christoph Egger <Christoph.Egger@amd.com> wrote:> > That was an automatic generated out-of-office mail in german language. > It says, clp is not available until March 10th > and in urgent cases, Mr. Fabio Luedl can help you out.Too bad, i thought that was not new kind of Spam :(. Will have to use google transtlator next time before marking SPAMs. Thanks for Transalation. Cu, --Pradeep> > > > On Tuesday 26 February 2008 12:22:40 tgh wrote: > > could you reply in english, i could not read your letter > > > > Thanks > > > > clp@eclinso.com 写道: > > > Vielen Dank für Ihre Nachricht. > > > > > > Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre E-Mail ab > > > dem 10-03-07 bearbeiten. > > > > > > In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er wird > > > Ihnen gerne weiterhelfen. > > > > > > Sie erreichen Herrn Lüdi unter: > > > Phone +41 61 6666 406 > > > E-Mail fl@eclinso.com > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > > > > -- > AMD Saxony, Dresden, Germany > Operating System Research Center > > Legal Information: > AMD Saxony Limited Liability Company & Co. KG > Sitz (Geschäftsanschrift): > Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland > Registergericht Dresden: HRA 4896 > vertretungsberechtigter Komplementär: > AMD Saxony LLC (Sitz Wilmington, Delaware, USA) > Geschäftsführer der AMD Saxony LLC: > Dr. Hans-R. Deppe, Thomas McCoy > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >-- Pradeep Singh Rautela http://eagain.wordpress.com http://emptydomain.googlepages.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
hi thank you for your reply and i read the code of xc_save.c and xc_restore.c, which maybe do the function of VMsaving and VMrestoring, but i wander, if the code of xc_save.c and xc_restore.c is called by some python code or c code during migration or xm save and xm restore or not? the code of xc_save.c is a main function ,and is it called by other program to do migration or not ? and in the code of xc_save.c, there seem no notification to the xenstore or devbackend, and how are these VMdevbackends destroyed in the dom0, when migration or save? and in the code of xc_restore.c,there seems to be an existing VMdomain,and the whole data from savefile or from migration,will load into the VMdomain, is it？ then ,what code call these code of xc_save and xc_restore? i am confused could you help me out Thanks in advance Daniel Stodden 写道:> On Tue, 2008-02-26 at 19:22 +0800, tgh wrote: > >> could you reply in english, i could not read your letter >> > > Don''t bother. Just an autoreply generated to tell you the guy is on > vacation. > > Regarding your problem: There is not much you can do to get some sort > execution traces enabled automatically. You probably want to enable > debugging when building Xen and the libraries. Then maybe add a couple > of debug-print statements to the code, whereever you see fit. > > I believe migration support in xend and libxc should be understandable > in isolation. The tricky parts are definitely done in C. Last time I > checked, xend mainly performed a single call to the tools and library. > > Also note that random instrumentation of all code executed for > translating and mapping of the domU address space within the hypervisor > would probably soon get more verbose than you asked for, since some of > the functions involved can be called at a comparatively high frequency. > > Rule 1 when digging your way through complex systems: Divide and > Conquer. Division comes first. Understand one thing at a time, starting > at a comparatively high-level, then selectively dig deeper. > > regards, > daniel > > > >> clp@eclinso.com 写道: >> >>> Vielen Dank für Ihre Nachricht. >>> >>> Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre >>> >> E-Mail ab dem 10-03-07 bearbeiten. >> >>> In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er >>> >> wird Ihnen gerne weiterhelfen. >> >>> Sie erreichen Herrn Lüdi unter: >>> Phone +41 61 6666 406 >>> E-Mail fl@eclinso.com >>> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
I've had to trace through the migration code and made the following notes. Hope it helps: http://msun.bluespot.org/wiki/doku.php?id=xen_migration_notes On Wed, Feb 27, 2008 at 4:37 AM, tgh <wwwwww4187@sina.com.cn> wrote:> hi > thank you for your reply > and i read the code of xc_save.c and xc_restore.c, which maybe do the > function of VMsaving and VMrestoring, but i wander, if the code of > xc_save.c and xc_restore.c is called by some python code or c code > during migration or xm save and xm restore or not? the code of xc_save.c > is a main function ,and is it called by other program to do migration or > not ? > > and in the code of xc_save.c, there seem no notification to the > xenstore or devbackend, and how are these VMdevbackends destroyed in the > dom0, when migration or save? > and in the code of xc_restore.c,there seems to be an existing > VMdomain,and the whole data from savefile or from migration,will load > into the VMdomain, is it？ then ,what code call these code of xc_save > and xc_restore? i am confused > > could you help me out > > Thanks in advance > > > Daniel Stodden 写道: > > > > On Tue, 2008-02-26 at 19:22 +0800, tgh wrote: > > > >> could you reply in english, i could not read your letter > >> > > > > Don't bother. Just an autoreply generated to tell you the guy is on > > vacation. > > > > Regarding your problem: There is not much you can do to get some sort > > execution traces enabled automatically. You probably want to enable > > debugging when building Xen and the libraries. Then maybe add a couple > > of debug-print statements to the code, whereever you see fit. > > > > I believe migration support in xend and libxc should be understandable > > in isolation. The tricky parts are definitely done in C. Last time I > > checked, xend mainly performed a single call to the tools and library. > > > > Also note that random instrumentation of all code executed for > > translating and mapping of the domU address space within the hypervisor > > would probably soon get more verbose than you asked for, since some of > > the functions involved can be called at a comparatively high frequency. > > > > Rule 1 when digging your way through complex systems: Divide and > > Conquer. Division comes first. Understand one thing at a time, starting > > at a comparatively high-level, then selectively dig deeper. > > > > regards, > > daniel > > > > > > > >> clp@eclinso.com 写道: > >> > >>> Vielen Dank für Ihre Nachricht. > >>> > >>> Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre > >>> > >> E-Mail ab dem 10-03-07 bearbeiten. > >> > >>> In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er > >>> > >> wird Ihnen gerne weiterhelfen. > >> > >>> Sie erreichen Herrn Lüdi unter: > >>> Phone +41 61 6666 406 > >>> E-Mail fl@eclinso.com > >>> > > > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
hi
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
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?
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?
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Nice summary! In part 3, you have: ? What does that checkpoint flag do ? When that flag is set (through xm save -c), the domain resumes operation after the save operation. Normally "save" destroys the domain. You might be interested in my presentation at xen summit 4 about checkpointing, which goes into some detail about the save/migration process: http://xen.org/files/xensummit_4/talk_Cully.pdf Since then we''ve increased the speed of checkpointing considerably, but the code to do it isn''t in Xen yet. We have a paper about it in the next NSDI conference which has the details, if you''re interested. On Wednesday, 27 February 2008 at 14:23, Mike Sun wrote:> I''ve had to trace through the migration code and made the following > notes. Hope it helps: > > http://msun.bluespot.org/wiki/doku.php?id=xen_migration_notes > > On Wed, Feb 27, 2008 at 4:37 AM, tgh <wwwwww4187@sina.com.cn> wrote: > > hi > > thank you for your reply > > and i read the code of xc_save.c and xc_restore.c, which maybe do the > > function of VMsaving and VMrestoring, but i wander, if the code of > > xc_save.c and xc_restore.c is called by some python code or c code > > during migration or xm save and xm restore or not? the code of xc_save.c > > is a main function ,and is it called by other program to do migration or > > not ? > > > > and in the code of xc_save.c, there seem no notification to the > > xenstore or devbackend, and how are these VMdevbackends destroyed in the > > dom0, when migration or save? > > and in the code of xc_restore.c,there seems to be an existing > > VMdomain,and the whole data from savefile or from migration,will load > > into the VMdomain, is it？ then ,what code call these code of xc_save > > and xc_restore? i am confused > > > > could you help me out > > > > Thanks in advance > > > > > > Daniel Stodden 写道: > > > > > > > On Tue, 2008-02-26 at 19:22 +0800, tgh wrote: > > > > > >> could you reply in english, i could not read your letter > > >> > > > > > > Don''t bother. Just an autoreply generated to tell you the guy is on > > > vacation. > > > > > > Regarding your problem: There is not much you can do to get some sort > > > execution traces enabled automatically. You probably want to enable > > > debugging when building Xen and the libraries. Then maybe add a couple > > > of debug-print statements to the code, whereever you see fit. > > > > > > I believe migration support in xend and libxc should be understandable > > > in isolation. The tricky parts are definitely done in C. Last time I > > > checked, xend mainly performed a single call to the tools and library. > > > > > > Also note that random instrumentation of all code executed for > > > translating and mapping of the domU address space within the hypervisor > > > would probably soon get more verbose than you asked for, since some of > > > the functions involved can be called at a comparatively high frequency. > > > > > > Rule 1 when digging your way through complex systems: Divide and > > > Conquer. Division comes first. Understand one thing at a time, starting > > > at a comparatively high-level, then selectively dig deeper. > > > > > > regards, > > > daniel > > > > > > > > > > > >> clp@eclinso.com 写道: > > >> > > >>> Vielen Dank für Ihre Nachricht. > > >>> > > >>> Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre > > >>> > > >> E-Mail ab dem 10-03-07 bearbeiten. > > >> > > >>> In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er > > >>> > > >> wird Ihnen gerne weiterhelfen. > > >> > > >>> Sie erreichen Herrn Lüdi unter: > > >>> Phone +41 61 6666 406 > > >>> E-Mail fl@eclinso.com > > >>> > > > > > > > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > >> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Brendan, I'd be very interested to see your NSDI paper. Any way I could get a pre-print? We're actually looking ways of using COW memory to improve the speed of the checkpoints in our research. Thanks! Mike On Thu, Feb 28, 2008 at 1:52 PM, Brendan Cully <brendan@cs.ubc.ca> wrote:> Nice summary! > > In part 3, you have: > > ? What does that checkpoint flag do ? > > When that flag is set (through xm save -c), the domain resumes > operation after the save operation. Normally "save" destroys the > domain. > > You might be interested in my presentation at xen summit 4 about > checkpointing, which goes into some detail about the save/migration > process: > > http://xen.org/files/xensummit_4/talk_Cully.pdf > > Since then we've increased the speed of checkpointing considerably, > but the code to do it isn't in Xen yet. We have a paper about it in > the next NSDI conference which has the details, if you're interested. > > > > On Wednesday, 27 February 2008 at 14:23, Mike Sun wrote: > > I've had to trace through the migration code and made the following > > notes. Hope it helps: > > > > http://msun.bluespot.org/wiki/doku.php?id=xen_migration_notes > > > > On Wed, Feb 27, 2008 at 4:37 AM, tgh <wwwwww4187@sina.com.cn> wrote: > > > hi > > > thank you for your reply > > > and i read the code of xc_save.c and xc_restore.c, which maybe do the > > > function of VMsaving and VMrestoring, but i wander, if the code of > > > xc_save.c and xc_restore.c is called by some python code or c code > > > during migration or xm save and xm restore or not? the code of xc_save.c > > > is a main function ,and is it called by other program to do migration or > > > not ? > > > > > > and in the code of xc_save.c, there seem no notification to the > > > xenstore or devbackend, and how are these VMdevbackends destroyed in the > > > dom0, when migration or save? > > > and in the code of xc_restore.c,there seems to be an existing > > > VMdomain,and the whole data from savefile or from migration,will load > > > into the VMdomain, is it？ then ,what code call these code of xc_save > > > and xc_restore? i am confused > > > > > > could you help me out > > > > > > Thanks in advance > > > > > > > > > Daniel Stodden 写道: > > > > > > > > > > On Tue, 2008-02-26 at 19:22 +0800, tgh wrote: > > > > > > > >> could you reply in english, i could not read your letter > > > >> > > > > > > > > Don't bother. Just an autoreply generated to tell you the guy is on > > > > vacation. > > > > > > > > Regarding your problem: There is not much you can do to get some sort > > > > execution traces enabled automatically. You probably want to enable > > > > debugging when building Xen and the libraries. Then maybe add a couple > > > > of debug-print statements to the code, whereever you see fit. > > > > > > > > I believe migration support in xend and libxc should be understandable > > > > in isolation. The tricky parts are definitely done in C. Last time I > > > > checked, xend mainly performed a single call to the tools and library. > > > > > > > > Also note that random instrumentation of all code executed for > > > > translating and mapping of the domU address space within the hypervisor > > > > would probably soon get more verbose than you asked for, since some of > > > > the functions involved can be called at a comparatively high frequency. > > > > > > > > Rule 1 when digging your way through complex systems: Divide and > > > > Conquer. Division comes first. Understand one thing at a time, starting > > > > at a comparatively high-level, then selectively dig deeper. > > > > > > > > regards, > > > > daniel > > > > > > > > > > > > > > > >> clp@eclinso.com 写道: > > > >> > > > >>> Vielen Dank für Ihre Nachricht. > > > >>> > > > >>> Ich bin vom 22-02-08 bis 07-03-08 nicht im Hause und werde Ihre > > > >>> > > > >> E-Mail ab dem 10-03-07 bearbeiten. > > > >> > > > >>> In dringenden Fällen wenden Sie sich bitte an Herrn Fabio Lüdi, er > > > >>> > > > >> wird Ihnen gerne weiterhelfen. > > > >> > > > >>> Sie erreichen Herrn Lüdi unter: > > > >>> Phone +41 61 6666 406 > > > >>> E-Mail fl@eclinso.com > > > >>> > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? 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 thanks _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 meCanonicalization 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 -- Daniel Stodden LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation Institut für Informatik der TU München D-85748 Garching http://www.lrr.in.tum.de/~stodden mailto:stodden@cs.tum.edu PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com
http://lists.xensource.com/xen-devel
hi I try to understand the migration code ,and I guess ,during migration,there is a step to make some change to the network bridge, but which code does it ? could someone help me Thanks _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel