WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-tools

Re: [Xen-devel] Hi,something about the xentrace tool

* rickey berkeley <rickey.berkeley@xxxxxxxxx> [2006-06-11 08:18]:
> Hi folks:

Hi,

> from man page
>            "Where CPU is the processor number, TSC is the recordâ??s
> timestamp  (the
>            value  of the CPU cycle counter), EVENT is the event ID and
> D1...D5 are
>            the trace data."
> 
>            "Which correspond to the CPU number, event ID, timestamp counter
> and
>            the 5 data fields from the trace record.   There should be one
> such
>            rule for each type of event."
> 
> So I just wonder what does these kind of D1....D5 data mean.

This is referring to the fact that a trace record can have up to 5
fields.

> 
> I found the defined the d1-d5 structure in  xen/include/public/trace.h
> 59 /* This structure represents a single trace buffer record. */
> 60 struct t_rec {
> 61     uint64_t cycles;          /* cycle counter timestamp */
> 62     uint32_t event;           /* event ID                */
> 63     unsigned long data[5];    /* event data items        */
> 64 };
> 
> and defined a trace function in ./xen/common/trace.c
> 225 void trace(u32 event, unsigned long d1, unsigned long d2,
> 226            unsigned long d3, unsigned long d4, unsigned long d5)
> 227 {
> 
> But I still can't understand what are these data real meaning
>  I never found a place in the source code where this function void
> trace(...) had been called.

Search for TRACE_ , there are macros that wrap the proper call to trace
based on the number of fields that the trace record is using.

> Can someone give me a clue about this?
> Or are those interfaces (d1...d5) for developers to define their own
> interest to track the event?

Let's look at one of the trace macros:

xen/common/schedule.c:115

 TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);

 The trace id is TRC_SCHED_DOM_ADD, is defined in 
 xen/include/public/trace.h, which is 

#define TRC_SCHED_DOM_ADD       (TRC_SCHED +  1)
 
#define TRC_SCHED   0x0002f000    /* Xen Scheduler trace      */

 so TRC_SCHED_DOM_ADD is 0x0002f0001

The _2D means the trace record expects to inputs.  The trace
infrastructure supports up to 5 parameters, TRACE_5D.

The xentrace formatter needs to know how to unpack the trace record, you
can look at  the unpacking in tools/xentrace/formats , looking at the
TRC_SCHED_DOM_ADD (0x0002f001), we can see it is unpacked as:

0x0002f001  CPU%(cpu)d  %(tsc)d     sched_add_domain  [ domid =
0x%(1)08x, edomid = 0x%(2)08x ]

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@xxxxxxxxxx

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