I was just looking at tools/xenmon/setmask.c which gets installed as /usr/sbin/xentrace_setmask. Am I confused or is this badly broken (both 3.1.x and 3.2)? Two problems: 1) Command line arguments to set the xentrace mask are completely ignored, and 2) The mask that IS always created and set is a bitwise-or of eight constants that are integers, not bitmasks, resulting in a mask which should be useless, except that the result -- either by accident or devious coding style -- comes out to be a reasonable value for a mask. Looks like this has been broken since the beginning of (its) time so no rush to fix it, but if someone would be so kind as to confirm I am not seeing things, I will work up a patch. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I was just looking at tools/xenmon/setmask.c which gets installed as > /usr/sbin/xentrace_setmask. > > Am I confused or is this badly broken (both 3.1.x and 3.2)? Two problems:It''s not actually functionally broken but it does have some issues.> 1) Command line arguments to set the xentrace mask are completely ignored,It looks like the tool just sets things up the way Xenmon needs them... This is fine but I wonder if it couldn''t just be rolled into the xenbaked? If it''s a necessary special-purpose tool for xenmon, it should probably be stashed away off the user''s path somewhere.> and 2) The mask that IS always created and set is a bitwise-or of eight > constants that are integers, not bitmasks, resulting in a mask which should > be useless, except that the result -- either by accident or devious coding > style -- comes out to be a reasonable value for a mask.The specific event within a (sub)class is identified by the low 12 bits of the event ID. These are just integers and are not suitable to be ORed. However... The Class and Subclass of the event are chosen from a set of values which are safe to be ORed together, and these are in the upper bits of the event ID. The result of this is that the OR in setmask.c actually will do the right thing, since the mask is really only concerned with class and subclass. So the code does actually do the right thing in terms of masking the correct (sub)classes. The test in line 376 of trace.c will sometimes not return when you''d really want it to, although I doubt that has much impact it''d still be nice to rule that out.> Looks like this has been broken since the beginning of (its) time so no > rush to fix it, but if someone would be so kind as to confirm I am not > seeing things, I will work up a patch.The code in setmask.c should probably be changed to be clearer: it works as-is but the intent would be much clearer if Class identifier were ORed rather than individual IDs. If my understanding is correct then this should work. Whilst you''re about it ;-) I suggest Xen ought to check the trace mask (i.e. low twelve bits should be zero). Maybe just reject an invalid mask with some appropriate error return? Happy New Year all! Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mark Williamson wrote:> 1) Command line arguments to set the xentrace mask are completely ignored, > > > It looks like the tool just sets things up the way Xenmon needs them... This > is fine but I wonder if it couldn''t just be rolled into the xenbaked? If > it''s a necessary special-purpose tool for xenmon, it should probably be > stashed away off the user''s path somewhere.As far as I can recall, Xenmon doesn''t explicitly rely on the trace mask. Its only use to xenmon is if too many trace events are generated, then you can use the trace mask to reduce the volume. But I think the xenmon related trace events are numbered more-or-less sequentially, so a mask isn''t very useful for picking which ones you''d like to see. But you can use the trace mask to turn off xenmon related events if you are just interested in vmx events, for instance. Rob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
hi i read the code of migration, and i fail to find the counterpart code of migration , which deal with the restoration of VM in the destination node, and i read the code of /tools/libxc/xc_domain_restore.c ,but the function of xc_domain_restore() seems not to be the one for the migration, it seems not support the restore of the iterative copy of the VM memory state ,is it? or how does it deal with the work? could someone give me a help Thanks in advance _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> i read the code of migration, and i fail to find the counterpart code of > migration , which deal with the restoration of VM in the destination > node, and i read the code of /tools/libxc/xc_domain_restore.c ,but the > function of xc_domain_restore() seems not to be the one for the > migration, it seems not support the restore of the iterative copy of the > VM memory state ,is it? or how does it deal with the work?Maybe the missing pieces you are looking for are in the xend (Python) code? In line 205 (or so) in tools/pyhton/xen/xend/XendDomainInfo.py you will find the high level function "restore". This method calls XendDomainInfo.resume (line 446) and triggers the necessary actions here. Another file to look in is XendCheckpoint.py, here you''ll find the method "restore" (line 154). Some Migration code is also in XendDomain.py. You can get more info if you enable debugging, do a live migration (to localhost) and look in xend.log for "Saving memory pages" or "Reloading memory pages". From here you will find the corresponding code (maybe by just grepping for the log message text). I found line 427 in xc_domain_restore.c, the code following this line deals with the restoring of the frames. From my perspective there is everything needed in there. Hope that helps! Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-84917 ----to satisfy European Law for business letters: AMD Saxony Limited Liability Company & Co. KG, Wilschdorfer Landstr. 101, 01109 Dresden, Germany Register Court Dresden: HRA 4896, General Partner authorized to represent: AMD Saxony LLC (Wilmington, Delaware, US) General Manager of 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 Tue, 2008-01-08 at 13:16 +0100, Andre Przywara wrote:> > i read the code of migration, and i fail to find the counterpart code of > > migration , which deal with the restoration of VM in the destination > > node, and i read the code of /tools/libxc/xc_domain_restore.c ,but the > > function of xc_domain_restore() seems not to be the one for the > > migration, it seems not support the restore of the iterative copy of the > > VM memory state ,is it? or how does it deal with the work? > > Maybe the missing pieces you are looking for are in the xend (Python) > code? In line 205 (or so) in tools/pyhton/xen/xend/XendDomainInfo.py you > will find the high level function "restore". This method calls > XendDomainInfo.resume (line 446) and triggers the necessary actions > here. Another file to look in is XendCheckpoint.py, here you''ll find the > method "restore" (line 154). Some Migration code is also in XendDomain.py. > You can get more info if you enable debugging, do a live migration (to > localhost) and look in xend.log for "Saving memory pages" or "Reloading > memory pages". From here you will find the corresponding code (maybe by > just grepping for the log message text). > I found line 427 in xc_domain_restore.c, the code following this line > deals with the restoring of the frames. From my perspective there is > everything needed in there.this is correct, the iteration is definitely done in xc_domain_restore(). the for loop as described above follows iteration as dictated by the source machine. each interation generates a number of batches, each batch comprising a number of pages, either first try or (later) resent due to being dirtied. each batch is dispatched in several passes. the second pass generates the machine frame list into which the batch is read. the most interesting part where that memory is mapped and filled with frame contents starts in line 533 (xc_map_foreign_range) and the subsequent for-loop in line 544 resp. complete enough to follow without the addtional setup done by xend. tools/xcutils/ contains C programs calling into the library for save and restore. should be easy to call from the command line once the parameter meanings are understood; i''d suggest to build with debug output enabled and follow the stderr messages to see how it works. regards, daniel -- dns@somacoma.net Wire up your home and stay there. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
thank both of you and how to debug python, i could debug c program with gdb ,and how to debug python program? and ,does the code of xc_domain_save.c and xc_domain_restore.c do the same job as the xend "xm save " and "xm restore"? and what are the valid parameter for it ? i look through the code ,it seems to be able to save VM in a live way ,and i try for some parameter , but failed , and how to do it? [root@vt-0 ~]# cd /root/xen-build-tree/xen-3.1.0-src/tools/xcutils/ [root@vt-0 xcutils]# ls Makefile readnotes.c xc_restore xc_restore.o xc_save.c readnotes readnotes.o xc_restore.c xc_save xc_save.o [root@vt-0 xcutils]# ./xc_save /tmp xc_save: usage: ./xc_save iofd domid maxit maxf flags [root@vt-0 xcutils]# ./xc_save /tmp/dom-1 dom-1 2 2 1 ERROR Internal error: Couldn''t map live_shinfo Warning - couldn''t disable shadow modeSave exit rc=1 [root@vt-0 xcutils]# ./xc_save /tmp/dom-1 dom-1 1 1 1 ERROR Internal error: Couldn''t map live_shinfo Warning - couldn''t disable shadow modeSave exit rc=1 [root@vt-0 xcutils]# ./xc_save /tmp/dom-1 dom-1 1 1 0 ERROR Internal error: Couldn''t map live_shinfo Save exit rc=1 [root@vt-0 xcutils]# Thanks Daniel Stodden 写道:> On Tue, 2008-01-08 at 13:16 +0100, Andre Przywara wrote: > >>> i read the code of migration, and i fail to find the counterpart code of >>> migration , which deal with the restoration of VM in the destination >>> node, and i read the code of /tools/libxc/xc_domain_restore.c ,but the >>> function of xc_domain_restore() seems not to be the one for the >>> migration, it seems not support the restore of the iterative copy of the >>> VM memory state ,is it? or how does it deal with the work? >>> >> Maybe the missing pieces you are looking for are in the xend (Python) >> code? In line 205 (or so) in tools/pyhton/xen/xend/XendDomainInfo.py you >> will find the high level function "restore". This method calls >> XendDomainInfo.resume (line 446) and triggers the necessary actions >> here. Another file to look in is XendCheckpoint.py, here you''ll find the >> method "restore" (line 154). Some Migration code is also in XendDomain.py. >> You can get more info if you enable debugging, do a live migration (to >> localhost) and look in xend.log for "Saving memory pages" or "Reloading >> memory pages". From here you will find the corresponding code (maybe by >> just grepping for the log message text). >> I found line 427 in xc_domain_restore.c, the code following this line >> deals with the restoring of the frames. From my perspective there is >> everything needed in there. >> > > this is correct, the iteration is definitely done in > xc_domain_restore(). > > the for loop as described above follows iteration as dictated by the > source machine. each interation generates a number of batches, each > batch comprising a number of pages, either first try or (later) resent > due to being dirtied. each batch is dispatched in several passes. the > second pass generates the machine frame list into which the batch is > read. the most interesting part where that memory is mapped and filled > with frame contents starts in line 533 (xc_map_foreign_range) and the > subsequent for-loop in line 544 resp. > > complete enough to follow without the addtional setup done by xend. > tools/xcutils/ contains C programs calling into the library for save and > restore. should be easy to call from the command line once the parameter > meanings are understood; i''d suggest to build with debug output enabled > and follow the stderr messages to see how it works. > > regards, > daniel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
hi I try to use the xc_save in the /tools/xcutils/xc_save ,but it could not work, what should i do , Thanks in xen-3.1.0 [root@amdvt01 ~]# cd /home/xen-3.1.0-src/tools/xcutils/ [root@amdvt01 xcutils]# ls Makefile readnotes.c xc_restore xc_restore.o xc_save.c readnotes readnotes.o xc_restore.c xc_save xc_save.o [root@amdvt01 xcutils]# ./xc_save /tmp/dom67 dom67 2 3 1 ERROR Internal error: Couldn''t map live_shinfo Warning - couldn''t disable shadow modeSave exit rc=1 [root@amdvt01 xcutils]# ./xc_save /tmp/dom67 dom67 2 3 0 ERROR Internal error: Couldn''t map live_shinfo Save exit rc=1 [root@amdvt01 xcutils]# ./xc_save /tmp/dom67 dom67 1 3 1 ERROR Internal error: Couldn''t map live_shinfo Warning - couldn''t disable shadow modeSave exit rc=1 [root@amdvt01 xcutils]# ./xc_save /tmp/dom67 dom67 1 3 15 ERROR Internal error: Couldn''t enable shadow mode Warning - couldn''t disable shadow modeSave exit rc=1 [root@amdvt01 xcutils]# and xen-3.0.3 [root@genode011 xcutils]# ./xc_save /tmp/dom3 dom3 2 2 1 Invalid state record -- pfn count out of range: 4294967295: 0 Warning - couldn''t disable shadow modeSave exit rc=1 [root@genode011 xcutils]# ./xc_save /tmp/dom3 dom3 2 2 0 Invalid state record -- pfn count out of range: 4294967295: 0 Save exit rc=1 [root@genode011 xcutils]# ./xc_save /tmp/dom3 dom3 1 2 0 Invalid state record -- pfn count out of range: 4294967295: 0 Save exit rc=1 [root@genode011 xcutils]# _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel