On Fri, Jul 31, 2026, Xiaoyao Li wrote: > On 7/29/2026 8:35 AM, Ackerley Tng via B4 Relay wrote: > > From: Sean Christopherson<[email protected]> > > > > Start plumbing in guest_memfd support for in-place private<=>shared > > conversions by tracking attributes via a maple tree. KVM currently tracks > > private vs. shared attributes on a per-VM basis, which made sense when a > > guest_memfd_only_ supported private memory, but tracking per-VM simply > > can't work for in-place conversions as the shared/private status of a given > > page needs to be per-gmem_inode, not per-VM. > > > > Use the filemap invalidation lock to protect the maple tree, as taking the > > lock for read when faulting in memory (for userspace or the guest) isn't > > expected to result in meaningful contention, and using a separate lock > > would add significant complexity (avoiding deadlock is quite difficult). > > > > Co-developed-by: Vishal Annapurve<[email protected]> > > Signed-off-by: Vishal Annapurve<[email protected]> > > Co-developed-by: Fuad Tabba<[email protected]> > > Signed-off-by: Fuad Tabba<[email protected]> > > Signed-off-by: Sean Christopherson<[email protected]> > > Tested-by: Shivank Garg<[email protected]> > > Co-developed-by: Ackerley Tng<[email protected]> > > Signed-off-by: Ackerley Tng<[email protected]> > > Reviewed-by: Xiaoyao Li <[email protected]> > > <...> > > > static __always_inline struct gmem_inode *GMEM_I(struct inode *inode) > > @@ -60,9 +68,25 @@ static pgoff_t kvm_gmem_get_index(struct kvm_memory_slot > > *slot, gfn_t gfn) > > return gfn - slot->base_gfn + slot->gmem.pgoff; > > } > > +static u64 kvm_gmem_interpret_entry(struct inode *inode, void *entry) > > Ummm, I'm not sure on the name. It doesn't look like KVM's style? > > Maybe, just kvm_gmem_get_attributes()?
+1000, "interpret_entry" is extremely vague.
