On Wed, Jul 9, 2025 at 8:00 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Wed, Jul 09, 2025, Vishal Annapurve wrote: > > I think we can simplify the role of guest_memfd in line with discussion [1]: > > I genuinely don't understand what you're trying to "simplify". We need to define > an ABI that is flexible and robust, but beyond that most of these guidelines boil > down to "don't write bad code". My goal for bringing this discussion up is to see if we can better define the role of guest_memfd and how it interacts with other layers, as I see some scenarios that can be improved like kvm_gmem_populate[1] where guest_memfd is trying to fault in pages on behalf of KVM. [1] https://lore.kernel.org/lkml/20250703062641.3247-1-yan.y.zhao@xxxxxxxxx/ > > > 1) guest_memfd is a memory provider for userspace, KVM, IOMMU. > > No, guest_memfd is a memory provider for KVM guests. That memory *might* be > mapped by userspace and/or into IOMMU page tables in order out of functional > necessity, but guest_memfd exists solely to serve memory to KVM guests, full stop. I look at this as guest_memfd should serve memory to KVM guests and to other users by following some KVM/Arch related guidelines e.g. for CC VMs, guest_memfd can handle certain behavior differently. > > > 3) KVM should ideally associate the lifetime of backing > > pagetables/protection tables/RMP tables with the lifetime of the > > binding of memslots with guest_memfd. > > Again, please align your indentation. > > > - Today KVM SNP logic ties RMP table entry lifetimes with how > > long the folios are mapped in guest_memfd, which I think should be > > revisited. > > Why? Memslots are ephemeral per-"struct kvm" mappings. RMP entries and guest_memfd > inodes are tied to the Virtual Machine, not to the "struct kvm" instance. IIUC guest_memfd can only be accessed through the window of memslots and if there are no memslots I don't see the reason for memory still being associated with "virtual machine". Likely because I am yet to completely wrap my head around 'guest_memfd inodes are tied to the Virtual Machine, not to the "struct kvm" instance', I need to spend more time on this one. > > > Some very early thoughts on how guest_memfd could be laid out for the long term: > > 1) guest_memfd code ideally should be built-in to the kernel. > > Why? How is this at all relevant? If we need to bake some parts of guest_memfd > into the kernel in order to avoid nasty exports and/or ordering dependencies, then > we can do so. But that is 100% an implementation detail and in no way a design > goal. I agree, this is implementation detail and we need real code to discuss this better.
