Looks fine, just one thing: io_space_map is actually quite expensive as synchronizing kernel address space requires an IPI and TLB flush. It'd be better to map it once and use the unload forward (see Echo.p for example) to unmap it on unload.

I noticed that RyzenSMU.p also seems to call io_space_map for each access, so I thought this usage pattern might be acceptable.

I also have another concern about mapping the whole MCHBAR region once. On Intel Comet Lake and earlier CPUs, the MCHBAR size is 64 KB or smaller, not 128 KB. If 128 KB is mapped unconditionally, it may map beyond the valid MCHBAR range on those platforms.

Would it be better to determine the actual MCHBAR size based on the CPU family/model, map only that range once, and then unmap it during unload?

I noticed that RyzenSMU.p also seems to call io_space_map for each access, so I thought this usage pattern might be acceptable.

That one should be updated at some point as well. The oldest PawnIO release had a bug where unload wouldn't get called, but that's quite irrelevant by now. It also does the whole page read in one go, so it's less likely to be spam-called by users.

Would it be better to determine the actual MCHBAR size based on the CPU family/model, map only that range once, and then unmap it during unload?

Yes

I have updated the PR according to your suggestion.
The module now maps the MCHBAR region once during initialization and unmaps it in the unload forward.

The MCHBAR size is selected based on the CPU family/model, instead of always mapping 128 KB:

32 KB for pre-IceLake microarchitectures
64 KB for IceLake through RocketLake
128 KB for TigerLake and newer

I also removed the server and some special-platform model entries for now, because I could not find public documentation for their MCHBAR register layout.

Tested on:

• Alder Lake (i7-12700)
• Tiger Lake (Xeon W-11955M)