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

[Ryan Harper <ryanh@xxxxxxxxxx>]

* 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