x86, perf: Add a separate Arch Perfmon v4 PMI handler

The Arch Perfmon v4 PMI handler is substantially different than
the older PMI handler. Instead of adding more and more ifs cleanly
fork the new handler into a new function, with the main common
code factored out into a common function.

Differences to the old handler:
- It relies on counter freezing, which eliminates several MSR
writes from the PMI handler and lowers the overhead significantly.

It makes the PMI handler more accurate, as all counters get
frozen atomically as soon as any counter overflows. So there is
much less counting of the PMI handler itself.

With the freezing we don't need to disable or enable counters or
PEBS. Only BTS which does not support auto-freezing still needs to
be explicitly managed.

- The PMU acking is done at the end, not the beginning.
This makes it possible to avoid manual enabling/disabling
of the PMU, instead we just rely on the freezing/acking.

With the new structure it is not possible to support looping
anymore (which very rarely happens anyways), so the looping
code is removed. There is also no stuck PMU detection,
but in this case the event would just be throttled quickly.

- The APIC is acked before reenabling the PMU, which avoids
problems with LBRs occasionally not getting unfreezed on Skylake.

This patch
- Adds code to enable v4 counter freezing
- Factors out common code of the PMI handler into a new function
- Fork <=v3 and >=v4 PMI handlers into separate functions.

Performance:

When profiling a kernel build on Skylake with different perf options,
measuring the length of all NMI handlers using the nmi handler
trace point:

(lower is better)

perf options    `           avg     max   delta
-c 100000                   445   31217   -53%  with freezing
-g -c 100000                966   33698   -44%  with freezing
--call-graph lbr -c 100000 2433   36930   -35%  with freezing
--c.g. dwarf -c 100000     1478   30491   -28%  with freezing

So the average cost of a NMI handler is cut down up to 53% with
freezing.

At least on this workload this makes -g competitive with the previous
non -g.

The max cost isn't really improved, since that is dominated by
other unrelated overhead.

Signed-off-by: Andi Kleen <ak@linux.intel.com>