Suzuki K Poulose <[email protected]> writes: > On 10/08/2026 10:06, David Hildenbrand (Arm) wrote: >> On 8/7/26 23:52, Ackerley Tng via B4 Relay wrote: >>> From: Ackerley Tng <[email protected]> >>> >>> Before conversion, a guest_memfd could be either all shared, or all >> >> You mean "in-place conversion support" ? > > Not necessarily. This is supposed to be : > > "At creation, ... >
I've been thinking of this series as the conversions series hence this description, David is right about being more specific with "in-place conversion support". I didn't notice that it could also be understood as "at creation" vs later on in the guest_memfd lifecycle. I did intend it to be about in-place conversion support, since I was trying to justify why we need to zap both shared and private pages instead of zapping based on the INIT_SHARED flag. >> >>> private, configured at creation time using the INIT_SHARED flag. Hence, >>> when zapping pages from stage 2 page tables, guest_memfd can filter which >>> to zap based on the initial shared/private state. >>> >>> With conversion, guest_memfd tracks shared/private state on a per-page >> >> Same here. >> >>> level, so a range can contain both private and shared pages. Zap both >>> private and shared pages for simplicity. >>> >>> An alternative would be to iterate guest_memfd attributes and only zap both >>> if shared and private pages exist within the range. Setting both the shared >>> and private filters lets the zapping logic do that iteration instead. >> >> I mean, we just want to zap anything that belongs to guest_memfd, >> independent of >> shared vs. private, really? >> >> IOW, it's not about shared vs. private, but really about zapping anything >> that >> belongs to guest_memfd. > > Correct. But we want to control what we "zap" (invalidate range) when we > do the "conversion". e.g., if some ranges are already private, we don't > want to zap those pages, as they might have some data "populated" by the > VMM. For more context: > > https://lore.kernel.org/all/[email protected] > > Suzuki > > Looking again, there are actually 2 changes in this patch, 1. Zap both shared and private memory. 2. Allow zap requester to request what to zap by providing a filter. (2) is preparation for in-place conversions, where Suzuki pointed out that in the conversion process introduced with in-place conversions, guest_memfd should only request to zap memory that is not aligned with the requested outcome of the conversion in terms of shared/private state, to avoid over-zapping. e.g. for shared to private conversions, only zap shared memory, zapping private might destroy data. How about this, I can split this patch as follows: 1. Update this patch to just do (2) Commit subject: Allow zapping requester to provide range filter In the conversion process introduced with in-place conversions, guest_memfd should only request to zap memory that is not aligned with the requested outcome of the conversion in terms of shared/private state, to avoid over-zapping. Prepare for that by allowing zapping requester to provide range filter so the requester can zap private, shared or both types of pages. 2. In the next patch "Add base support for KVM_SET_MEMORY_ATTRIBUTES2", call kvm_gmem_invalidate_start() for conversions providing just KVM_FILTER_PRIVATE or KVM_FILTER_SHARED - no change to the next patch, mostly. 3. Add a simplification patch to always zap both PRIVATE and SHARED for the truncation, inode release and memory failure calls to kvm_gmem_invalidate_start() With guest_memfd in-place conversions, guest_memfd can iterate the maple tree to look up whether to zap PRIVATE, SHARED, or both based on the range being zapped, but I think that's doing extra work if the goal is to zap everything from guest_memfd. Before gmem it was an easy lookup to check the guest_memfd init time flag, but with conversions it requires iteration, and truncation/release/memory failure aren't particularly time sensitive. Sean, do you know if looking up attributes in gmem to feed the KVM MMU the smallest set of pages to zap will improve performance significantly? Or if there's any other reason to do this lookup (more complexity in gmem)? >> >> So, couldn't there just be a KVM_FILTER_GMEM thingy instead? >> >> But I didn't quite digest how these filters are used. >> >> I can see that kvm_gfn_range_filter_to_root_types() does some magic to them, >> but >> I am not a KVM MMU expert to know what KVM_MIRROR_ROOTS would mean. >>
