On Tue, Nov 01, 2022, Oliver Upton wrote: > On Tue, Nov 01, 2022 at 08:28:04PM +0000, Sean Christopherson wrote: > > On Thu, Oct 27, 2022, Oliver Upton wrote: > > > There is no real urgency to free a stage-2 subtree that was pruned. > > > Nonetheless, KVM does the tear down in the stage-2 fault path while > > > holding the MMU lock. > > > > > [ copy ] > > > This is _very_ misleading. The above paints RCU as an optimization of sorts to > > avoid doing work while holding mmu_lock. Freeing page tables in an RCU callback > > is _required_ for correctness when allowing parallel page faults to remove page > > tables, as holding mmu_lock for read in that case doesn't ensure no other CPU is > > accessing and/or holds a reference to the to-be-freed page table. > > Agree, but it is still important to reason about what is changing here > too. Moving work out of the vCPU fault path _is_ valuable, though > ancillary to the correctness requirements. Sure, but that's at best a footnote. Similar to protecting freeing, RCU isn't the only option for moving work out of the vCPU fault path. In fact, it's probably one of the worst options because RCU callbacks run with soft IRQs disabled, i.e. doing _too_ much in a RCU callback is a real problem. If RCU weren't being used to protect readers, deferring freeing via a workqueue, kthread, etc... would work just as well, if not better. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
