I don't understand the subtraction here.

Should the second parameter logically be PMAP_PCID_KERN?

The parameter names should reflect how they are actually used.

We request the global invalidation, and do not request PCID-specific. So it should not be PMAP_PCID_KERN even formally, I believe.

The doc calls both rax and edx descriptors, unfortunately. And ecx is not a counter as such.

If you have suggestions I will apply it, for me the direct register names are easiest to match with the documentation.

How can cnt == 0 be true? va is not required to be page-aligned?

This is the maximum count of additional pages; since we subtract 1 below, from my reading of AMD's spec we can technically use cnt = invlpgb_maxcnt + 1 here.

I see, maybe va, desc, and count. But yes, the reader will have to look at invlpgb documentation to fully understand what is going on.

That was left from the previous invalid formula.

I initialized maxcnt by the cpuid val + 1.

Note the above two sysctl descr line styles.

Although it makes no functional difference, I would contend that NPTEPG is the correct constant here, as it represents the number of PTEs in a page table page referenced by a 2MB PDE.

I think multiplication by the same constant that we divided by above makes this easier to understand. I suspect that the compiler will implement this as a shift anyway.

Would it make sense to assert that this is true? I see there's such an assertion in smp_targeted_tlb_shootdown_native, but maybe one here would be good for documentary purposes?

Yes, indeed. The best place to do that is in fact sched_unpin(), and it is somewhat surprising that there is no such assert already. [The code calls sched_unpin() right after the tlbsync()]

D45736

Suppose addr1 = 0x800, addr2 = 0x1800. Then I'd expect this routine to invalidate translations for 0x0000 and 0x1000, but we have total = 1.

I suspect that ranged invalidation always get the aligned addresses, but fixed. Thanks.