Re: [patch v6 12/12] btrace, x86: disable on some processors

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: "Metzger, Markus T" <markus.t.metzger@intel.com>
> Date: Wed, 19 Dec 2012 16:11:41 +0000
> 
> > > LBR, BTM, or BTS records may have incorrect branch "from" information afer an
> > > EIST transition, T-states, C1E, or Adaptive Thermal Throttling (AAJ122).
> > >
> > > This results in sporadic test fails. Disable btrace on those processors.
> > >
> > > 2012-12-17 Markus Metzger <markus.t.metzger@intel.com>
> > >
> > > 	* common/linux-btrace.c (linux_supports_btrace): Add cpuid check.
> > 
> > I think this approach is a reasonable compromise.  However, AFAICT the
> > linux_supports_btrace() is called unconditionally.  Therefore this
> > will break GDB on old CPUs that don't implement the cpuid
> > instructions.  And AFAIK the family/model values are specific to
> > Intel, so you should check that you're on an Intel CPU before
> > interpreting these values.  And I still think you should check whether
> > the kernel supports BTS on the CPU you're running on first before
> > disabling it on certain CPUs.
> 
> This function is only called if the kernel provides a perf_event.h
> header file, which requires a recent enough kernel. Will a recent
> kernel run on those old cpu's that don't implement cpuid?

Linus decided only very recently to drop i386 support, starting with
the (yet to be realeased) 3.8.  And the i486 (which also lacks cpuid)
remains supported.

> In order to check whether the kernel supports BTS, I would need to
> enable tracing. Let's see if I can use the gdb or gdbserver process
> for this, since I don't necessarily have an inferior. If you think
> that it is necessary, I could try to add such a check.

I think it would make sense to do so.  Would probably solve the cpuid
issue as well, since you could assume that cpuid is supported if the
kernel actually supports BTS.  So do that check first and then only
disable it if you're running on a known-to-be-broken CPU.

> I added a vendor check.

Thanks,

Mark