On Tue, May 20, 2025 at 04:16:00PM -0700, Sean Christopherson wrote: > On Tue, May 20, 2025, Peter Xu wrote: > > On Fri, May 16, 2025 at 02:35:34PM -0700, Sean Christopherson wrote: > > > Sean Christopherson (6): > > > KVM: Bound the number of dirty ring entries in a single reset at > > > INT_MAX > > > KVM: Bail from the dirty ring reset flow if a signal is pending > > > KVM: Conditionally reschedule when resetting the dirty ring > > > KVM: Check for empty mask of harvested dirty ring entries in caller > > > KVM: Use mask of harvested dirty ring entries to coalesce dirty ring > > > resets > > > KVM: Assert that slots_lock is held when resetting per-vCPU dirty > > > rings > > > > For the last one, I'd think it's majorly because of the memslot accesses > > (or CONFIG_LOCKDEP=y should yell already on resets?). > > No? If KVM only needed to ensure stable memslot accesses, then SRCU would suffice. > It sounds like holding slots_lock may have been a somewhat unintentional, but the > reason KVM can't switch to SRCU is that doing so would break ordering, not because > slots_lock is needed to protect the memslot accesses. Hmm.. isn't what you said exactly means a "yes"? :) I mean, I would still expect lockdep to report this ioctl if without the slots_lock, please correct me if it's not the case. And if using RCU is not trivial (or not necessary either), so far the slots_lock is still required to make sure the memslot accesses are legal? -- Peter Xu
