Re: [PATCH RFC 01/17] mm: shmem: Implement guest_memfd provider operations for tmpfs

[David Woodhouse]

On Fri, 2026-09-25 at 17:50 -0700, Ackerley Tng via B4 Relay wrote:
> 
> @@ -130,6 +131,9 @@ struct super_operations {
>  
>  	/* Report a filesystem error */
>  	void (*report_error)(const struct fserror_event *event);
> +#ifdef CONFIG_KVM_GUEST_MEMFD
> +	const struct guest_memfd_provider_operations *gmem_provider_ops;
> +#endif
>  };
>  
>  struct super_block {

I think I'd prefer the memory provider ops *not* to explicitly mention
KVM or guest_memfd. 

It is *just* a provider of memory. It manages its own address space,
and gives you the PFN (or folio, if you must) for a given range of its
address space on request. Perhaps with a 'nowait' flag to allow for
asynchronous operation (expecting its caller to try again without that
flag from a context where it *does* want to wait).

It will also want to manage *permissions* for that memory (read-only,
probably shared/private too?). And *revocation* when it wants a page
back.

The *consumers* of this memory provider API will include KVM/guestmemfd
and IOMMUFD. The latter *might* be through masquerading as dmabuf, or
IOMMUFD might treat memory providers as a first class citizen and be
taught to consume them directly.

But let's try to keep the interface, its implementations, and its
consumers cleanly separated.

Attachment: smime.p7s
Description: S/MIME cryptographic signature