[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Recent trace patch not arch-neutral


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Mon, 31 Oct 2005 14:32:05 -0800
  • Delivery-date: Mon, 31 Oct 2005 22:29:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcXeYrvzn+u/0749QG6KWctXqcALtgABg3TAAABKMXA=
  • Thread-topic: [Xen-devel] Recent trace patch not arch-neutral

> > A recent patch to trace.c uses a call to rdtscll() which is 
> > x86-specific.  Is there an arch-neutral call that can be used 
> > instead?  Or do arch's need to implement this?  (And if the 
> > latter, should we choose a more generic name?)
> 
> The tracebuffer code has always used the cycle counter, so if you've
> previously been compiling it for ia64 it must have previously 
> been using
> some more arch neutral way of accessing it...

OK, from the hg annotated manifest it appeared (on first
glance) to be recently added.

Still not positive, but I think Xen/ia64 was compiling but
never linking in trace.c because the call from dom0_ops.c
to tb_control was controlled by #ifdef TRACE_BUFFER,
that ifdef is now gone, and Xen/ia64 never turned it on.

Looking quickly over trace.c, all appears to be arch-neutral
except for the call to rdtscll(), so the questions remain...

Is there an arch-neutral call that can be used 
instead?  Or do arch's need to implement this?  (And if the 
latter, should we choose a more generic name?)

Dan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.