xentrace_setmask badly broken?

xentrace_setmask badly broken?

[Dan Magenheimer]

[-- Attachment #1.1: Type: text/plain, Size: 726 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 1845 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: xentrace_setmask badly broken?

[Mark Williamson]

> 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!

Re: xentrace_setmask badly broken?

[Rob Gardner]

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

migration and restore?

[tgh]

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

Re: migration and restore?

[Andre Przywara]

> 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

Re: migration and restore?

[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


-- 
dns@somacoma.net

Wire up your home and stay there.

Re: migration and restore?

[tgh]

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
>
>
>   

failure about xc_save

[tgh]

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]#