| 9709 | } |
| 9710 | |
| 9711 | void |
| 9712 | pmap_activate(struct thread *td) |
| 9713 | { |
| 9714 | /* |
| 9715 | * invltlb_{invpcid,}_pcid_handler() is used to handle an |
| 9716 | * invalidate_all IPI, which checks for curpmap == |
| 9717 | * smp_tlb_pmap. The below sequence of operations has a |
| 9718 | * window where %CR3 is loaded with the new pmap's PML4 |
| 9719 | * address, but the curpmap value has not yet been updated. |
| 9720 | * This causes the invltlb IPI handler, which is called |
| 9721 | * between the updates, to execute as a NOP, which leaves |
| 9722 | * stale TLB entries. |
| 9723 | * |
| 9724 | * Note that the most common use of pmap_activate_sw(), from |
| 9725 | * a context switch, is immune to this race, because |
| 9726 | * interrupts are disabled (while the thread lock is owned), |
| 9727 | * so the IPI is delayed until after curpmap is updated. Protect |
| 9728 | * other callers in a similar way, by disabling interrupts |
| 9729 | * around the %cr3 register reload and curpmap assignment. |
| 9730 | */ |
| 9731 | spinlock_enter(); |
| 9732 | pmap_activate_sw(td); |
| 9733 | spinlock_exit(); |
| 9734 | } |
| 9735 | |
| 9736 | void |
| 9737 | pmap_activate_boot(pmap_t pmap) |
nothing calls this directly
no test coverage detected