You should probably check the cpuid flag for the AMD's RAPL and decide whether you initialize it at all.

Again, I think this is dependent on the cpuid for thermal sensors.

Ah you have a circular dependency between the two functions can you move this definition to the top of the file.

This is already done for all system mode PMC's by the common infrastructure.

Ah I didn't realize you were checking if the counters exist in your add function that looks good, but still think we shouldn't add the class if there's no counters present.

I think amd and intel also have integrated gpu power reporting. Should be a couple extra lines if you look at on of the APU PPRs.

RAPL...

Shouldn't you depend on the GETCAPS call that I added to advertise different capabilities per counter?

Intel doesn't enumerate RAPL via CPUID. I think rdmsr_safe() of MSR_RAPL_POWER_UNIT is the best check here. That's now factored into pmc_rapl_present() helper used on AMD, called before the class slot is reserved

The common check in pmc_do_op_pmcallocate() is skipped when the security.bsd.unprivileged_syspmcs tunable is set. I did the check intentional so energy counters remain privileged even in this case

The class is already dropped on such hardware, pmc_rapl_initialize() returns ENXIO when no energy MSR responds

But all RAPL rows carry identical capabilities (PMC_CAP_READ|PMC_CAP_DOMWIDE), and rows whose MSR doesn't respond are never created

I can add a RAPL_ENERGY_GPU event now, but I have no hardware to test it. On AMD I couldn't find an MSR based GPU domain: From what I saw GPU power on APUs is reported via the SMU (linux amdgpu) rather than RAPL MSRs . Do you know some specific PPR ?

I suggest adding a mtx_assert(&rapl_alloc_mtx, MA_OWNED) assertion to rapl_guard_schedule.

I know it was copied from elsewhere, but please use these instead.

Does it need to be rdmsr_safe()? After all this code comes after pmc_rapl_present().

right, in fact using mtx_assert makes it consistent with the comment : )

You are right, it does not need to be rdmsr_safe ! Thanks for noticing it

Latest preferred formatting for the license header: https://docs.freebsd.org/en/articles/license-guide/

With your approval, I can make the above tweak when merging.

Sure, please go ahead! and sorry for the delay answer, for some reason I didn't see the email : )
Thanks!