linux-kernel - Re: [PATCH 3/5] perf, x86: Disable PEBS on clowertown chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1267825433.4997.14.camel@laptop>
Date:	Fri, 05 Mar 2010 22:43:53 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org, paulus@...ba.org,
	robert.richter@....com, fweisbec@...il.com,
	Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH 3/5] perf, x86: Disable PEBS on clowertown chips

On Fri, 2010-03-05 at 13:38 -0800, Stephane Eranian wrote:
> On Fri, Mar 5, 2010 at 1:35 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Fri, 2010-03-05 at 13:22 -0800, Stephane Eranian wrote:
> >> > The two serious ones, AJ106 and AJ68 are no fix and are listed as such
> >> > in all errata I can find, including the 7[23]00 series.
> >> >
> >> Not E74xx. I think it would be fine to drop LBR with PEBS as the work-around
> >> to AJ106.
> >>
> >> > I checked the 65nm Core2Duo, Xeon 5200 and Xeon 7[23]00 spec updates.
> >> > Going by that it seems the full model 15 family is broken and I'll leave
> >> > the patch as is.
> >>
> >> But the E74xx are okay and you are excluding them. Worst case you should
> >> provide an override.
> >
> > >From what I can tell E74xx is model 29, which would be just fine with
> > this patch, this patch only marks model 15 as broken.
> >
> True, my bad.
> So it would be a matter to provide some ways of disabling LBR with PEBS
> on model 15.

And some way of dealing with the flaky PEBS PMI, which requires we
program the pebs_event_reset thing otherwise there won't be a next PEBS
record to re-trigger the PMI.

If it would have stated it always did the threshold comparison first and
then the index increment, so that we'd always trigger on the second
record we could simply program half the period and always take two and
ignore the first, but it says _MAY_, so its a race and there's no
reliable solution.

It might all be possible but I don't see it being worth the effort.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/