Re: [Xen-devel] [PATCH v2 0/3] VPMU fixes

["Kleen, Andi" <andi.kleen@xxxxxxxxx>]

I'm not aware of that specific quirk on Nehalem. Standard perf has a workaround 
for the errata below, but it sounds different from what you have.

But if it's a NHM/WSM problem your model numbers are certainly not enough.

You always need some kind of limiter for the PMI because it is possible to 
program the PMU that PMIs/NMIs appear back-to-back and lock up the system. But 
just programming them to 1 is not enough in this case, really have to be 
limited (perf both accounts and limits the frequency in time and the total CPU 
consumption of the PMI).
I think if you have such a generic limiter it would likely be able to handle 
this issue too.

Comments of the Nehalem workaround in the main perf code:

* Workaround for:
 *   Intel Errata AAK100 (model 26)
 *   Intel Errata AAP53  (model 30)
 *   Intel Errata BD53   (model 44)
 *
 * The official story:
 *   These chips need to be 'reset' when adding counters by programming the
 *   magic three (non-counting) events 0x4300B5, 0x4300D2, and 0x4300B1 either
 *   in sequence on the same PMC or on different PMCs.
 *
 * In practise it appears some of these events do in fact count, and
 * we need to programm all 4 events.

         * The Errata requires below steps:
         * 1) Clear MSR_IA32_PEBS_ENABLE and MSR_CORE_PERF_GLOBAL_CTRL;
         * 2) Configure 4 PERFEVTSELx with the magic events and clear
         *    the corresponding PMCx;
         * 3) set bit0~bit3 of MSR_CORE_PERF_GLOBAL_CTRL;
         * 4) Clear MSR_CORE_PERF_GLOBAL_CTRL;
         * 5) Clear 4 pairs of ERFEVTSELx and PMCx;

-Andi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel