hwpmc: consistently validate PMC class in allocation method

[mhorne]

Summary

It is always a good idea. In one case, attempting to allocate N+1 PMCs
from a class with N hardware counters would incorrectly attempt to
allocate from the next class in the list. Without this validation, this
can lead to all kinds of unexpected behaviour.

Since powerpc_allocate_pmc() is used by both the mpc7xxx and ppc970
classes, add a new global to track which is active (it will never be
both).

Test Plan

On my desktop with 8 programmable counters, calling pmcstat with 9 separate events will panic the system. With this patch, it will fail to allocate the 9th, as expected.

See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253687#c16

[mhorne]

Ping.

[luporl]

Worked fine on POWER9.
For PowerPC, without these changes the allocation of more programmable counters than available already failed, because of the check for the counter number in allocate. But, as you said, it is always a good idea to validate the PMC class too.

[mhorne]

In D31387#713971, @luporl wrote:

Worked fine on POWER9.
For PowerPC, without these changes the allocation of more programmable counters than available already failed, because of the check for the counter number in allocate. But, as you said, it is always a good idea to validate the PMC class too.

That's right, the issue described only affects platforms which register more than one hwpmc class (where pcd->pcd_num != md->pmd_npmc).