On Fri, Feb 07, 2025 at 03:28:31PM +0100, Brendan Jackman wrote: > Hi Rik, > > On Thu, 6 Feb 2025 at 05:45, Rik van Riel <riel@xxxxxxxxxxx> wrote: > > This is done because some paravirt TLB flush implementations > > handle the TLB flush in the hypervisor, and will do the flush > > even when the target CPU has interrupts disabled. > > > > Always handle page table freeing with MMU_GATHER_RCU_TABLE_FREE. > > Using RCU synchronization between page table freeing and get_user_pages_fast() > > allows bare metal to also do TLB flushing while interrupts are disabled. > > > > Various places in the mm do still block IRQs or disable preemption > > as an implicit way to block RCU frees. > > > > That makes it safe to use INVLPGB on AMD CPUs. > > It would be nice to update the CONFIG_MMU_GATHER_RCU_TABLE_FREE > comment in mm/mmu_gather.c to mention INVLPG alongside "Architectures > that do not have this (PPC)" Why? This is just one more architecture that does broadcast. - and while that's being updated it would > also be useful to note down the paravirt thing you explained above, > IMO it's pretty helpful to have more examples of the concrete usecases > for this logic. Look at kvm_flush_tlb_multi() if you're interested. The notable detail is that is avoids flushing TLB for vCPUs that are preempted, and instead lets the vCPU resume code do the invalidate.
