Do you want to add macros for these constants? Identifying the E-cores will be useful even without this workaround, e.g. for the scheduler.

Perhaps add a short comment explaining what is being worked around here. Hopefully this workaround will be deleted soon, but it is worth describing.

pmap_invlpg(pmap_t pmap, vm_offset_t)
{
    if (pmap != kernel_pmap)
        return;
    ...
}

feels more intuitive. The compiler should be able to remove the branch in most callers.

Otherwise, it is not obvious to me what the "_pmap" suffix means.

The identification of small cores is recorded into pcpu data, so it is there. Still added constants.

Added a comment to pmap_invlpg().

Ok, I did it almost this way, but the function still needs to perform invalidation, so it cannot just return for !kernel_pmap.

pmap_quick_enter_page() doesn't set PG_G, so strictly speaking this case doesn't need to change.

pc_small_core?

pc_pcid_invlpg_bug would be more descriptive

"..., which results in the INVLPG instruction failing to flush all

Should have a description, something like Use INVPCID_CTXGLOB to work around small core INVLPG microarchitectural bug or Enable small core INVLPG workaround perhaps?

I wonder about the name too, maybe pcid_invlpg_workaround instead, or something like force_invpcid? pcid_invlpg_bug might give the impression that this is just reporting whether the bug is present, I think.

@markj, thoughts?

What is this line? I'm not sure what "lead" means here, and there is a closing comment delimiter without an opening delimiter. Fixing this macro and using in initializecpu() seems like a good idea though.

It is 'leaf'. And '*/' is ignored because the macro is not used.

This should be updated to match the sysctl name. More broadly, I would suggest updating the name of the local variable, use_invlpg_pmap, to be pcid_invlpg_workaround, and the same for the PCPU field's name.

I'm confused by this change. Specifically, this function is used when invpcid_works is false. Is that ever going to be the case on the broken cores? Moreover, if the change is required here, then I would also expect to see a similar change in invlrng_pcid_handler().

Because the virtual address being mapped here was dynamically allocated, I don't think that we should make the assumption that a stale TLB entry for vaddr didn't have PG_G set. So, I would use pmap_invlpg() here.

On an unrelated note, I don't understand why the invlpg is performed in pmap_quick_remove_page() instead of here. If the processor prefetches neighboring TLB entries to the one being accessed (as some have been reported to do), then the spin lock does not prevent the situation described in the "AMD64 Architecture Programmer's Manual Volume 2: System Programming" rev. 3.23, "7.3.1 Special Coherency Considerations".

Change "there" to "here". Also, the correctness of a simple invlpg depends on this virtual address being exclusively mapped by pmap_quick_enter_page(). If someplace else had created a mapping at qframe, then that other place might have included PG_G in the mapping, and we would have to uise pmap_invlpg() here:

"Since qframe is exclusively mapped by pmap_quick_enter_page() and that function doesn't set PG_G, we can use INVLPG here.

This is a partially (minimally) done attempt to keep code working even with invpcid_works manually set to zero. I reverted this change for now.

The change is added to the branch as a separate commit.