From: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>
To: linux-coco@lists.linux.dev
Cc: "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org>,
Ackerley Tng <ackerleytng@google.com>,
Alex Williamson <alex@shazbot.org>,
David Woodhouse <dwmw2@infradead.org>,
David Hildenbrand <david@kernel.org>,
Jason Gunthorpe <jgg@nvidia.com>,
"Joerg Roedel (AMD)" <joro@8bytes.org>,
Kevin Tian <kevin.tian@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Robin Murphy <robin.murphy@arm.com>,
Sean Christopherson <seanjc@google.com>,
Alexey Kardashevskiy <aik@amd.com>,
Xu Yilun <yilun.xu@linux.intel.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Steven Price <steven.price@arm.com>,
Fred Griffoul <griffoul@gmail.com>,
iommu@lists.linux.dev, kvm@vger.kernel.org,
patches@lists.linux.dev
Subject: [RFC PATCH v4 20/25] vfio: Dispatch guest_memfd provider operations through the device file
Date: Wed, 4 Nov 2026 20:33:17 +0530 [thread overview]
Message-ID: <20261104150322.3516320-21-aneesh.kumar@kernel.org> (raw)
In-Reply-To: <20261104150322.3516320-1-aneesh.kumar@kernel.org>
Forward guest_memfd provider operations and the supplied device context
through the VFIO device file to the device driver. Validate the driver
callbacks before attachment. Keep a reference to the VFIO device file
until the driver's provider release callback returns, so the device and
driver operations remain available throughout cleanup.
Reject non-VFIO resource files and providers without device PFNs, whole-
range validation, mapping exclusion and release support. BAR
addresses are device PFNs rather than allocatable RAM folios; accepting
folio callbacks or incomplete exclusion callbacks would allow a backing
type that cannot honor device mapping and revocation rules. A driver
without this contract returns EOPNOTSUPP at attachment rather than
exposing its regions through a partial provider.
Cc: Alex Williamson <alex@shazbot.org>
Cc: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: kvm@vger.kernel.org
Cc: patches@lists.linux.dev
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
drivers/vfio/vfio_main.c | 108 +++++++++++++++++++++++++++++++++++++++
include/linux/vfio.h | 4 ++
2 files changed, 112 insertions(+)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index ff49f2fdb602..838242f82fd2 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -14,6 +14,7 @@
#include <linux/compat.h>
#include <linux/device.h>
#include <linux/fs.h>
+#include <linux/guest_memfd.h>
#include <linux/idr.h>
#include <linux/iommu.h>
#if IS_ENABLED(CONFIG_KVM)
@@ -248,6 +249,110 @@ struct vfio_device *_vfio_alloc_device(size_t size, struct device *dev,
}
EXPORT_SYMBOL_GPL(_vfio_alloc_device);
+#ifdef CONFIG_KVM_GUEST_MEMFD
+struct vfio_gmem_provider {
+ const struct guest_memfd_provider_operations *ops;
+ void *data;
+ struct file *file;
+};
+
+static void *vfio_gmem_provider_attach(struct inode *inode, struct file *file,
+ struct guest_memfd_device *gmem)
+{
+ const struct guest_memfd_provider_operations *ops;
+ struct vfio_gmem_provider *provider;
+ struct vfio_device_file *df;
+ void *data;
+
+ /* Reject other file types before interpreting their private_data. */
+ if (file->f_op != &vfio_device_fops || !gmem)
+ return ERR_PTR(-EOPNOTSUPP);
+
+ df = file->private_data;
+ ops = df->device->ops->gmem_provider_ops;
+ /* Every provider must support attachment and release. */
+ if (!ops || !ops->attach || !ops->release)
+ return ERR_PTR(-EOPNOTSUPP);
+
+ /* VFIO requires device PFNs, range validation and mapping exclusion. */
+ if (!ops->get_pfn || !ops->device_memory ||
+ !ops->prepare_memory_region ||
+ !ops->lock ||
+ !ops->unlock)
+ return ERR_PTR(-EOPNOTSUPP);
+
+ /* VFIO provides PFNs, not folios. */
+ if (ops->alloc_folio || ops->invalidate_folio)
+ return ERR_PTR(-EOPNOTSUPP);
+
+ provider = kzalloc_obj(*provider);
+ if (!provider)
+ return ERR_PTR(-ENOMEM);
+
+ data = ops->attach(inode, file, gmem);
+ if (IS_ERR(data)) {
+ kfree(provider);
+ return data;
+ }
+
+ provider->ops = ops;
+ provider->data = data;
+ /* Pin the driver operations through release(), including its return. */
+ provider->file = get_file(file);
+ return provider;
+}
+
+static void vfio_gmem_provider_release(void *data)
+{
+ struct vfio_gmem_provider *provider = data;
+
+ provider->ops->release(provider->data);
+ fput(provider->file);
+ kfree(provider);
+}
+
+static int vfio_gmem_provider_prepare_memory_region(void *data,
+ u64 offset, u64 size, u32 flags)
+{
+ struct vfio_gmem_provider *provider = data;
+
+ return provider->ops->prepare_memory_region(provider->data, offset,
+ size, flags);
+}
+
+static int vfio_gmem_provider_get_pfn(void *data, pgoff_t index,
+ unsigned long *pfn, int *max_order)
+{
+ struct vfio_gmem_provider *provider = data;
+
+ return provider->ops->get_pfn(provider->data, index, pfn, max_order);
+}
+
+static void vfio_gmem_provider_lock(void *context)
+{
+ struct vfio_gmem_provider *provider = context;
+
+ provider->ops->lock(provider->data);
+}
+
+static void vfio_gmem_provider_unlock(void *context)
+{
+ struct vfio_gmem_provider *provider = context;
+
+ provider->ops->unlock(provider->data);
+}
+
+static const struct guest_memfd_provider_operations vfio_gmem_provider_ops = {
+ .attach = vfio_gmem_provider_attach,
+ .release = vfio_gmem_provider_release,
+ .prepare_memory_region = vfio_gmem_provider_prepare_memory_region,
+ .lock = vfio_gmem_provider_lock,
+ .unlock = vfio_gmem_provider_unlock,
+ .get_pfn = vfio_gmem_provider_get_pfn,
+ .device_memory = true,
+};
+#endif
+
static int vfio_fs_init_fs_context(struct fs_context *fc)
{
return init_pseudo(fc, VFIO_MAGIC) ? 0 : -ENOMEM;
@@ -1449,6 +1554,9 @@ static void vfio_device_show_fdinfo(struct seq_file *m, struct file *filep)
#endif
const struct file_operations vfio_device_fops = {
+#ifdef CONFIG_KVM_GUEST_MEMFD
+ .gmem_provider_ops = &vfio_gmem_provider_ops,
+#endif
.owner = THIS_MODULE,
.open = vfio_device_fops_cdev_open,
.release = vfio_device_fops_release,
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 2436b8bd600a..10fd5015ce1d 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -88,6 +88,8 @@ struct vfio_device {
struct dentry *debug_root;
};
+struct guest_memfd_provider_operations;
+
/**
* struct vfio_device_ops - VFIO bus driver device callbacks
*
@@ -118,9 +120,11 @@ struct vfio_device {
* if none was provided.
* @dma_unmap: Called when userspace unmaps IOVA from the container
* this device is attached to.
+ * @gmem_provider_ops: Optional driver guest_memfd resource operations
* @device_feature: Optional, fill in the VFIO_DEVICE_FEATURE ioctl
*/
struct vfio_device_ops {
+ const struct guest_memfd_provider_operations *gmem_provider_ops;
char *name;
int (*init)(struct vfio_device *vdev);
void (*release)(struct vfio_device *vdev);
--
2.43.0
next prev parent reply other threads:[~2026-11-04 15:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 15:02 [RFC PATCH v4 00/25] KVM/VFIO: Add guest_memfd support for device MMIO Aneesh Kumar K.V (Arm)
2026-11-04 15:02 ` [RFC PATCH v4 01/25] KVM: guest_memfd: Let providers prepare memory regions Aneesh Kumar K.V (Arm)
2026-11-04 15:02 ` [RFC PATCH v4 02/25] KVM: guest_memfd: Dispatch conversion through backing operations Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 03/25] KVM: guest_memfd: Let providers coordinate mapping changes Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 04/25] KVM: guest_memfd: Dispatch revocation through backing operations Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 05/25] KVM: guest_memfd: Split population by backing type Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 06/25] KVM: guest_memfd: Support device-backed PFN providers Aneesh Kumar K.V (Arm)
2026-11-04 18:37 ` Fred Griffoul
2026-11-04 15:03 ` [RFC PATCH v4 07/25] KVM: guest_memfd: Support private/shared conversion of device memory Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 08/25] KVM: guest_memfd: Track private device ranges after attribute updates Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 09/25] KVM: guest_memfd: Support range revocation of device mappings Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 10/25] KVM: guest_memfd: Add shared device mmap through PFN providers Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 11/25] KVM: guest_memfd: Clear private device state on final close Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 12/25] KVM: guest_memfd: Invalidate mappings before memslot unbind Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 13/25] vfio: Track device use by guest_memfd Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 14/25] vfio/pci: Add helpers to check and serialize BAR state changes Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 15/25] vfio/pci: Check command enable changes before updating device state Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 16/25] vfio/pci: Check whether BAR state changes are allowed before reset Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 17/25] vfio/pci: Check low-power requests before updating device state Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 18/25] vfio/pci: Track userspace BAR mappings Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 19/25] vfio/pci: Restrict host BAR access for guest_memfd providers Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` Aneesh Kumar K.V (Arm) [this message]
2026-11-04 15:03 ` [RFC PATCH v4 21/25] vfio: Serialize guest_memfd attachment with device file operations Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 22/25] vfio/pci: Require D0 before providing guest_memfd BAR backing Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 23/25] iommufd: Support MMIO provider attachment to vDEVICEs Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 24/25] vfio/pci: Add a guest_memfd resource provider for MMIO BARs Aneesh Kumar K.V (Arm)
2026-11-04 15:03 ` [RFC PATCH v4 25/25] KVM: Document device-backed guest_memfd and VFIO usage Aneesh Kumar K.V (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261104150322.3516320-21-aneesh.kumar@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=ackerleytng@google.com \
--cc=aik@amd.com \
--cc=alex@shazbot.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dwmw2@infradead.org \
--cc=griffoul@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=patches@lists.linux.dev \
--cc=pbonzini@redhat.com \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=yilun.xu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.