bitkeeper revision 1.891.3.1 (40a107b0xATyR-Pt7aENgr5O6ydSyA)

Improvements to trace buffer features.

.rootkeys

@@ -112,6 +112,7 @@
 4054a2fdkdATEnRw-U7AUlgu-6JiUA tools/xend/setup.py
 4056cd26Qyp09iNoOjrvzg8KYzSqOw tools/xend/xend
 403a3edbrr8RE34gkbR40zep98SXbg tools/xentrace/Makefile
+40a107afN60pFdURgBv9KwEzgRl5mQ tools/xentrace/formats
 4050c413PhhLNAYk3TEwP37i_iLw9Q tools/xentrace/xentrace.8
 403a3edbVpV2E_wq1zeEkJ_n4Uu2eg tools/xentrace/xentrace.c
 403a3edb0lzD0Fojc-NYNoXr3SYrnA tools/xentrace/xentrace_cpusplit

docs/interface.tex

@@ -705,12 +705,16 @@ value of the CPU cycle-counter.  For builds without the trace buffer enabled,
 the macros expand to no-ops and thus can be left in place without incurring
 overheads.
 
-\subsection{Enabling tracing}
+\subsection{Trace-enabled builds}
 
 By default, the trace buffer is enabled only in debug builds (i.e. {\tt NDEBUG}
 is not defined).  It can be enabled separately by defining {\tt TRACE\_BUFFER},
 either in {\tt <xen/config.h>} or on the gcc command line.
 
+The size (in pages) of the per-CPU trace buffers can be specified using the
+{\tt tbuf_size=n } boot parameter to Xen.  If the size is set to 0, the trace
+buffers will be disabled.
+
 \subsection{Dumping trace data}
 
 When running a trace buffer build of Xen, trace data are written continuously
@@ -725,10 +729,11 @@ in overall chronological order.
 
 The output from {\tt xentrace} can be post-processed using {\tt
 xentrace\_cpusplit} (used to split trace data out into per-cpu log files) and
-{\tt xentrace\_format} (used to pretty-print trace data).
+{\tt xentrace\_format} (used to pretty-print trace data).  For the predefined
+trace points, there is an example format file in {\tt tools/xentrace/formats }.
 
-For more information, see the manual pages for {\tt xentrace},
-{\tt xentrace\_format} and {\tt xentrace\_cpusplit}.
+For more information, see the manual pages for {\tt xentrace}, {\tt
+xentrace\_format} and {\tt xentrace\_cpusplit}.
 
 
 \chapter{Hypervisor calls}

tools/xentrace/formats

@@ -0,0 +1,14 @@
+0x00010000	CPU%(cpu)d 0x%(tsc)x sched_add_domain(0x%(3)08x)            [ dom id = 0x%(1)08x%(2)08x   ]
+0x00010001	CPU%(cpu)d 0x%(tsc)x sched_rem_domain(0x%08(3)x)            [ dom id = 0x%(1)08x%(2)08x   ]
+0x00010002	CPU%(cpu)d 0x%(tsc)x __wake_up(0x%(3)08x)                   [ dom id = 0x%(1)08x%(2)08x   ]
+0x00010003	CPU%(cpu)d 0x%(tsc)x do_block()                             [ current = 0x%(2)08x         ]
+0x00010004	CPU%(cpu)d 0x%(tsc)x do_yield()		                    [ current = %(2)08x         ]
+0x00010005	CPU%(cpu)d 0x%(tsc)x do_set_timer_op(0x%(4)08x, 0x%(5)08x)  [ current = 0x%(3)08x ]
+0x00010006	CPU%(cpu)d 0x%(tsc)x sched_ctl(0x%(1)08x)
+0x00010007	CPU%(cpu)d 0x%(tsc)x sched_adjdom(params)                   [ dom id = 0x%(1)08x%(2)08x   ]
+0x00010008	CPU%(cpu)d 0x%(tsc)x __reschedule(0x%(3)08x)                [ dom id = 0x%(1)08x%(2)08x   ]
+0x00010009	CPU%(cpu)d 0x%(tsc)x switching to task_struct 0x%(1)08x     [ dom id = 0x%(1)08x     ]
+0x0001000A	CPU%(cpu)d 0x%(tsc)x s_timer_fn(unused)
+0x0001000B	CPU%(cpu)d 0x%(tsc)x t_timer_fn(unused)
+0x0001000C	CPU%(cpu)d 0x%(tsc)x dom_timer_fn(data)
+0x0001000D	CPU%(cpu)d 0x%(tsc)x fallback_timer_fn(unused)

tools/xentrace/xentrace_format

@@ -15,8 +15,10 @@ def usage():
 
           {event_id}{whitespace}{text format string}
 
-          The textual format string may include the format specifiers:
-            %(cpu)s, %(tsc), %(event)s, %(1)s, %(2)s, %(3)s, %(4)s, %(5)s
+          The textual format string may include format specifiers, such as:
+            %(cpu)d, %(tsc)d, %(event)d, %(1)d, %(2)d, %(3)d, %(4)d, %(5)d
+          [ the 'd' format specifier outputs in decimal, alternatively 'x'
+            will output in hexadecimal and 'o' will output in octal ]
 
           Which correspond to the CPU number, event ID, timestamp counter and
           the 5 data fields from the trace record.  There should be one such
@@ -34,7 +36,7 @@ def read_defs(defs_file):
     
     fd = open(defs_file)
 
-    reg = re.compile('(\d+)\s+(\S.*)')
+    reg = re.compile('(\S+)\s+(\S.*)')
 
     while True:
         line = fd.readline()
@@ -45,7 +47,7 @@ def read_defs(defs_file):
 
         if not m: print >> sys.stderr, "Bad format file" ; sys.exit(1)
         
-        defs[m.group(1)] = m.group(2)
+        defs[str(eval(m.group(1)))] = m.group(2)
 
     return defs
 
@@ -73,20 +75,20 @@ while not interrupted:
         line = sys.stdin.readline()
         if not line:
             break
-
+        
         m = reg.match(line)
 
         if not m: print >> sys.stderr, "Invalid input line."
 
         s = string.split(m.group(4))
 
-        args = {'cpu'   : m.group(1),
-                'tsc'   : m.group(2),
-                'event' : m.group(3) }
+        args = {'cpu'   : eval(m.group(1)),
+                'tsc'   : eval(m.group(2)),
+                'event' : eval(m.group(3)) }
 
-        i = 0
+        i = 1
         for item in s:
-            args[str(i)] = item
+            args[str(i)] = eval(item)
             i += 1
 
         if defs.has_key(m.group(3)): print defs[m.group(3)] % args

tools/xentrace/xentrace_format.1

@@ -1,4 +1,4 @@
-.TH XENTRACE_FORMAT 1 "11 March 2004" "Xen domain 0 utils"
+.TH XENTRACE_FORMAT 1 "11 May 2004" "Xen domain 0 utils"
 .SH NAME
 xentrace_format \- pretty-print Xen trace data
 .SH SYNOPSIS
@@ -18,14 +18,20 @@ The rules in \fIDEFS-FILE\fP should have the format shown below:
 
 Each rule should start on a new line.
 
-The format string may include the following format specifiers:
-%(cpu)s, %(tsc), %(event)s, %(1)s, %(2)s, %(3)s, %(4)s, %(5)s
+The format string may include format specifiers, such as:
+%(cpu)d, %(tsc)d, %(event)d, %(1)d, %(2)d, %(3)d, %(4)d, %(5)d
+
+[ the `d' format specifier output in decimal, alternatively `x'
+  will output in hexadecimal and `o' will output in octal ]
 
 These 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 to be pretty-printed (events which do not
 have formatting rules are ignored).
-          
+
+A sample format file for Xen's predefined trace events is available
+in the file tools/xentrace/formats in the Xen source tree.
+
 Depending on your system and the rate at which trace data is produced,
 this script may not be able to keep up with the output of
 \fBxentrace\fP if it is piped directly.  In these circumstances you

xen/arch/i386/setup.c

@@ -15,7 +15,6 @@
 #include <asm/desc.h>
 #include <asm/domain_page.h>
 #include <asm/pdb.h>
-#include <xen/trace.h>
 
 char ignore_irq13;		/* set if exception 16 works */
 struct cpuinfo_x86 boot_cpu_data = { 0, 0, 0, 0, -1, 1, 0, 0, -1 };
@@ -451,6 +450,4 @@ void __init start_of_day(void)
 #endif
 
     watchdog_on = 1;
-
-    init_trace_bufs();
 }

xen/common/kernel.c

@@ -31,6 +31,7 @@
 #include <xen/console.h>
 #include <xen/net_headers.h>
 #include <xen/serial.h>
+#include <xen/trace.h>
 
 kmem_cache_t *task_struct_cachep;
 
@@ -288,6 +289,8 @@ void cmain(unsigned long magic, multiboot_info_t *mbi)
     add_to_domain_alloc_list(__pa(frame_table) + frame_table_size,
                              dom0_memory_start);
 
+    init_trace_bufs();
+
     wake_up(new_dom);
 
     startup_cpu_idle_loop();

xen/common/trace.c

@@ -53,6 +53,7 @@ void init_trace_bufs(void)
     unsigned long nr_pages;
     char         *rawbuf;
     struct t_buf *buf;
+    struct task_struct *dom0;
     
     if ( opt_tbuf_size == 0 )
     {
@@ -69,10 +70,15 @@ void init_trace_bufs(void)
         return;
     }
 
-    /* share pages so that xentrace can map them */
+    /* Share pages so that xentrace can map them. */
+
+    dom0 = find_domain_by_id(0);
+
     for( i = 0; i < nr_pages; i++)
-        SHARE_PFN_WITH_DOMAIN(virt_to_page(rawbuf+(i*PAGE_SIZE)), 0);
+        SHARE_PFN_WITH_DOMAIN(virt_to_page(rawbuf+(i*PAGE_SIZE)), dom0);
     
+    put_task_struct(dom0);
+
     for ( i = 0; i < smp_num_cpus; i++ )
     {
         buf = t_bufs[i] = (struct t_buf *)&rawbuf[i*opt_tbuf_size*PAGE_SIZE];