BTW, since we take the PMAP_LOCK() at the start of the function, I conclude that the interrupts are not disabled when pmap_fault_fixup() is called. Then I see nothing that would prevent the context switch to move the thread to other core, so sfence_vma() might occur on the core which does not have invalid translation cached.

In D18868#405977, @kib wrote:

BTW, since we take the PMAP_LOCK() at the start of the function, I conclude that the interrupts are not disabled when pmap_fault_fixup() is called. Then I see nothing that would prevent the context switch to move the thread to other core, so sfence_vma() might occur on the core which does not have invalid translation cached.

I believe you are right, but the only effect will be extra spurious faults.

Intel specifies that CPU always flushes TLB for the fault address, automatically. It might make sense to consider flushing TLB in the low level routine before enabling interrupts.

In D18868#406028, @kib wrote:

Intel specifies that CPU always flushes TLB for the fault address, automatically. It might make sense to consider flushing TLB in the low level routine before enabling interrupts.

You mean, change pmap_fault_fixup() to flush the TLB only after modifying the PTE, and unconditionally flush the TLB immediately after the trap to supervisor mode?

In D18868#406046, @markj wrote:

In D18868#406028, @kib wrote:

Intel specifies that CPU always flushes TLB for the fault address, automatically. It might make sense to consider flushing TLB in the low level routine before enabling interrupts.

You mean, change pmap_fault_fixup() to flush the TLB only after modifying the PTE, and unconditionally flush the TLB immediately after the trap to supervisor mode?

Yes, I mean flush TLB for the address after entering supervisor mode, before enabling interrupts. If done, do we need to flush TLB again in fixup() ? Perhaps formally yes, if the rules are that any address can be cached in TLB at any time, but practically even speculative execution only speculates over the existing code. While in the fault handler and trap()/fixup(), nothing should access the faulted address.

In D18868#406082, @kib wrote:

In D18868#406046, @markj wrote:

In D18868#406028, @kib wrote:

Intel specifies that CPU always flushes TLB for the fault address, automatically. It might make sense to consider flushing TLB in the low level routine before enabling interrupts.

You mean, change pmap_fault_fixup() to flush the TLB only after modifying the PTE, and unconditionally flush the TLB immediately after the trap to supervisor mode?

Yes, I mean flush TLB for the address after entering supervisor mode, before enabling interrupts. If done, do we need to flush TLB again in fixup() ? Perhaps formally yes, if the rules are that any address can be cached in TLB at any time, but practically even speculative execution only speculates over the existing code. While in the fault handler and trap()/fixup(), nothing should access the faulted address.

If the initial fault is not spurious (e.g., access/dirty bits are software-managed and PTE_A is not set on the PTE for the faulting address), then we must issue a sfence.vma after setting PTE_A. Thus it is not sufficient to flush the TLB upon entering supervisor mode.