Re: [PATCH v9 01/41] KVM: guest_memfd: Introduce per-gmem attributes, use to guard user mappings
Ackerley Tng <[email protected]> Tue, 4 Aug 2026 06:46:20 -0700
| Newsgroups | gmane.linux.kernel,gmane.comp.emulators.kvm.devel,gmane.linux.documentation,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <CAEvNRgGJ4DQuOVafc8ipd8NGP+6y=dcwSZPGOjtrHBAGO7sB9g@mail.gmail.com> |
Sean Christopherson <[email protected]> writes: > 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. Was a little stuck with naming, my frame of mind was that "entry" is the attributes, so I can't get attributes from attributes. After you pointed this out, getting attributes out of an entry makes sense. Will rename to kvm_gmem_get_attributes().