* [PATCH v5 11/20] vfio: Enforce preserved devices are retrieved via LIVEUPDATE_SESSION_RETRIEVE_FD
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
From: David Matlack <dmatlack@google.com>
Enforce that files for incoming (preserved by previous kernel) VFIO
devices are retrieved via LIVEUPDATE_SESSION_RETRIEVE_FD rather than by
opening the corresponding VFIO character device or via
VFIO_GROUP_GET_DEVICE_FD.
Both of these methods would result in VFIO initializing the device
without access to the preserved state of the device passed by the
previous kernel.
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Co-developed-by: Vipin Sharma <vipinsh@google.com>
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/device_cdev.c | 8 ++++++++
drivers/vfio/group.c | 9 +++++++++
drivers/vfio/pci/vfio_pci_liveupdate.c | 6 ++++++
drivers/vfio/vfio.h | 18 ++++++++++++++++++
4 files changed, 41 insertions(+)
diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
index 970932f22ecb..0050f0fe456b 100644
--- a/drivers/vfio/device_cdev.c
+++ b/drivers/vfio/device_cdev.c
@@ -49,6 +49,14 @@ static int vfio_device_cdev_open(struct vfio_device *device, struct file **filep
}
*filep = file;
+ } else if (vfio_liveupdate_incoming_is_preserved(device)) {
+ /*
+ * Since it is live update preserved device, it must be
+ * retrieved via LIVEUPDATE_SESSION_RETRIEVE_FD instead of
+ * opening /dev/vfio/devices/vfioX.
+ */
+ ret = -EBUSY;
+ goto err_free_device_file;
}
file->private_data = df;
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index b2299e5bc6df..62b4eaabc829 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -316,6 +316,15 @@ static int vfio_group_ioctl_get_device_fd(struct vfio_group *group,
if (IS_ERR(device))
return PTR_ERR(device);
+ /*
+ * This device was preserved across a Live Update. Accessing it via
+ * VFIO_GROUP_GET_DEVICE_FD is not allowed.
+ */
+ if (vfio_liveupdate_incoming_is_preserved(device)) {
+ vfio_device_put_registration(device);
+ return -EBUSY;
+ }
+
fd = FD_ADD(O_CLOEXEC, vfio_device_open_file(device));
if (fd < 0)
vfio_device_put_registration(device);
diff --git a/drivers/vfio/pci/vfio_pci_liveupdate.c b/drivers/vfio/pci/vfio_pci_liveupdate.c
index 4baac80d03f0..f0ea37d98696 100644
--- a/drivers/vfio/pci/vfio_pci_liveupdate.c
+++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
@@ -47,6 +47,12 @@
* ...
* ioctl(session_fd, LIVEUPDATE_SESSION_FINISH, ...);
*
+ * .. note::
+ * After kexec, if a device was preserved by the previous kernel, attempting
+ * to open a new file for the device via its character device
+ * (``/dev/vfio/devices/X``) or via ``VFIO_GROUP_GET_DEVICE_FD`` will fail
+ * with ``-EBUSY``.
+ *
* Restrictions
* ============
*
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index e4b72e79b7e3..496180950eb6 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -11,6 +11,7 @@
#include <linux/cdev.h>
#include <linux/module.h>
#include <linux/vfio.h>
+#include <linux/pci.h>
struct iommufd_ctx;
struct iommu_group;
@@ -461,4 +462,21 @@ static inline void vfio_device_debugfs_init(struct vfio_device *vdev) { }
static inline void vfio_device_debugfs_exit(struct vfio_device *vdev) { }
#endif /* CONFIG_VFIO_DEBUGFS */
+#ifdef CONFIG_VFIO_PCI_LIVEUPDATE
+static inline bool vfio_liveupdate_incoming_is_preserved(struct vfio_device *device)
+{
+ struct device *d = device->dev;
+
+ if (dev_is_pci(d))
+ return pci_liveupdate_is_incoming(to_pci_dev(d));
+
+ return false;
+}
+#else
+static inline bool vfio_liveupdate_incoming_is_preserved(struct vfio_device *device)
+{
+ return false;
+}
+#endif /* CONFIG_VFIO_PCI_LIVEUPDATE */
+
#endif
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 10/20] vfio/pci: Retrieve preserved device files after Live Update
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
Enable userspace to retrieve preserved VFIO device files from VFIO after
a Live Update by implementing the retrieve(), can_finish() and finish()
file handler callbacks.
During retrieve, find the VFIO device using the BDF and domain
information from the serialized state, and open it using the new
vfio_device_liveupdate_cdev_open() API.
Disallow Live Update to finish if userspace hasn't opened the file
successfully or any error occurred during retrieve.
Co-developed-by: David Matlack <dmatlack@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/pci/vfio_pci_liveupdate.c | 64 +++++++++++++++++++++++++-
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_liveupdate.c b/drivers/vfio/pci/vfio_pci_liveupdate.c
index e6eb7f6b53d7..4baac80d03f0 100644
--- a/drivers/vfio/pci/vfio_pci_liveupdate.c
+++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
@@ -39,7 +39,13 @@
* preserved, so there is no way for the file to be destroyed or the device
* to be unbound from the vfio-pci driver while it is preserved.
*
- * Retrieving the file after kexec is not yet supported.
+ * After kexec, the preserved VFIO device file can be retrieved from the session
+ * just like any other preserved file::
+ *
+ * ioctl(session_fd, LIVEUPDATE_SESSION_RETRIEVE_FD, &arg);
+ * device_fd = arg.fd;
+ * ...
+ * ioctl(session_fd, LIVEUPDATE_SESSION_FINISH, ...);
*
* Restrictions
* ============
@@ -93,6 +99,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/errno.h>
+#include <linux/file.h>
#include <linux/kexec_handover.h>
#include <linux/kho/abi/vfio_pci.h>
#include <linux/liveupdate.h>
@@ -223,13 +230,65 @@ static int vfio_pci_liveupdate_freeze(struct liveupdate_file_op_args *args)
return 0;
}
+static int match_device(struct device *dev, const void *arg)
+{
+ struct vfio_device *device = container_of(dev, struct vfio_device, device);
+ const struct vfio_pci_core_device_ser *ser = arg;
+ struct pci_dev *pdev;
+
+ pdev = dev_is_pci(device->dev) ? to_pci_dev(device->dev) : NULL;
+ if (!pdev)
+ return false;
+
+ return ser->bdf == pci_dev_id(pdev) && ser->domain == pci_domain_nr(pdev->bus);
+}
+
static int vfio_pci_liveupdate_retrieve(struct liveupdate_file_op_args *args)
{
- return -EOPNOTSUPP;
+ struct vfio_pci_core_device_ser *ser;
+ struct vfio_device *device;
+ struct file *file;
+ int ret = 0;
+
+ ser = phys_to_virt(args->serialized_data);
+
+ device = vfio_find_device(ser, match_device);
+ if (!device)
+ return -ENODEV;
+
+ file = vfio_device_liveupdate_cdev_open(device);
+ if (IS_ERR(file)) {
+ ret = PTR_ERR(file);
+ goto out;
+ }
+
+ args->file = file;
+out:
+ /* Drop the reference from vfio_find_device() */
+ vfio_device_put_registration(device);
+ return ret;
+
+}
+
+
+static bool vfio_pci_liveupdate_can_finish(struct liveupdate_file_op_args *args)
+{
+ struct vfio_device *device;
+
+ if (args->retrieve_status <= 0)
+ return false;
+
+ device = vfio_device_from_file(args->file);
+ guard(mutex)(&device->dev_set->lock);
+ return vfio_device_cdev_opened(device);
}
static void vfio_pci_liveupdate_finish(struct liveupdate_file_op_args *args)
{
+ struct vfio_device *device = vfio_device_from_file(args->file);
+
+ pci_liveupdate_finish(to_pci_dev(device->dev));
+ kho_restore_free(phys_to_virt(args->serialized_data));
}
static const struct liveupdate_file_ops vfio_pci_liveupdate_file_ops = {
@@ -238,6 +297,7 @@ static const struct liveupdate_file_ops vfio_pci_liveupdate_file_ops = {
.unpreserve = vfio_pci_liveupdate_unpreserve,
.freeze = vfio_pci_liveupdate_freeze,
.retrieve = vfio_pci_liveupdate_retrieve,
+ .can_finish = vfio_pci_liveupdate_can_finish,
.finish = vfio_pci_liveupdate_finish,
.owner = THIS_MODULE,
};
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 09/20] vfio: Add API to open cdev device for Live Update restore
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
During Live Update restore, VFIO PCI driver needs to recreate the device
file context that was preserved before kexec and return it to the user.
Provide an API for VFIO Live Update to get VFIO device file. Use an
anonymous inode when creating the file, since the retrieved device file
is not opened through any particular cdev inode, and the cdev inode does
not matter in practice.
Co-developed-by: David Matlack <dmatlack@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/device_cdev.c | 39 ++++++++++++++++++++++++++++++++++++--
include/linux/vfio.h | 9 +++++++++
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
index 2231423fe56d..970932f22ecb 100644
--- a/drivers/vfio/device_cdev.c
+++ b/drivers/vfio/device_cdev.c
@@ -2,6 +2,7 @@
/*
* Copyright (c) 2023 Intel Corporation.
*/
+#include <linux/anon_inodes.h>
#include <linux/vfio.h>
#include <linux/iommufd.h>
@@ -16,9 +17,10 @@ void vfio_init_device_cdev(struct vfio_device *device)
device->cdev.owner = THIS_MODULE;
}
-static int vfio_device_cdev_open(struct vfio_device *device, struct file *file)
+static int vfio_device_cdev_open(struct vfio_device *device, struct file **filep)
{
struct vfio_device_file *df;
+ struct file *file = *filep;
int ret;
/* Paired with the put in vfio_device_fops_release() */
@@ -31,6 +33,24 @@ static int vfio_device_cdev_open(struct vfio_device *device, struct file *file)
goto err_put_registration;
}
+ /*
+ * Simulate opening the character device using an anonymous inode. The
+ * returned file has the same properties as a cdev file (e.g. operations
+ * are blocked until BIND_IOMMUFD is called).
+ */
+ if (!file) {
+ file = anon_inode_getfile_fmode("[vfio-device-liveupdate]",
+ &vfio_device_fops, NULL,
+ O_RDWR, FMODE_PREAD | FMODE_PWRITE);
+
+ if (IS_ERR(file)) {
+ ret = PTR_ERR(file);
+ goto err_free_device_file;
+ }
+
+ *filep = file;
+ }
+
file->private_data = df;
/*
@@ -42,11 +62,26 @@ static int vfio_device_cdev_open(struct vfio_device *device, struct file *file)
return 0;
+err_free_device_file:
+ kfree(df);
err_put_registration:
vfio_device_put_registration(device);
return ret;
}
+struct file *vfio_device_liveupdate_cdev_open(struct vfio_device *device)
+{
+ struct file *file = NULL;
+ int ret;
+
+ ret = vfio_device_cdev_open(device, &file);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return file;
+}
+EXPORT_SYMBOL_GPL(vfio_device_liveupdate_cdev_open);
+
/*
* device access via the fd opened by this function is blocked until
* .open_device() is called successfully during BIND_IOMMUFD.
@@ -56,7 +91,7 @@ int vfio_device_fops_cdev_open(struct inode *inode, struct file *file)
struct vfio_device *device = container_of(inode->i_cdev,
struct vfio_device, cdev);
- return vfio_device_cdev_open(device, file);
+ return vfio_device_cdev_open(device, &file);
}
static void vfio_df_get_kvm_safe(struct vfio_device_file *df)
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 42c3a9ae3a85..b896c64b11da 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -430,6 +430,15 @@ int vfio_virqfd_enable(void *opaque, int (*handler)(void *, void *),
void vfio_virqfd_disable(struct virqfd **pvirqfd);
void vfio_virqfd_flush_thread(struct virqfd **pvirqfd);
+#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)
+struct file *vfio_device_liveupdate_cdev_open(struct vfio_device *device);
+#else
+static inline struct file *vfio_device_liveupdate_cdev_open(struct vfio_device *device)
+{
+ return ERR_PTR(-EOPNOTSUPP);
+}
+#endif /* IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV) */
+
struct vfio_device *vfio_find_device(const void *data, device_match_t match);
#endif /* VFIO_H */
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 08/20] vfio: Refactor vfio_device_fops_cdev_open()
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
Refactor vfio_device_fops_cdev_open() to use a static helper
vfio_device_cdev_open(). This helper will be used in subsequent
patches to support opening the device file during Live Update restore.
No functional change intended.
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/device_cdev.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
index 54abf312cf04..2231423fe56d 100644
--- a/drivers/vfio/device_cdev.c
+++ b/drivers/vfio/device_cdev.c
@@ -16,14 +16,8 @@ void vfio_init_device_cdev(struct vfio_device *device)
device->cdev.owner = THIS_MODULE;
}
-/*
- * device access via the fd opened by this function is blocked until
- * .open_device() is called successfully during BIND_IOMMUFD.
- */
-int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
+static int vfio_device_cdev_open(struct vfio_device *device, struct file *file)
{
- struct vfio_device *device = container_of(inode->i_cdev,
- struct vfio_device, cdev);
struct vfio_device_file *df;
int ret;
@@ -37,14 +31,14 @@ int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
goto err_put_registration;
}
- filep->private_data = df;
+ file->private_data = df;
/*
* Use the pseudo fs inode on the device to link all mmaps
* to the same address space, allowing us to unmap all vmas
* associated to this device using unmap_mapping_range().
*/
- filep->f_mapping = device->inode->i_mapping;
+ file->f_mapping = device->inode->i_mapping;
return 0;
@@ -53,6 +47,18 @@ int vfio_device_fops_cdev_open(struct inode *inode, struct file *filep)
return ret;
}
+/*
+ * device access via the fd opened by this function is blocked until
+ * .open_device() is called successfully during BIND_IOMMUFD.
+ */
+int vfio_device_fops_cdev_open(struct inode *inode, struct file *file)
+{
+ struct vfio_device *device = container_of(inode->i_cdev,
+ struct vfio_device, cdev);
+
+ return vfio_device_cdev_open(device, file);
+}
+
static void vfio_df_get_kvm_safe(struct vfio_device_file *df)
{
spin_lock(&df->kvm_ref_lock);
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 07/20] vfio: Introduce vfio_find_device() helper
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
Introduce vfio_find_device() to discover a registered vfio_device from
vfio_device_class matching user-provided criteria.
To ensure safe lifecycle handling, vfio_find_device() acquires a
registration reference (device->refcount) via
vfio_device_try_get_registration() rather than relying solely on
device.kref taken in class_find_device(). Holding only kref allows
vendor modules to unload while external callers hold device pointers,
leading to a kernel panic on release. Callers must release the device
via vfio_device_put_registration().
Additionally, move refcount_set() prior to vfio_device_add() in
__vfio_register_dev() so device->refcount is initialized before the
device is published to class lookups, avoiding registration data races.
On vfio_device_add() failure, the error path drops the initial
registration reference and waits for completion to drain any reference
taken by a concurrent lookup before returning the error to the driver.
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/vfio_main.c | 64 +++++++++++++++++++++++++++++++++++++---
include/linux/vfio.h | 2 ++
2 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 2437af031169..e91fd83dc58d 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -13,6 +13,7 @@
#include <linux/cdev.h>
#include <linux/compat.h>
#include <linux/device.h>
+#include <linux/device/class.h>
#include <linux/fs.h>
#include <linux/idr.h>
#include <linux/iommu.h>
@@ -359,17 +360,20 @@ static int __vfio_register_dev(struct vfio_device *device,
goto err_out;
}
- ret = vfio_device_add(device);
- if (ret)
- goto err_out;
-
/* Refcounting can't start until the driver calls register */
refcount_set(&device->refcount, 1);
+ ret = vfio_device_add(device);
+ if (ret)
+ goto err_add;
+
vfio_device_group_register(device);
vfio_device_debugfs_init(device);
return 0;
+err_add:
+ vfio_device_put_registration(device);
+ wait_for_completion(&device->comp);
err_out:
vfio_device_remove_group(device);
return ret;
@@ -1797,6 +1801,58 @@ int vfio_dma_rw(struct vfio_device *device, dma_addr_t iova, void *data,
}
EXPORT_SYMBOL(vfio_dma_rw);
+struct vfio_device_match_data {
+ const void *data;
+ device_match_t match;
+};
+
+static int vfio_device_match_fn(struct device *dev, const void *data)
+{
+ struct vfio_device *vdev = container_of(dev, struct vfio_device, device);
+ const struct vfio_device_match_data *mdata = data;
+
+ if (mdata->match(dev, mdata->data)) {
+ if (vfio_device_try_get_registration(vdev))
+ return 1;
+ }
+ return 0;
+}
+
+/**
+ * vfio_find_device - Find a registered VFIO device matching search criteria
+ * @data: Context data passed to the @match function
+ * @match: Device match callback function
+ *
+ * Finds a registered VFIO device in the vfio_device_class matching the search
+ * criteria specified by @match.
+ *
+ * On success, this function acquires a registration reference on the matched
+ * device via vfio_device_try_get_registration(). This pins the device and
+ * prevents its vendor driver module from unloading or unbinding while the
+ * reference is held.
+ *
+ * Return: Pointer to the matching vfio_device on success, or NULL if no
+ * matching device is found. The caller MUST release the acquired registration
+ * reference using vfio_device_put_registration() when finished with the device.
+ */
+struct vfio_device *vfio_find_device(const void *data, device_match_t match)
+{
+ struct vfio_device_match_data mdata = { .data = data, .match = match };
+ struct device *device;
+
+ device = class_find_device(&vfio_device_class, NULL, &mdata, vfio_device_match_fn);
+ if (!device)
+ return NULL;
+
+ /*
+ * Drop standard kref reference. Caller holds reference from
+ * vfio_device_try_get_registration().
+ */
+ put_device(device);
+ return container_of(device, struct vfio_device, device);
+}
+EXPORT_SYMBOL_GPL(vfio_find_device);
+
/*
* Module/class support
*/
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index cf0d941d0410..42c3a9ae3a85 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -430,4 +430,6 @@ int vfio_virqfd_enable(void *opaque, int (*handler)(void *, void *),
void vfio_virqfd_disable(struct virqfd **pvirqfd);
void vfio_virqfd_flush_thread(struct virqfd **pvirqfd);
+struct vfio_device *vfio_find_device(const void *data, device_match_t match);
+
#endif /* VFIO_H */
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 06/20] vfio/pci: Preserve vfio-pci device files across Live Update
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
Implement the Live Update file handler callbacks to preserve a vfio-pci
device across a Live Update. Subsequent commits will enable userspace to
then retrieve this file after the Live Update.
State about each device is serialized into a new ABI struct,
vfio_pci_core_device_ser. The contents of this struct are preserved
across the Live Update to the next kernel using a combination of
Kexec-Handover (KHO) to preserve the page(s) holding the struct, and
the Live Update Orchestrator (LUO) to preserve the physical address of
the struct.
For now, the only contents of struct vfio_pci_core_device_ser are the
device's PCI segment number and BDF, ensuring the device can be uniquely
identified after the Live Update.
Key design notes and constraints:
* Device state before kexec: Userspace is required to disable
interrupts on the device and ensure it is in the D0 power state.
This ensures the device does not send any interrupts until new
handlers are set up by the next kernel.
* Device reset during freeze: The device is reset and its state
is restored in the freeze() callback, ensuring the next kernel
receives it in a consistent state. Eventually, this will be
dropped so the device can be preserved in a running state, but
that requires further work in VFIO and the core PCI layer.
* FD usability after freeze: Once the device is frozen, the VFIO
device FD becomes unusable (i.e., ioctls and memory accesses will
return errors) because the device may have already been reset.
If the freeze operation fails, userspace must close the FD and
reinitialize the device.
* Lifecycle: LUO holds a reference to this file while it is preserved.
Therefore, VFIO is guaranteed that vfio_df_device_last_close() will
not be called on this device until userspace has unpreserved the
file via LUO.
Co-developed-by: David Matlack <dmatlack@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/pci/Kconfig | 2 +-
drivers/vfio/pci/vfio_pci_config.c | 3 +
drivers/vfio/pci/vfio_pci_core.c | 15 ++
drivers/vfio/pci/vfio_pci_liveupdate.c | 198 ++++++++++++++++++++++++-
drivers/vfio/pci/vfio_pci_priv.h | 9 ++
include/linux/kho/abi/vfio_pci.h | 15 ++
include/linux/vfio_pci_core.h | 3 +
7 files changed, 242 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index c12d614fc6c4..d97c809599fa 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -45,7 +45,7 @@ config VFIO_PCI_IGD
config VFIO_PCI_LIVEUPDATE
bool "VFIO PCI support for Live Update (EXPERIMENTAL)"
- depends on PCI_LIVEUPDATE
+ depends on PCI_LIVEUPDATE && VFIO_DEVICE_CDEV
help
Support for preserving devices bound to vfio-pci across a Live
Update. This option should only be enabled by developers working on
diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
index a10ed733f0e3..a51805515d30 100644
--- a/drivers/vfio/pci/vfio_pci_config.c
+++ b/drivers/vfio/pci/vfio_pci_config.c
@@ -406,6 +406,9 @@ bool __vfio_pci_memory_enabled(struct vfio_pci_core_device *vdev)
struct pci_dev *pdev = vdev->pdev;
u16 cmd = le16_to_cpu(*(__le16 *)&vdev->vconfig[PCI_COMMAND]);
+ if (vfio_pci_dev_is_frozen(vdev))
+ return false;
+
/*
* Memory region cannot be accessed if device power state is D3.
*
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index f31e59e5badb..c312b0eaf7d0 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -1087,6 +1087,9 @@ int vfio_pci_ioctl_get_region_info(struct vfio_device *core_vdev,
struct pci_dev *pdev = vdev->pdev;
int i, ret;
+ if (vfio_pci_dev_is_frozen(vdev))
+ return -EIO;
+
switch (info->index) {
case VFIO_PCI_CONFIG_REGION_INDEX:
info->offset = VFIO_PCI_INDEX_TO_OFFSET(info->index);
@@ -1513,6 +1516,9 @@ long vfio_pci_core_ioctl(struct vfio_device *core_vdev, unsigned int cmd,
container_of(core_vdev, struct vfio_pci_core_device, vdev);
void __user *uarg = (void __user *)arg;
+ if (vfio_pci_dev_is_frozen(vdev))
+ return -EIO;
+
switch (cmd) {
case VFIO_DEVICE_GET_INFO:
return vfio_pci_ioctl_get_info(vdev, uarg);
@@ -1567,6 +1573,9 @@ int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,
struct vfio_pci_core_device *vdev =
container_of(device, struct vfio_pci_core_device, vdev);
+ if (vfio_pci_dev_is_frozen(vdev))
+ return -EIO;
+
switch (flags & VFIO_DEVICE_FEATURE_MASK) {
case VFIO_DEVICE_FEATURE_LOW_POWER_ENTRY:
return vfio_pci_core_pm_entry(vdev, flags, arg, argsz);
@@ -1591,6 +1600,9 @@ static ssize_t vfio_pci_rw(struct vfio_pci_core_device *vdev, char __user *buf,
unsigned int index = VFIO_PCI_OFFSET_TO_INDEX(*ppos);
int ret;
+ if (vfio_pci_dev_is_frozen(vdev))
+ return -EIO;
+
if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions)
return -EINVAL;
@@ -1775,6 +1787,9 @@ int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma
u64 phys_len, req_len, pgoff, req_start;
void __iomem *bar_io;
+ if (vfio_pci_dev_is_frozen(vdev))
+ return -EIO;
+
index = vma->vm_pgoff >> (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT);
if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions)
diff --git a/drivers/vfio/pci/vfio_pci_liveupdate.c b/drivers/vfio/pci/vfio_pci_liveupdate.c
index 803528c9f1b2..e6eb7f6b53d7 100644
--- a/drivers/vfio/pci/vfio_pci_liveupdate.c
+++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
@@ -6,28 +6,221 @@
* David Matlack <dmatlack@google.com>
*/
+/**
+ * DOC: VFIO PCI Preservation via LUO
+ *
+ * VFIO PCI devices can be preserved over a kexec using the Live Update
+ * Orchestrator (LUO) file preservation. This allows userspace (such as a VMM)
+ * to transfer an in-use device to the next kernel.
+ *
+ * .. note::
+ * The support for preserving VFIO PCI devices is currently *partial* and
+ * should be considered *experimental*. It should only be used by developers
+ * working on expanding the support for the time being.
+ *
+ * To avoid accidental usage while the support is still experimental, this
+ * support is hidden behind a default-disable config option
+ * ``CONFIG_VFIO_PCI_LIVEUPDATE``. Once the kernel support has stabilized and
+ * become complete, this option will be enabled by default when
+ * ``CONFIG_VFIO_PCI`` and ``CONFIG_PCI_LIVEUPDATE`` are enabled.
+ *
+ * Usage Example
+ * =============
+ *
+ * VFIO PCI devices can be preserved across a kexec by preserving the file
+ * associated with the device in a LUO session::
+ *
+ * device_fd = open("/dev/vfio/devices/vfioX");
+ * ...
+ * ioctl(session_fd, LIVEUPDATE_SESSION_PRESERVE_FD, { ..., device_fd, ...});
+ *
+ * .. note::
+ * LUO will hold an extra reference to the device file for as long as it is
+ * preserved, so there is no way for the file to be destroyed or the device
+ * to be unbound from the vfio-pci driver while it is preserved.
+ *
+ * Retrieving the file after kexec is not yet supported.
+ *
+ * Restrictions
+ * ============
+ *
+ * The kernel imposes the following restrictions when preserving VFIO devices:
+ *
+ * * The device must be bound to the ``vfio-pci`` driver.
+ *
+ * * ``CONFIG_VFIO_PCI_ZDEV_KVM`` must not be enabled. This may be relaxed in
+ * the future.
+ *
+ * * The device must not be an Intel display device. This may be relaxed in
+ * the future.
+ *
+ * * The device file descriptor must be obtained by opening the VFIO character
+ * device (``/dev/vfio/devices/vfioX``) and not via
+ * ``VFIO_GROUP_GET_DEVICE_FD``.
+ *
+ * * The device must meet following conditions prior to kexec without which the
+ * ``reboot(LINUX_REBOOT_CMD_KEXEC)`` syscall (to initiate the kexec) will
+ * fail.
+ *
+ * - The device must have interrupt disabled.
+ * - The device must be in D0 state.
+ *
+ * In addition, the device must meet all of the restrictions imposed by the
+ * core PCI layer documented at :doc:`/PCI/liveupdate`.
+ *
+ * Preservation Behavior
+ * =====================
+ *
+ * The eventual goal of this support is to avoid disrupting the workload, state,
+ * or configuration of each preserved device during a Live Update. This would
+ * include allowing the device to perform DMA to preserved memory buffers and
+ * perform P2P DMA to other preserved devices. However, there are many pieces
+ * that still need to land in the kernel.
+ *
+ * For now, VFIO only preserves the following state for devices:
+ *
+ * * The PCI Segment, Bus, Device, and Function numbers of the device. The
+ * kernel guarantees the these will not change across a kexec when a device
+ * is preserved.
+ *
+ * Since the kernel is not yet prepared to preserve all parts of the device and
+ * its dependencies (such as DMA mappings), VFIO currently resets and restores
+ * preserved devices back into an idle state during kexec, before handing off
+ * control to the next kernel. This will be relaxed in future versions of the
+ * kernel once it is safe to allow the device to keep running across kexec.
+ */
+
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/errno.h>
+#include <linux/kexec_handover.h>
#include <linux/kho/abi/vfio_pci.h>
#include <linux/liveupdate.h>
#include <linux/module.h>
+#include <linux/vfio.h>
#include "vfio_pci_priv.h"
static bool vfio_pci_liveupdate_can_preserve(struct liveupdate_file_handler *handler,
struct file *file)
{
- return false;
+ struct vfio_device *device = vfio_device_from_file(file);
+ struct vfio_pci_core_device *vdev;
+ struct pci_dev *pdev;
+
+ if (!device)
+ return false;
+
+ /* Live Update support is limited to cdev files. */
+ if (!vfio_device_cdev_opened(device))
+ return false;
+
+ if (device->ops != &vfio_pci_ops)
+ return false;
+
+ vdev = container_of(device, struct vfio_pci_core_device, vdev);
+ pdev = vdev->pdev;
+
+ /*
+ * Don't support specialized vfio-pci devices for now since they haven't
+ * been tested.
+ */
+ if (IS_ENABLED(CONFIG_VFIO_PCI_ZDEV_KVM) || vfio_pci_is_intel_display(pdev))
+ return false;
+
+ /* Only non-VFs are supported for now. */
+ if (pdev->is_virtfn)
+ return false;
+
+ return true;
}
static int vfio_pci_liveupdate_preserve(struct liveupdate_file_op_args *args)
{
- return -EOPNOTSUPP;
+ struct vfio_device *device = vfio_device_from_file(args->file);
+ struct vfio_pci_core_device_ser *ser;
+ struct vfio_pci_core_device *vdev;
+ struct pci_dev *pdev;
+ int ret;
+
+ vdev = container_of(device, struct vfio_pci_core_device, vdev);
+ pdev = vdev->pdev;
+
+ ret = pci_liveupdate_preserve(pdev);
+ if (ret)
+ return ret;
+
+ ser = kho_alloc_preserve(sizeof(*ser));
+ if (IS_ERR(ser)) {
+ ret = PTR_ERR(ser);
+ goto err_unpreserve;
+ }
+
+ ser->bdf = pci_dev_id(pdev);
+ ser->domain = pci_domain_nr(pdev->bus);
+
+ args->serialized_data = virt_to_phys(ser);
+ return 0;
+
+err_unpreserve:
+ pci_liveupdate_unpreserve(pdev);
+ return ret;
}
static void vfio_pci_liveupdate_unpreserve(struct liveupdate_file_op_args *args)
{
+ struct vfio_device *device = vfio_device_from_file(args->file);
+
+ pci_liveupdate_unpreserve(to_pci_dev(device->dev));
+ kho_unpreserve_free(phys_to_virt(args->serialized_data));
+}
+
+static int vfio_pci_liveupdate_freeze(struct liveupdate_file_op_args *args)
+{
+ struct vfio_device *device = vfio_device_from_file(args->file);
+ struct vfio_pci_core_device *vdev;
+ struct pci_dev *pdev;
+
+ vdev = container_of(device, struct vfio_pci_core_device, vdev);
+ pdev = vdev->pdev;
+
+ guard(mutex)(&device->dev_set->lock);
+ guard(mutex)(&vdev->igate);
+ guard(rwsem_write)(&vdev->memory_lock);
+
+ /*
+ * Userspace must disable interrupts on the device prior to freeze so
+ * that the device does not send any interrupts until new interrupt
+ * handlers have been established by the next kernel.
+ */
+ if (vdev->irq_type != VFIO_PCI_NUM_IRQS) {
+ pci_err(pdev, "Freeze failed! Interrupts are still enabled.\n");
+ return -EINVAL;
+ }
+
+ if (pdev->current_state != PCI_D0) {
+ pci_err(pdev, "Freeze failed! Device not in D0 state.\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Reset is a temporary measure to provide kernel after kexec a clean
+ * device while VFIO live update work is under development and not
+ * fully supported. It will go away once continuous DMA support is
+ * added to device preservation.
+ */
+ vfio_pci_zap_bars(vdev);
+ vfio_pci_dma_buf_move(vdev, true);
+ vfio_pci_core_try_reset(vdev);
+ pci_write_config_word(pdev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);
+ /*
+ * Userspace cannot use the FD correctly now irrespective of liveupdate
+ * freeze failing or succeeding. They will have to reinitialize the VFIO
+ * device to continue using it as reset might have loaded default PCI
+ * state. Disable ioctl, read, write and mmap access to the device.
+ */
+ smp_store_release(&vdev->liveupdate_frozen, true);
+ return 0;
}
static int vfio_pci_liveupdate_retrieve(struct liveupdate_file_op_args *args)
@@ -43,6 +236,7 @@ static const struct liveupdate_file_ops vfio_pci_liveupdate_file_ops = {
.can_preserve = vfio_pci_liveupdate_can_preserve,
.preserve = vfio_pci_liveupdate_preserve,
.unpreserve = vfio_pci_liveupdate_unpreserve,
+ .freeze = vfio_pci_liveupdate_freeze,
.retrieve = vfio_pci_liveupdate_retrieve,
.finish = vfio_pci_liveupdate_finish,
.owner = THIS_MODULE,
diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h
index 5d2ad128523d..4b65753e8936 100644
--- a/drivers/vfio/pci/vfio_pci_priv.h
+++ b/drivers/vfio/pci/vfio_pci_priv.h
@@ -145,6 +145,11 @@ static inline void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev,
#ifdef CONFIG_VFIO_PCI_LIVEUPDATE
int __init vfio_pci_liveupdate_init(void);
void vfio_pci_liveupdate_cleanup(void);
+static inline bool vfio_pci_dev_is_frozen(struct vfio_pci_core_device *vdev)
+{
+ /* Written in VFIO PCI Liveupdate during freeze() event */
+ return smp_load_acquire(&vdev->liveupdate_frozen);
+}
#else
static inline int vfio_pci_liveupdate_init(void)
{
@@ -154,6 +159,10 @@ static inline int vfio_pci_liveupdate_init(void)
static inline void vfio_pci_liveupdate_cleanup(void)
{
}
+static inline bool vfio_pci_dev_is_frozen(struct vfio_pci_core_device *vdev)
+{
+ return false;
+}
#endif /* CONFIG_VFIO_PCI_LIVEUPDATE */
#endif
diff --git a/include/linux/kho/abi/vfio_pci.h b/include/linux/kho/abi/vfio_pci.h
index 67e8199eec59..229a13ac1e52 100644
--- a/include/linux/kho/abi/vfio_pci.h
+++ b/include/linux/kho/abi/vfio_pci.h
@@ -9,6 +9,9 @@
#ifndef _LINUX_LIVEUPDATE_ABI_VFIO_PCI_H
#define _LINUX_LIVEUPDATE_ABI_VFIO_PCI_H
+#include <linux/compiler.h>
+#include <linux/types.h>
+
/**
* DOC: VFIO PCI Live Update ABI
*
@@ -25,4 +28,16 @@
#define VFIO_PCI_LUO_FH_COMPATIBLE "vfio-pci-v1"
+/**
+ * struct vfio_pci_core_device_ser - Serialized state of a single VFIO PCI
+ * device.
+ *
+ * @domain: The device's PCI domain number (segment).
+ * @bdf: The device's PCI bus, device, and function number.
+ */
+struct vfio_pci_core_device_ser {
+ u32 domain;
+ u16 bdf;
+} __packed;
+
#endif /* _LINUX_LIVEUPDATE_ABI_VFIO_PCI_H */
diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
index 5fc6ce4dd786..adc5d05456bd 100644
--- a/include/linux/vfio_pci_core.h
+++ b/include/linux/vfio_pci_core.h
@@ -143,6 +143,9 @@ struct vfio_pci_core_device {
struct notifier_block nb;
struct rw_semaphore memory_lock;
struct list_head dmabufs;
+#ifdef CONFIG_VFIO_PCI_LIVEUPDATE
+ bool liveupdate_frozen;
+#endif
};
enum vfio_pci_io_width {
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 05/20] vfio/pci: Register a file handler with Live Update Orchestrator
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
Register a live update file handler for vfio-pci device files. Add stub
implementations of all required callbacks so that registration does not
fail (i.e. to avoid breaking git-bisect). Register it with both live
update framework and PCI subsystem.
This file handler will be extended in subsequent commits to enable a
device bound to vfio-pci to run without interruption while the host is
going through a kexec Live Update.
Put this support behind a new Kconfig VFIO_PCI_LIVEUPDATE that is marked
experimental and default-disabled until more of the device preservation
support has landed in the kernel.
Co-developed-by: David Matlack <dmatlack@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
MAINTAINERS | 1 +
drivers/vfio/pci/Kconfig | 12 ++++
drivers/vfio/pci/Makefile | 1 +
drivers/vfio/pci/vfio_pci.c | 11 +++-
drivers/vfio/pci/vfio_pci_liveupdate.c | 80 ++++++++++++++++++++++++++
drivers/vfio/pci/vfio_pci_priv.h | 14 +++++
include/linux/kho/abi/vfio_pci.h | 28 +++++++++
7 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 drivers/vfio/pci/vfio_pci_liveupdate.c
create mode 100644 include/linux/kho/abi/vfio_pci.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 347c435ca404..77a35742de0a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -28329,6 +28329,7 @@ F: Documentation/ABI/testing/debugfs-vfio
F: Documentation/ABI/testing/sysfs-devices-vfio-dev
F: Documentation/driver-api/vfio.rst
F: drivers/vfio/
+F: include/linux/kho/abi/vfio_pci.h
F: include/linux/vfio.h
F: include/linux/vfio_pci_core.h
F: include/uapi/linux/vfio.h
diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index 296bf01e185e..c12d614fc6c4 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -42,6 +42,18 @@ config VFIO_PCI_IGD
and LPC bridge config space.
To enable Intel IGD assignment through vfio-pci, say Y.
+
+config VFIO_PCI_LIVEUPDATE
+ bool "VFIO PCI support for Live Update (EXPERIMENTAL)"
+ depends on PCI_LIVEUPDATE
+ help
+ Support for preserving devices bound to vfio-pci across a Live
+ Update. This option should only be enabled by developers working on
+ implementing this support. Once enough support has landed in the
+ kernel, this option will no longer be marked EXPERIMENTAL.
+
+ If you don't know what to do here, say N.
+
endif
config VFIO_PCI_ZDEV_KVM
diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
index 6138f1bf241d..bf296ab1c967 100644
--- a/drivers/vfio/pci/Makefile
+++ b/drivers/vfio/pci/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_VFIO_PCI_CORE) += vfio-pci-core.o
vfio-pci-y := vfio_pci.o
vfio-pci-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o
+vfio-pci-$(CONFIG_VFIO_PCI_LIVEUPDATE) += vfio_pci_liveupdate.o
obj-$(CONFIG_VFIO_PCI) += vfio-pci.o
obj-$(CONFIG_MLX5_VFIO_PCI) += mlx5/
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 1fb4b276afe7..439d14d79d8f 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -264,10 +264,14 @@ static int __init vfio_pci_init(void)
vfio_pci_core_set_params(nointxmask, is_disable_vga, disable_idle_d3);
+ ret = vfio_pci_liveupdate_init();
+ if (ret)
+ return ret;
+
/* Register and scan for devices */
ret = pci_register_driver(&vfio_pci_driver);
if (ret)
- return ret;
+ goto err_liveupdate_cleanup;
vfio_pci_fill_ids();
@@ -275,12 +279,17 @@ static int __init vfio_pci_init(void)
pr_warn("device denylist disabled.\n");
return 0;
+
+err_liveupdate_cleanup:
+ vfio_pci_liveupdate_cleanup();
+ return ret;
}
module_init(vfio_pci_init);
static void __exit vfio_pci_cleanup(void)
{
pci_unregister_driver(&vfio_pci_driver);
+ vfio_pci_liveupdate_cleanup();
}
module_exit(vfio_pci_cleanup);
diff --git a/drivers/vfio/pci/vfio_pci_liveupdate.c b/drivers/vfio/pci/vfio_pci_liveupdate.c
new file mode 100644
index 000000000000..803528c9f1b2
--- /dev/null
+++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright (c) 2026, Google LLC.
+ * Vipin Sharma <vipinsh@google.com>
+ * David Matlack <dmatlack@google.com>
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/errno.h>
+#include <linux/kho/abi/vfio_pci.h>
+#include <linux/liveupdate.h>
+#include <linux/module.h>
+
+#include "vfio_pci_priv.h"
+
+static bool vfio_pci_liveupdate_can_preserve(struct liveupdate_file_handler *handler,
+ struct file *file)
+{
+ return false;
+}
+
+static int vfio_pci_liveupdate_preserve(struct liveupdate_file_op_args *args)
+{
+ return -EOPNOTSUPP;
+}
+
+static void vfio_pci_liveupdate_unpreserve(struct liveupdate_file_op_args *args)
+{
+}
+
+static int vfio_pci_liveupdate_retrieve(struct liveupdate_file_op_args *args)
+{
+ return -EOPNOTSUPP;
+}
+
+static void vfio_pci_liveupdate_finish(struct liveupdate_file_op_args *args)
+{
+}
+
+static const struct liveupdate_file_ops vfio_pci_liveupdate_file_ops = {
+ .can_preserve = vfio_pci_liveupdate_can_preserve,
+ .preserve = vfio_pci_liveupdate_preserve,
+ .unpreserve = vfio_pci_liveupdate_unpreserve,
+ .retrieve = vfio_pci_liveupdate_retrieve,
+ .finish = vfio_pci_liveupdate_finish,
+ .owner = THIS_MODULE,
+};
+
+static struct liveupdate_file_handler vfio_pci_liveupdate_fh = {
+ .ops = &vfio_pci_liveupdate_file_ops,
+ .compatible = VFIO_PCI_LUO_FH_COMPATIBLE,
+};
+
+int __init vfio_pci_liveupdate_init(void)
+{
+ int ret;
+
+ ret = liveupdate_register_file_handler(&vfio_pci_liveupdate_fh);
+ if (ret)
+ goto err_return;
+
+ ret = pci_liveupdate_register_flb(&vfio_pci_liveupdate_fh);
+ if (ret)
+ goto err_unregister;
+
+ return 0;
+
+err_unregister:
+ liveupdate_unregister_file_handler(&vfio_pci_liveupdate_fh);
+err_return:
+ return (ret == -EOPNOTSUPP) ? 0 : ret;
+}
+
+void vfio_pci_liveupdate_cleanup(void)
+{
+ pci_liveupdate_unregister_flb(&vfio_pci_liveupdate_fh);
+ liveupdate_unregister_file_handler(&vfio_pci_liveupdate_fh);
+}
diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h
index 85bc1666cb0e..5d2ad128523d 100644
--- a/drivers/vfio/pci/vfio_pci_priv.h
+++ b/drivers/vfio/pci/vfio_pci_priv.h
@@ -142,4 +142,18 @@ static inline void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev,
}
#endif
+#ifdef CONFIG_VFIO_PCI_LIVEUPDATE
+int __init vfio_pci_liveupdate_init(void);
+void vfio_pci_liveupdate_cleanup(void);
+#else
+static inline int vfio_pci_liveupdate_init(void)
+{
+ return 0;
+}
+
+static inline void vfio_pci_liveupdate_cleanup(void)
+{
+}
+#endif /* CONFIG_VFIO_PCI_LIVEUPDATE */
+
#endif
diff --git a/include/linux/kho/abi/vfio_pci.h b/include/linux/kho/abi/vfio_pci.h
new file mode 100644
index 000000000000..67e8199eec59
--- /dev/null
+++ b/include/linux/kho/abi/vfio_pci.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Copyright (c) 2026, Google LLC.
+ * Vipin Sharma <vipinsh@google.com>
+ * David Matlack <dmatlack@google.com>
+ */
+
+#ifndef _LINUX_LIVEUPDATE_ABI_VFIO_PCI_H
+#define _LINUX_LIVEUPDATE_ABI_VFIO_PCI_H
+
+/**
+ * DOC: VFIO PCI Live Update ABI
+ *
+ * VFIO uses the ABI defined below for preserving device files across a kexec
+ * reboot using LUO.
+ *
+ * Device metadata is serialized into memory which is then handed to the next
+ * kernel via KHO.
+ *
+ * This interface is a contract. Any modification to any of the serialization
+ * structs defined here constitutes a breaking change. Such changes require
+ * incrementing the version number in the VFIO_PCI_LUO_FH_COMPATIBLE string.
+ */
+
+#define VFIO_PCI_LUO_FH_COMPATIBLE "vfio-pci-v1"
+
+#endif /* _LINUX_LIVEUPDATE_ABI_VFIO_PCI_H */
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 04/20] liveupdate: Export symbols needed by modules
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
Export liveupdate_register_file_handler() and
liveupdate_unregister_file_handler(). All of these will be used by
vfio-pci in a subsequent commit, which can be built as a module.
Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
kernel/liveupdate/luo_file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c
index c39f96961a85..dd4e26ac34f0 100644
--- a/kernel/liveupdate/luo_file.c
+++ b/kernel/liveupdate/luo_file.c
@@ -909,6 +909,7 @@ int liveupdate_register_file_handler(struct liveupdate_file_handler *fh)
up_write(&luo_register_rwlock);
return err;
}
+EXPORT_SYMBOL_GPL(liveupdate_register_file_handler);
/**
* liveupdate_unregister_file_handler - Unregister a liveupdate file handler
@@ -926,3 +927,4 @@ void liveupdate_unregister_file_handler(struct liveupdate_file_handler *fh)
luo_flb_unregister_all(fh);
list_del(&ACCESS_PRIVATE(fh, list));
}
+EXPORT_SYMBOL_GPL(liveupdate_unregister_file_handler);
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 03/20] vfio/pci: Export vfio_pci_dma_buf_move for vfio-pci module
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
VFIO Live update during freeze needs to reset the device before handing
over to next kernel.
Export DMA revoke function which VFIO Live Update will call in its
freeze before reset so that P2P DMA doesn't error out or cause some
other issue.
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/pci/vfio_pci_dmabuf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
index c16f460c01d6..2c05fb5a171a 100644
--- a/drivers/vfio/pci/vfio_pci_dmabuf.c
+++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
@@ -376,6 +376,7 @@ void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
fput(priv->dmabuf->file);
}
}
+EXPORT_SYMBOL_GPL(vfio_pci_dma_buf_move);
void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device *vdev)
{
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 02/20] vfio: Export various helpers from VFIO
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
The upcoming VFIO live update feature needs to access various helper
functions for its logic which are not exported by default.
Export these functions and variable for other modules to use them.
Remove static from their declaration and add them in
include/linux/vfio.h and drivers/vfio/pci/vfio_pci_priv.h header files.
No functional change intended.
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/pci/vfio_pci.c | 2 +-
drivers/vfio/pci/vfio_pci_core.c | 6 ++++--
drivers/vfio/pci/vfio_pci_priv.h | 5 +++++
drivers/vfio/vfio_main.c | 3 ++-
include/linux/vfio.h | 1 +
5 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 0c771064c0b8..1fb4b276afe7 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -125,7 +125,7 @@ static int vfio_pci_open_device(struct vfio_device *core_vdev)
return 0;
}
-static const struct vfio_device_ops vfio_pci_ops = {
+const struct vfio_device_ops vfio_pci_ops = {
.name = "vfio-pci",
.init = vfio_pci_core_init_dev,
.release = vfio_pci_core_release_dev,
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 3c8b990ee92f..f31e59e5badb 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -623,7 +623,7 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
}
EXPORT_SYMBOL_GPL(vfio_pci_core_enable);
-static void vfio_pci_core_try_reset(struct vfio_pci_core_device *vdev)
+void vfio_pci_core_try_reset(struct vfio_pci_core_device *vdev)
{
struct pci_dev *pdev = vdev->pdev;
struct pci_dev *bridge;
@@ -674,6 +674,7 @@ static void vfio_pci_core_try_reset(struct vfio_pci_core_device *vdev)
out_restore_state:
pci_restore_state(pdev);
}
+EXPORT_SYMBOL_GPL(vfio_pci_core_try_reset);
void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
{
@@ -1657,7 +1658,7 @@ ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *bu
}
EXPORT_SYMBOL_GPL(vfio_pci_core_write);
-static void vfio_pci_zap_bars(struct vfio_pci_core_device *vdev)
+void vfio_pci_zap_bars(struct vfio_pci_core_device *vdev)
{
struct vfio_device *core_vdev = &vdev->vdev;
loff_t start = VFIO_PCI_INDEX_TO_OFFSET(VFIO_PCI_BAR0_REGION_INDEX);
@@ -1666,6 +1667,7 @@ static void vfio_pci_zap_bars(struct vfio_pci_core_device *vdev)
unmap_mapping_range(core_vdev->inode->i_mapping, start, len, true);
}
+EXPORT_SYMBOL_GPL(vfio_pci_zap_bars);
void vfio_pci_zap_and_down_write_memory_lock(struct vfio_pci_core_device *vdev)
{
diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h
index fca9d0dfac90..85bc1666cb0e 100644
--- a/drivers/vfio/pci/vfio_pci_priv.h
+++ b/drivers/vfio/pci/vfio_pci_priv.h
@@ -11,6 +11,8 @@
/* Cap maximum number of ioeventfds per device (arbitrary) */
#define VFIO_PCI_IOEVENTFD_MAX 1000
+extern const struct vfio_device_ops vfio_pci_ops;
+
struct vfio_pci_ioeventfd {
struct list_head next;
struct vfio_pci_core_device *vdev;
@@ -73,6 +75,9 @@ u16 vfio_pci_memory_lock_and_enable(struct vfio_pci_core_device *vdev);
void vfio_pci_memory_unlock_and_restore(struct vfio_pci_core_device *vdev,
u16 cmd);
+void vfio_pci_zap_bars(struct vfio_pci_core_device *vdev);
+void vfio_pci_core_try_reset(struct vfio_pci_core_device *vdev);
+
#ifdef CONFIG_VFIO_PCI_IGD
bool vfio_pci_is_intel_display(struct pci_dev *pdev);
int vfio_pci_igd_init(struct vfio_pci_core_device *vdev);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 5e0422014523..2437af031169 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -1467,7 +1467,7 @@ const struct file_operations vfio_device_fops = {
#endif
};
-static struct vfio_device *vfio_device_from_file(struct file *file)
+struct vfio_device *vfio_device_from_file(struct file *file)
{
struct vfio_device_file *df = file->private_data;
@@ -1475,6 +1475,7 @@ static struct vfio_device *vfio_device_from_file(struct file *file)
return NULL;
return df->device;
}
+EXPORT_SYMBOL_GPL(vfio_device_from_file);
/**
* vfio_file_is_valid - True if the file is valid vfio file
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 31b826efba00..cf0d941d0410 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -378,6 +378,7 @@ static inline bool vfio_file_has_dev(struct file *file, struct vfio_device *devi
bool vfio_file_is_valid(struct file *file);
bool vfio_file_enforced_coherent(struct file *file);
void vfio_file_set_kvm(struct file *file, struct kvm *kvm);
+struct vfio_device *vfio_device_from_file(struct file *file);
#define VFIO_PIN_PAGES_MAX_ENTRIES (PAGE_SIZE/sizeof(unsigned long))
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 01/20] vfio/pci: Factor out the reset logic in VFIO PCI device close path
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <20260714151505.3466855-1-vipinsh@google.com>
vfio_pci_core_disable() is a very long function doing multiple things
like exiting runtime power management, setting device to D0 power,
clearing bus master, clearing irqs, freeing eventfds, releasing device
regions, unmapping PCI bars, and performing device/bus resets.
The upcoming VFIO Liveupdate feature will also need to utilize same
reset logic.
Extract device reset code to a new helper function,
vfio_pci_core_try_reset(), and update vfio_pci_core_disable() to use
this new function.
No functional change intended.
Co-developed-by: David Matlack <dmatlack@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Signed-off-by: Vipin Sharma <vipinsh@google.com>
---
drivers/vfio/pci/vfio_pci_core.c | 100 ++++++++++++++++---------------
1 file changed, 53 insertions(+), 47 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index a28f1e99362c..3c8b990ee92f 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -623,9 +623,60 @@ int vfio_pci_core_enable(struct vfio_pci_core_device *vdev)
}
EXPORT_SYMBOL_GPL(vfio_pci_core_enable);
-void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
+static void vfio_pci_core_try_reset(struct vfio_pci_core_device *vdev)
{
+ struct pci_dev *pdev = vdev->pdev;
struct pci_dev *bridge;
+
+ vdev->needs_reset = true;
+
+ /*
+ * If we have saved state, restore it. If we can reset the device,
+ * even better. Resetting with current state seems better than
+ * nothing, but saving and restoring current state without reset
+ * is just busy work.
+ */
+ if (pci_load_and_free_saved_state(pdev, &vdev->pci_saved_state)) {
+ pci_info(pdev, "%s: Couldn't reload saved state\n", __func__);
+
+ if (!vdev->reset_works)
+ return;
+
+ pci_save_state(pdev);
+ }
+
+ /*
+ * Disable INTx and MSI, presumably to avoid spurious interrupts
+ * during reset. Stolen from pci_reset_function()
+ */
+ pci_write_config_word(pdev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);
+
+ /*
+ * Try to get the locks ourselves to prevent a deadlock. The
+ * success of this is dependent on being able to lock the device,
+ * which is not always possible.
+ * We can not use the "try" reset interface here, which will
+ * overwrite the previously restored configuration information.
+ */
+ if (vdev->reset_works) {
+ bridge = pci_upstream_bridge(pdev);
+ if (bridge && !pci_dev_trylock(bridge))
+ goto out_restore_state;
+ if (pci_dev_trylock(pdev)) {
+ if (!__pci_reset_function_locked(pdev))
+ vdev->needs_reset = false;
+ pci_dev_unlock(pdev);
+ }
+ if (bridge)
+ pci_dev_unlock(bridge);
+ }
+
+out_restore_state:
+ pci_restore_state(pdev);
+}
+
+void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
+{
struct pci_dev *pdev = vdev->pdev;
struct vfio_pci_dummy_resource *dummy_res, *tmp;
struct vfio_pci_ioeventfd *ioeventfd, *ioeventfd_tmp;
@@ -700,54 +751,9 @@ void vfio_pci_core_disable(struct vfio_pci_core_device *vdev)
kfree(dummy_res);
}
- vdev->needs_reset = true;
-
vfio_pci_zdev_close_device(vdev);
- /*
- * If we have saved state, restore it. If we can reset the device,
- * even better. Resetting with current state seems better than
- * nothing, but saving and restoring current state without reset
- * is just busy work.
- */
- if (pci_load_and_free_saved_state(pdev, &vdev->pci_saved_state)) {
- pci_info(pdev, "%s: Couldn't reload saved state\n", __func__);
-
- if (!vdev->reset_works)
- goto out;
-
- pci_save_state(pdev);
- }
-
- /*
- * Disable INTx and MSI, presumably to avoid spurious interrupts
- * during reset. Stolen from pci_reset_function()
- */
- pci_write_config_word(pdev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);
-
- /*
- * Try to get the locks ourselves to prevent a deadlock. The
- * success of this is dependent on being able to lock the device,
- * which is not always possible.
- * We can not use the "try" reset interface here, which will
- * overwrite the previously restored configuration information.
- */
- if (vdev->reset_works) {
- bridge = pci_upstream_bridge(pdev);
- if (bridge && !pci_dev_trylock(bridge))
- goto out_restore_state;
- if (pci_dev_trylock(pdev)) {
- if (!__pci_reset_function_locked(pdev))
- vdev->needs_reset = false;
- pci_dev_unlock(pdev);
- }
- if (bridge)
- pci_dev_unlock(bridge);
- }
-
-out_restore_state:
- pci_restore_state(pdev);
-out:
+ vfio_pci_core_try_reset(vdev);
pci_disable_device(pdev);
vfio_pci_dev_set_try_reset(vdev->vdev.dev_set);
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH v5 00/20] vfio/pci: Base Live Update support for VFIO
From: Vipin Sharma @ 2026-07-14 15:14 UTC (permalink / raw)
To: kexec, linux-kernel, linux-doc, kvm, linux-mm, linux-kselftest
Cc: ajayachandra, alex, amastro, ankita, apopple, bhelgaas, chrisl,
christian.koenig, corbet, dmatlack, graf, jacob.pan, jgg, jgg,
jrhilke, julianr, kees, kevin.tian, leon, leonro, lukas, mattev,
michal.winiarski, parav, pasha.tatashin, praan, pratyush, rananta,
rientjes, rodrigo.vivi, rppt, saeedm, schnelle, skhan, skhawaja,
vipinsh, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
Hello,
This series can be found on Github:
https://github.com/shvipin/linux vfio/liveupdate/v5
This series provides the base support to enable Live Update feature for
VFIO PCI devices using the Live Update Orchestrator (LUO) and Kexec
Handover (KHO).
Overview
--------
This series makes the following changes to support VFIO Live Update:
- Puts VFIO Live Update support behind the CONFIG_VFIO_PCI_LIVEUPDATE
config option (which requires CONFIG_VFIO_DEVICE_CDEV).
- Preserves VFIO cdev device FDs across a kexec Live Update session via
LUO/KHO.
- Enforces that incoming preserved devices can only be retrieved via
LIVEUPDATE_SESSION_RETRIEVE_FD post-kexec (preventing legacy
group/cdev opens from accessing uninitialized state).
- Quiesces the device prior to kexec in freeze() by resetting hardware,
disabling bus mastering, and marking the device frozen to reject
post-freeze IO/MMIO.
- Includes VFIO selftests (uapi & kexec tests with continuous DMA
checks) and kernel documentation.
VFIO PCI Live Update Roadmap
----------------------------
We are planning to add VFIO PCI Live Update support in phases. Since full
support of this feature will come in phase, VFIO PCI Liveupdate is
controlled by CONFIG_VFIO_PCI_LIVEUPDATE config option.
This series is phase 1 below:
1. PCIe function (non-VF) preserved across Live Update without changing
BDF
2. PCIe function (non-VF) preserved across Live Update without resetting
3. PCIe function (non-VF) preserved across Live Update with continuous
DMA (noiommu)
4. PCIe function (non-VF) preserved across Live Update with continuous
DMA (iommufd)
5. PCIe VF preserved across Live Update with continuous DMA (iommufd)
Dependencies
------------
This series has following dependencies as shown in the diagram
|---------------------------|
| VFIO v5 | <--- Sent in this series.
|---------------------------|
| Liveupdate Selftests[1] |
|---------------------------|
| PCI v7 [2] |
|---------------------------|
[1] https://lore.kernel.org/all/20260511201155.1488670-1-vipinsh@google.com/
These selftests changes are needed by other selftests also (iommu,
kvm), so, I have sent them separately.
[2] https://lore.kernel.org/linux-pci/20260710212616.1351130-1-dmatlack@google.com/
This is the PCI v7, which adds the live update support in PCI core.
Github branch I have mentioned at the top has all of these dependencies.
Testing
-------
Tested using VFIO Live Update selftests in both QEMU and bare-metal
environment (Intel DSA PCIe device).
$ ./setup.sh 0000:00:04.0
$ ./vfio_pci_liveupdate_kexec_test --stage 1 0000:6a:01.0
$ kexec --reuse-cmdline -l -s /boot/vmlinuz
$ kexec -e
$ ./setup.sh 0000:00:04.0
$ ./vfio_pci_liveupdate_kexec_test --stage 2 0000:6a:01.0
Kernel command line options used:
- liveupdate=on
- kho=on
- vfio_iommu_type1.allow_unsafe_interrupts=Y
- vfio_pci.enable_sriov=Y
- vfio_pci.disable_denylist=Y
- vfio.enable_unsafe_noiommu_mode=Y
Changelog
---------
v5:
- Addressed Sashiko feedback.
- Removed condition to disable CONFIG_VFIO_PCI_DMABUF.
- Expanded vfio_find_device() helper to safely discover a registered
vfio_device by matching criteria. Internal Sashiko instance found
data race.
- Updated selftests to latest changes in VFIO selftests.
- Rebased on top of PCI Live Update series v7.
v4: https://lore.kernel.org/kvm/20260511234802.2280368-1-vipinsh@google.com/
v3: https://lore.kernel.org/kvm/20260323235817.1960573-1-dmatlack@google.com/
v2: https://lore.kernel.org/kvm/20260129212510.967611-1-dmatlack@google.com/
v1: https://lore.kernel.org/kvm/20251126193608.2678510-1-dmatlack@google.com/
rfc: https://lore.kernel.org/kvm/20251018000713.677779-1-vipinsh@google.com/
David Matlack (7):
vfio: Enforce preserved devices are retrieved via
LIVEUPDATE_SESSION_RETRIEVE_FD
docs: liveupdate: Add documentation for VFIO PCI
vfio: selftests: Add vfio_pci_liveupdate_uapi_test
vfio: selftests: Add Makefile support for TEST_GEN_PROGS_EXTENDED
vfio: selftests: Expose iommu_modes to tests
vfio: selftests: Verify that opening VFIO device fails during Live
Update
vfio: selftests: Add continuous DMA to vfio_pci_liveupdate_kexec_test
Vipin Sharma (13):
vfio/pci: Factor out the reset logic in VFIO PCI device close path
vfio: Export various helpers from VFIO
vfio/pci: Export vfio_pci_dma_buf_move for vfio-pci module
liveupdate: Export symbols needed by modules
vfio/pci: Register a file handler with Live Update Orchestrator
vfio/pci: Preserve vfio-pci device files across Live Update
vfio: Introduce vfio_find_device() helper
vfio: Refactor vfio_device_fops_cdev_open()
vfio: Add API to open cdev device for Live Update restore
vfio/pci: Retrieve preserved device files after Live Update
vfio: selftests: Build liveupdate library in VFIO selftests
vfio: selftests: Initialize vfio_pci_device using a VFIO cdev FD
vfio: selftests: Add vfio_pci_liveupdate_kexec_test
Documentation/core-api/liveupdate.rst | 1 +
.../driver-api/vfio_pci_liveupdate.rst | 23 ++
MAINTAINERS | 2 +
drivers/vfio/device_cdev.c | 67 +++-
drivers/vfio/group.c | 9 +
drivers/vfio/pci/Kconfig | 12 +
drivers/vfio/pci/Makefile | 1 +
drivers/vfio/pci/vfio_pci.c | 13 +-
drivers/vfio/pci/vfio_pci_config.c | 3 +
drivers/vfio/pci/vfio_pci_core.c | 119 +++---
drivers/vfio/pci/vfio_pci_dmabuf.c | 1 +
drivers/vfio/pci/vfio_pci_liveupdate.c | 340 ++++++++++++++++++
drivers/vfio/pci/vfio_pci_priv.h | 28 ++
drivers/vfio/vfio.h | 18 +
drivers/vfio/vfio_main.c | 67 +++-
include/linux/kho/abi/vfio_pci.h | 43 +++
include/linux/vfio.h | 12 +
include/linux/vfio_pci_core.h | 3 +
kernel/liveupdate/luo_file.c | 2 +
tools/testing/selftests/vfio/Makefile | 23 +-
.../vfio/lib/include/libvfio/iommu.h | 2 +
.../lib/include/libvfio/vfio_pci_device.h | 3 +
tools/testing/selftests/vfio/lib/iommu.c | 4 +-
.../selftests/vfio/lib/vfio_pci_device.c | 25 +-
.../vfio/vfio_pci_liveupdate_kexec_test.c | 256 +++++++++++++
.../vfio/vfio_pci_liveupdate_uapi_test.c | 97 +++++
26 files changed, 1097 insertions(+), 77 deletions(-)
create mode 100644 Documentation/driver-api/vfio_pci_liveupdate.rst
create mode 100644 drivers/vfio/pci/vfio_pci_liveupdate.c
create mode 100644 include/linux/kho/abi/vfio_pci.h
create mode 100644 tools/testing/selftests/vfio/vfio_pci_liveupdate_kexec_test.c
create mode 100644 tools/testing/selftests/vfio/vfio_pci_liveupdate_uapi_test.c
base-commit: cbf37fff757e87376e80e11a8378393a8f25145f
prerequisite-patch-id: 85705fb54d3065efe1d87ab4b69e828a9f3404e7
prerequisite-patch-id: a33ae79b5fc0259bd013b430c18cc3d14a678599
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply
* Re: What's cooking in zh_CN (Jul 2026, #02)
From: Weijie Yuan @ 2026-07-14 15:04 UTC (permalink / raw)
To: linux-doc
Cc: Alex Shi, Yanteng Si, Dongliang Mu, Ben Guo, Gary Guo, Yan Zhu,
Doehyun Baek, Jiandong Qiu, chengyaqiang, Haoyang Liu
In-Reply-To: <alZK0i0HvxOvSKwj@wyuan.org>
On Tue, Jul 14, 2026 at 10:42:34PM +0800, Weijie Yuan wrote:
> Here are the topics that have been cooking in Alex's tree.
This statement is incorrect. I will correct it next time.
Sorry for the noise.
> Copies of the source code to Chinese documentation development tree live
> in here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
> https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/alexs/linux.git
>
> Mirrors:
>
> https://mirrors.hust.edu.cn/git/kernel-doc-zh.git
> https://mirror.nju.edu.cn/git/kernel-doc-zh.git (experimental)
^ permalink raw reply
* What's cooking in zh_CN (Jul 2026, #02)
From: Weijie Yuan @ 2026-07-14 14:42 UTC (permalink / raw)
To: linux-doc
Cc: Alex Shi, Yanteng Si, Dongliang Mu, Ben Guo, Gary Guo, Yan Zhu,
Doehyun Baek, Jiandong Qiu, chengyaqiang, Haoyang Liu
Here are the topics that have been cooking in Alex's tree.
Copies of the source code to Chinese documentation development tree live
in here:
git://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
https://kernel.googlesource.com/pub/scm/linux/kernel/git/alexs/linux.git
Mirrors:
https://mirrors.hust.edu.cn/git/kernel-doc-zh.git
https://mirror.nju.edu.cn/git/kernel-doc-zh.git (experimental)
Please report any mirror instability to linux-doc@vger.kernel.org
-----------------------------------------------------------------------
NOTICE
The first "What's cooking" missed Haoyang Liu, and it so happens that
there are several topics graduating today, so the frequency of status
updates this time is relatively high.
The first time I cc'ed all relevant personnel. Is everyone happy to keep
it this way, or should I only send it to the list? I´m concerned that
unrelated discussions may create unnecessary noise in their inbox.
This report is experimental. Please feel free to offer your suggestions.
-----------------------------------------------------------------------
[Graduated to 'docs-next']
* Ben Guo (2026-07-14) 4 commits
[PATCH v3 0/4] docs/zh_CN: update rust documentation translations
[PATCH v3 1/4] docs/zh_CN: Update rust/quick-start.rst translation
[PATCH v3 2/4] docs/zh_CN: Update rust/general-information.rst translation
[PATCH v3 3/4] docs/zh_CN: Update rust/arch-support.rst translation
[PATCH v3 4/4] docs/zh_CN: Update rust/testing.rst translation
Merged into docs-next.
source: https://lore.kernel.org/linux-doc/cover.1784000217.git.ben.guo@openatom.club/
* chengyaqiang (2026-05-22) 1 commit
[PATCH] docs/zh_CN: fix KASAN SW_TAGS mode description
Merged into docs-next.
source: https://lore.kernel.org/linux-doc/20260522075735.2022734-1-chengyaqiang@chengyaqiang.com/
-----------------------------------------------------------------------
[Cooking]
* Doehyun Baek (2026-07-08) 7 commits
[PATCH v6 0/7] docs/zh_CN: update DAMON translations
[PATCH v6 1/7] docs/zh_CN: update DAMON design translation
[PATCH v6 2/7] docs/zh_CN: add DAMON_STAT usage translation
[PATCH v6 3/7] docs/zh_CN: update DAMON index translation
[PATCH v6 4/7] docs/zh_CN: update DAMON start translation
[PATCH v6 5/7] docs/zh_CN: update DAMON usage translation
[PATCH v6 6/7] docs/zh_CN: update DAMON reclaim translation
[PATCH v6 7/7] docs/zh_CN: update DAMON LRU sort translation
Needs review.
source: https://lore.kernel.org/linux-doc/20260708073246.1652828-1-doehyunbaek@gmail.com/
* Jiandong Qiu (2026-07-06) 2 commits
[PATCH v3 0/2] docs/zh_CN: update translation of doc-guide/sphinx.rst
[PATCH v3 1/2] docs/zh_CN: add process/changes.rst translation
[PATCH v3 2/2] docs/zh_CN: update sphinx.rst translation
Needs review.
cf. https://lore.kernel.org/linux-doc/ak1SG5mw7y2UZrvR@wyuan.org/
source: https://lore.kernel.org/linux-doc/20260706151358.2103703-1-qiujiandong1998@gmail.com/
* Yan Zhu (2026-06-12) 10 commits
[not found] <cover.1781105672.git.zhuyan2015@qq.com>
[PATCH 01/10] docs/zh_CN: add LSM/index Chinese translation
[PATCH 02/10] docs/zh_CN: add LSM/apparmor Chinese translation
[PATCH 03/10] docs/zh_CN: add LSM/LoadPin Chinese translation
[PATCH 04/10] docs/zh_CN: add LSM/SELinux Chinese translation
[PATCH 05/10] docs/zh_CN: add LSM/Smack Chinese translation
[PATCH 06/10] docs/zh_CN: add LSM/tomoyo Chinese translation
[PATCH 07/10] docs/zh_CN: add LSM/Yama Chinese translation
[PATCH 08/10] docs/zh_CN: add LSM/SafeSetID Chinese translation
[PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
[PATCH 10/10] docs/zh_CN: add LSM/landlock Chinese translation
Needs review.
source: https://lore.kernel.org/linux-doc/tencent_7080BF6BB8F05936649DDC091FFD8C45210A@qq.com/
Note: cover letter missing on lore archive.
-----------------------------------------------------------------------
[Stalled]
* Haoyang Liu (2026-03-05) 1 commit
[PATCH] docs/zh_CN: fix an inconsistent statement in dev-tools/testing-overview
Expecting a reroll.
cf. https://lore.kernel.org/linux-doc/29bd0dbc-c6f9-43ce-b95f-4e787e3fe9c3@gmail.com/
source: https://lore.kernel.org/linux-doc/20260305192048.16405-1-tttturtleruss@gmail.com/
^ permalink raw reply
* Re: (subset) [PATCH v25 0/7] firmware: imx: driver for NXP secure-enclave
From: Frank Li @ 2026-07-14 14:38 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Frank Li, Jonathan Corbet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Pankaj Gupta, linux-doc, linux-kernel, devicetree,
imx, linux-arm-kernel
In-Reply-To: <73a5b9fd-aff4-4ae2-ab2b-d860bbc7325d@kontron.de>
On Tue, Jul 14, 2026 at 09:27:06AM +0200, Frieder Schrempf wrote:
> On 05.05.26 17:53, Frank Li wrote:
> >
> > On Thu, 22 Jan 2026 17:19:12 +0530, Pankaj Gupta wrote:
> >> The NXP's i.MX EdgeLock Enclave, a HW IP creating an embedded secure
> >> enclave within the SoC boundary to enable features like
> >> - HSM
> >> - SHE
> >> - V2X
> >>
> >> Communicates via message unit with linux kernel. This driver is
> >> enables communication ensuring well defined message sequence protocol
> >> between Application Core and enclave's firmware.
> >>
> >> [...]
> >
> > Applied, thanks!
> >
> > [1/7] Documentation/firmware: add imx/se to other_interfaces
> > commit: 3b4531c6e0f4c8874f0266853a410438eda1fc24
> > [2/7] dt-bindings: arm: fsl: add imx-se-fw binding doc
> > commit: 4d7bcf0869686d7d7fbf16244453b987e5ca6d14
> > [3/7] firmware: imx: add driver for NXP EdgeLock Enclave
> > commit: 338529a73c2bf2c277013b745cfe6f19b84b70af
> > [4/7] firmware: imx: device context dedicated to priv
> > commit: 2d733ed67f608ee85abb854157011f88d7f280a8
> > [5/7] firmware: drivers: imx: adds miscdev
> > commit: 4de71839142b5f43846e3593f4eb236e1d733885
> What happened to these patches?
>
> They were part of linux-next for quite some time (up to next-20260630)
> and then they disappeared (missing in next-20260701).
>
> I didn't find any hint where or why they were dropped.
Sashiko and linux-next build found some issues, which need be fixed before
send pull request.
Pankaj is working on the new version.
Frank
>
^ permalink raw reply
* Re: [PATCH 3/6] iio: adc: adi-axi-adc: Add support for CRC
From: Nuno Sá @ 2026-07-14 14:33 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Janani Sunil, Nuno Sá, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Olivier Moysan, Philipp Zabel, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Shuah Khan, linux, linux-iio, devicetree,
linux-kernel, linux-gpio, linux-doc, jananisunil.dev
In-Reply-To: <ucrlt75xiwbv3rrc4gvgdop24u54eizhuqzf2av2qsa6ceymdp@kfkuiwuvakhl>
On Tue, Jul 14, 2026 at 04:18:24PM +0200, Nuno Sá wrote:
> On Fri, Jul 10, 2026 at 01:46:17AM +0100, Jonathan Cameron wrote:
> > On Thu, 9 Jul 2026 10:50:14 +0200
> > Janani Sunil <janani.sunil@analog.com> wrote:
> >
> > > Add support for enabling and disabling Cyclic Redundancy Check (CRC)
> > > processing in the AXI ADC backend. CRC provides data integrity verification
> > > for high-speed ADC data streams, ensuring reliable data transfer between
> > > the ADC frontend and backend processing systems.
> > >
> > > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> > The 'other things' I found bit from Sashiko is interesting. Far as I can
> > tell it is right and [devm_]mutex_init() is missing for lock
> > in struct adi_axi_adc_state().
> >
>
> Ouch! Yes, I was also wondering about the lock comment.
>
> > Nuno, looks like it was from:
> > 7ecb8ee5c93b ("iio: adc: adi-axi-adc: support digital interface calibration")
> >
> > Which indeed adds the lock with a mutex_init()
>
> You mean without :)?
>
> I'll send a patch fixing it!
Actually, to make it easier, Janani will include the fix in v2.
- Nuno Sá
> - Nuno Sá
> >
> > Jonathan
> >
> > > static const struct iio_backend_info adi_axi_adc_generic = {
> > >
> >
^ permalink raw reply
* RE: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
From: Shenwei Wang (OSS) @ 2026-07-14 14:29 UTC (permalink / raw)
To: Mathieu Poirier, Shenwei Wang (OSS)
Cc: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Arnaud POULIQUEN, b-padhi@ti.com, Andrew Lunn
In-Reply-To: <alUdg9iTysXCFUa5@p14s>
> -----Original Message-----
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
> Sent: Monday, July 13, 2026 12:17 PM
> To: Shenwei Wang (OSS) <shenwei.wang@oss.nxp.com>
> Cc: Linus Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
> Jonathan Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
> Andersson <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Shenwei Wang <shenwei.wang@nxp.com>; Peng Fan
> <peng.fan@nxp.com>; devicetree@vger.kernel.org; linux-
> remoteproc@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>; Arnaud
> POULIQUEN <arnaud.pouliquen@foss.st.com>; b-padhi@ti.com; Andrew Lunn
> <andrew@lunn.ch>
> Subject: Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg
> bus
>
> On Thu, Jun 25, 2026 at 10:54:26AM -0500, Shenwei Wang wrote:
> > From: Shenwei Wang <shenwei.wang@nxp.com>
> >
> > Describes the gpio rpmsg transport protocol over the rpmsg bus between
> > the remote system and Linux.
> >
> > Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> > ---
> > Documentation/driver-api/gpio/gpio-rpmsg.rst | 271 +++++++++++++++++++
> > Documentation/driver-api/gpio/index.rst | 1 +
> > 2 files changed, 272 insertions(+)
> > create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
> >
> > diff --git a/Documentation/driver-api/gpio/gpio-rpmsg.rst
> > b/Documentation/driver-api/gpio/gpio-rpmsg.rst
> > new file mode 100644
> > index 000000000000..7d351ff0adb0
> > --- /dev/null
> > +++ b/Documentation/driver-api/gpio/gpio-rpmsg.rst
> > @@ -0,0 +1,271 @@
> > +.. SPDX-License-Identifier: GPL-2.0-or-later
> > +
> > +GPIO RPMSG (Remote Processor Messaging) Protocol
> > +================================================
> > +
> > +The GPIO RPMSG transport protocol is used for communication and
> > +interaction with GPIO controllers on remote processors via the RPMSG bus.
> > +
> > +Message Format
> > +--------------
> > +
> > +The RPMSG message consists of a 8-byte packet with the following layout:
> > +
> > +.. code-block:: none
> > +
> > + +------+------+------+------+------+------+------+------+
> > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > + | cmd | line | value |
> > + +------+------+------+------+------+------+------+------+
> > +
> > +- **cmd**: Command code, used for GPIO_RPMSG_SEND messages.
> > +
> > +- **line**: The GPIO line (pin) index of the port.
>
> Here and throughout, please remove any mention of 'port'. This is handled by the
> endpoint device, i.e one GPIO controller (port) per endpoint.
>
> > +
> > +- **value**: See details in the command description below.
> > +
> > +
> > +GPIO Commands
> > +-------------
> > +
> > +Commands are specified in the **Cmd** field.
> > +
> > +The SEND message is always sent from Linux to the remote firmware.
> > +Each SEND corresponds to a single REPLY message. The GPIO driver
> > +should serialize messages and determine whether a REPLY message is
> > +required. If a REPLY message is expected but not received within the
> > +specified timeout period (currently 1 second in the Linux driver),
> > +the driver should return -ETIMEOUT.
> > +
> > +GET_DIRECTION (Cmd=2)
> > +~~~~~~~~~~~~~~~~~~~~~
> > +
> > +**Request:**
> > +
> > +.. code-block:: none
> > +
> > + +------+------+------+------+------+------+------+------+
> > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > + | 2 | line | 0 |
> > + +------+------+------+------+------+------+------+------+
> > +
> > +**Reply:**
> > +
> > +.. code-block:: none
> > +
> > + +------+--------+--------+
> > + | 0x00 | 0x01 | 0x02 |
> > + | 1 | status | value |
> > + +------+--------+--------+
> > +
> > +- **status**:
> > +
> > + - 0: Ok
> > + - 1: Error
> > +
> > +- **value**: Direction.
> > +
> > + - 0: None
> > + - 1: Output
> > + - 2: Input
> > +
> > +
> > +SET_DIRECTION (Cmd=3)
> > +~~~~~~~~~~~~~~~~~~~~~
> > +
> > +**Request:**
> > +
> > +.. code-block:: none
> > +
> > + +------+------+------+------+------+------+------+------+
> > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > + | 3 | line | value |
> > + +------+------+------+------+------+------+------+------+
> > +
> > +- **value**: Direction.
> > +
> > + - 0: None
> > + - 1: Output
> > + - 2: Input
> > +
> > +**Reply:**
> > +
> > +.. code-block:: none
> > +
> > + +------+--------+--------+
> > + | 0x00 | 0x01 | 0x02 |
> > + | 1 | status | 0 |
> > + +------+--------+--------+
> > +
> > +- **status**:
> > +
> > + - 0: Ok
> > + - 1: Error
> > +
> > +
> > +GET_VALUE (Cmd=4)
> > +~~~~~~~~~~~~~~~~~
> > +
> > +**Request:**
> > +
> > +.. code-block:: none
> > +
> > + +------+------+------+------+------+------+------+------+
> > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > + | 4 | line | 0 |
> > + +------+------+------+------+------+------+------+------+
> > +
> > +**Reply:**
> > +
> > +.. code-block:: none
> > +
> > + +------+--------+--------+
> > + | 0x00 | 0x01 | 0x02 |
> > + | 1 | status | value |
> > + +------+--------+--------+
> > +
> > +- **status**:
> > +
> > + - 0: Ok
> > + - 1: Error
> > +
> > +- **value**: Level.
> > +
> > + - 0: Low
> > + - 1: High
> > +
> > +
> > +SET_VALUE (Cmd=5)
> > +~~~~~~~~~~~~~~~~~
> > +
> > +**Request:**
> > +
> > +.. code-block:: none
> > +
> > + +------+------+------+------+------+------+------+------+
> > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > + | 5 | line | value |
> > + +------+------+------+------+------+------+------+------+
> > +
> > +- **value**: Output level.
> > +
> > + - 0: Low
> > + - 1: High
> > +
> > +**Reply:**
> > +
> > +.. code-block:: none
> > +
> > + +------+--------+--------+
> > + | 0x00 | 0x01 | 0x02 |
> > + | 1 | status | 0 |
> > + +------+--------+--------+
> > +
> > +- **status**:
> > +
> > + - 0: Ok
> > + - 1: Error
> > +
> > +
> > +SET_IRQ_TYPE (Cmd=6)
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +**Request:**
> > +
> > +.. code-block:: none
> > +
> > + +------+------+------+------+------+------+------+------+
> > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > + | 6 | line | value |
> > + +------+------+------+------+------+------+------+------+
> > +
> > +- **value**: IRQ types.
> > +
> > + - 0: Interrupt disabled
> > + - 1: Rising edge trigger
> > + - 2: Falling edge trigger
> > + - 3: Both edge trigger
> > + - 4: High level trigger
> > + - 8: Low level trigger
>
> I'm in agreement with cmd 3, 4, 5 and 6.
>
How about cmd 2?
> > +
> > +**Reply:**
> > +
> > +.. code-block:: none
> > +
> > + +------+--------+--------+
> > + | 0x00 | 0x01 | 0x02 |
> > + | 1 | status | 0 |
> > + +------+--------+--------+
> > +
> > +- **status**:
> > +
> > + - 0: Ok
> > + - 1: Error
> > +
> > +SET_WAKEUP (Cmd=16)
> > +~~~~~~~~~~~~~~~~~~~
>
> I already commented on messages that are not part of the virtio-gpio
> specification.
>
I don't believe virtio-gpio needs a SET_WAKEUP command.
In the RPMSG case, SET_WAKEUP is required because it performs an operation on the
remote processor, so the remote side must be explicitly notified.
For virtio-gpio, however, everything is handled locally. The other side does not need to
perform any action, so sending a SET_WAKEUP command appears unnecessary.
> > +
> > +**Request:**
> > +
> > +.. code-block:: none
> > +
> > + +------+------+------+------+------+------+------+------+
> > + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> > + | 1 | line | value |
> > + +------+------+------+------+------+------+------+------+
> > +
> > +- **value**: Wakeup enable.
> > +
> > + The remote system should always aim to stay in a power-efficient
> > + state by shutting down or clock-gating the GPIO blocks that aren't
> > + in use. Since the remoteproc driver is responsible for managing the
> > + power states of the remote firmware, the GPIO driver does not
> > + require to know the firmware's running states.
> > +
> > + When the wakeup bit is set, the remote firmware should configure
> > + the line as a wakeup source. The firmware should send the
> > + notification message to Linux after it is woken from the GPIO line.
> > +
> > + - 0: Disable wakeup from GPIO
> > + - 1: Enable wakeup from GPIO
> > +
> > +**Reply:**
> > +
> > +.. code-block:: none
> > +
> > + +------+--------+--------+
> > + | 0x00 | 0x01 | 0x02 |
> > + | 1 | status | 0 |
> > + +------+--------+--------+
> > +
> > +- **status**:
> > +
> > + - 0: Ok
> > + - 1: Error
> > +
> > +Notification Message
> > +--------------------
>
> "Interrupt Messages"
>
> > +
> > +Notifications are sent by the remote core and they have
> > +**Type=2 (GPIO_RPMSG_NOTIFY)**:
> > +
> > +When a GPIO line asserts an interrupt on the remote processor, the
> > +firmware should immediately mask the corresponding interrupt source
> > +and send a notification message to the Linux. Upon completion of the
> > +interrupt handling on the Linux side, the driver should issue a
> > +command **SET_IRQ_TYPE** to the firmware to unmask the interrupt.
> > +
> > +A Notification message can arrive between a SEND and its REPLY
> > +message, and the driver is expected to handle this scenario.
> > +
> > +.. code-block:: none
> > +
> > + +------+------+--------+
> > + | 0x00 | 0x01 | 0x02 |
> > + | 2 | line | trigger|
> > + +------+------+--------+
>
> 2 things here:
>
> 1) You did not include messages that mask and unmask interrupts at the driver
> side.
Interrupt masking and unmasking are handled entirely on the local processor.
When an interrupt occurs, the remote system masks the interrupt and then sends a notification
to Linux. After Linux processes the notification, it sends a SET_IRQ_TYPE message back to the
remote system, which then unmasks the interrupt.
Thanks,
Shenwei
>
> 2) We are carrying virtio-gpio messages on top of RPMSG and as such, this whole
> protocol should be about thar:
>
> +------+------+--------+--------
> | 0x00 | payload |
> | Q | |
> +------+------+--------+--------
>
> Q = 0 requestq
> Q = 1 eventq
>
> The "payload" part is simply the format of the messages as found in the virtio-
> gpio specification. From there, the only thing left to mention is which messages
> are not supported, i.e get line names.
>
> > +
> > +- **line**: The GPIO line (pin) index of the port.
> > +
> > +- **trigger**: Optional parameter to indicate the trigger event type.
>
> Not part of the spec - remove.
>
> Given the refactoring work that is still needed, I will not look at the
> implementation.
>
> Thanks,
> Mathieu
>
> > +
> > diff --git a/Documentation/driver-api/gpio/index.rst
> > b/Documentation/driver-api/gpio/index.rst
> > index bee58f709b9a..e5eb1f82f01f 100644
> > --- a/Documentation/driver-api/gpio/index.rst
> > +++ b/Documentation/driver-api/gpio/index.rst
> > @@ -16,6 +16,7 @@ Contents:
> > drivers-on-gpio
> > bt8xxgpio
> > pca953x
> > + gpio-rpmsg
> >
> > Core
> > ====
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH 3/6] iio: adc: adi-axi-adc: Add support for CRC
From: Nuno Sá @ 2026-07-14 14:18 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Janani Sunil, Nuno Sá, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Olivier Moysan, Philipp Zabel, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Shuah Khan, linux, linux-iio, devicetree,
linux-kernel, linux-gpio, linux-doc, jananisunil.dev
In-Reply-To: <20260710014617.323acf6e@jic23-huawei>
On Fri, Jul 10, 2026 at 01:46:17AM +0100, Jonathan Cameron wrote:
> On Thu, 9 Jul 2026 10:50:14 +0200
> Janani Sunil <janani.sunil@analog.com> wrote:
>
> > Add support for enabling and disabling Cyclic Redundancy Check (CRC)
> > processing in the AXI ADC backend. CRC provides data integrity verification
> > for high-speed ADC data streams, ensuring reliable data transfer between
> > the ADC frontend and backend processing systems.
> >
> > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> The 'other things' I found bit from Sashiko is interesting. Far as I can
> tell it is right and [devm_]mutex_init() is missing for lock
> in struct adi_axi_adc_state().
>
Ouch! Yes, I was also wondering about the lock comment.
> Nuno, looks like it was from:
> 7ecb8ee5c93b ("iio: adc: adi-axi-adc: support digital interface calibration")
>
> Which indeed adds the lock with a mutex_init()
You mean without :)?
I'll send a patch fixing it!
- Nuno Sá
>
> Jonathan
>
> > static const struct iio_backend_info adi_axi_adc_generic = {
> >
>
^ permalink raw reply
* Re: What's cooking in zh_CN (Jul 2026)
From: Weijie Yuan @ 2026-07-14 14:03 UTC (permalink / raw)
To: Dongliang Mu
Cc: Alex Shi, Dongliang Mu, linux-doc, Alex Shi, Yanteng Si, Ben Guo,
Gary Guo, Yan Zhu, Doehyun Baek, Jiandong Qiu
In-Reply-To: <53ffbf05-7b2e-4ffa-945d-2a415e843cff@hust.edu.cn>
On Tue, Jul 14, 2026 at 09:14:38PM +0800, Dongliang Mu wrote:
> > Dongliang, is the dashboard you want exactly like the one I sent in this
> > email, which is read-only? Or perhaps wish there are other functions as
> > well. For example, you can mark the patch series you have reviewed.
>
> Actually I just need a list of patches which I need to review, which I
> reviewed before and be resubmitted, and which is applied.
OK, let me think about it for a night.
In the afternoon, I came up with a rather crude method, which is...
Simply directly upload the plain text of "What's cooking" to a website
with Git. But of course, it wasn't updated immediately. It required
manual update. Do you think automatic synchronization is important?
I guess it is expected that the implementation automatic synchronization
will not be too easy, if we want it perfect.
It's not too much trouble for me to update manually now, but I expect to
try using shell scripts to improve efficiency next.
> > I can't find what IMA is btw.
>
> https://ima.qq.com/
>
> It is closed-source software from Tencent. This software cannot solve our
> problem.
>
> I just put all the related linux-doc patches into the knowledge base, and
> ask in NLP about the activities in the linux-doc mailing list
Got it. I'll take a look though.
^ permalink raw reply
* Re: [RFC PATCH 1/7] iommu: Add group lookup by ID
From: Jason Gunthorpe @ 2026-07-14 14:03 UTC (permalink / raw)
To: Zhanpeng Zhang
Cc: joro, palmer, tony.luck, reinette.chatre, tomasz.jeznach, will,
robin.murphy, fustini, pjw, aou, alex, Dave.Martin, james.morse,
babu.moger, corbet, shuah, kevin.tian, cuiyunhui, yuanzhu, iommu,
linux-riscv, linux-kernel, linux-doc, linux-kselftest, x86
In-Reply-To: <20260714130657.46963-2-zhangzhanpeng.jasper@bytedance.com>
On Tue, Jul 14, 2026 at 09:06:51PM +0800, Zhanpeng Zhang wrote:
> Add iommu_group_get_by_id() so callers can resolve an IOMMU group from
> the numeric ID used in /sys/kernel/iommu_groups.
>
> An ID lookup must keep the group object alive without also keeping an
> otherwise empty group active. Embed the devices kobject in struct
> iommu_group so its address remains valid until the parent group is
> released, and return a reference on the parent kobject to ID lookup
> callers. Add iommu_group_put_by_id() to release that reference and
> iommu_group_is_active() to detect when the devices kobject has become
> inactive.
>
> Serialize lookup against group teardown with iommu_group_kset_mutex and
> only return groups whose devices kobject still has a live reference.
> This prevents a concurrent lookup from dereferencing a stale child
> kobject while allowing external users to discard bindings to empty
> groups.
>
> Signed-off-by: Zhanpeng Zhang <zhangzhanpeng.jasper@bytedance.com>
> ---
> drivers/iommu/iommu.c | 107 +++++++++++++++++++++++++++++++++++++-----
> include/linux/iommu.h | 17 +++++++
> 2 files changed, 113 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index e8f13dcebbde..da269d10f6bf 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -40,6 +40,7 @@
> #include "iommu-priv.h"
>
> static struct kset *iommu_group_kset;
> +static DEFINE_MUTEX(iommu_group_kset_mutex);
> static DEFINE_IDA(iommu_group_ida);
I think it would be better to change the ida to an xarray than to use
a string search on a kset..
Jason
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: Michael S. Tsirkin @ 2026-07-14 13:40 UTC (permalink / raw)
To: Simon Schippers
Cc: Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer,
Brett Sheffield, linux-doc, linux-kernel
In-Reply-To: <20260709095511.168235-1-simon.schippers@tu-dortmund.de>
On Thu, Jul 09, 2026 at 11:55:11AM +0200, Simon Schippers wrote:
> Commit 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop
> when a qdisc is present") did not show a relevant performance regression
> in my testing but on Brett Sheffield's librecast testbed it shows a
> significant performance drop in a IPv6 multicast testcase. The regression
> can be pinpointed when multiple iperf3 TCP threads are sending. For 8
> threads the performance dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is
> the reason why this patch makes the qdisc backpressure behavior opt-in.
>
> One option to accomplish the opt-in would be to set the default qdisc to
> noqueue at init. However this may also break userspace as users might
> have chosen a custom qdisc even though most of the qdiscs did nothing
> for tun/tap in the past due to missing backpressure...
>
> This is the reason why in this patch, the flag IFF_BACKPRESSURE is
> introduced instead which is required to enable the backpressure logic.
> This means the stopping logic in tun_net_xmit() and the waking logic in
> __tun_wake_queue() are skipped if the flag is disabled. Setting
> IFF_BACKPRESSURE makes an attached qdisc effective by stopping the queue
> instead of tail-dropping when the internal ring is full.
>
> To avoid a possible stall due to disabling IFF_BACKPRESSURE, the new
> helper tun_force_wake_queue() is implemented. The helper safely wakes the
> respective netdev queue and resets cons_cnt while the consumer_lock and
> the producer_lock of the ring are held. The helper is run in tun_attach()
> when a queue (re)attaches, in tun_set_iff() for attached tfiles, and
> in tun_queue_resize().
>
> The documentation in tuntap.rst is updated accordingly.
>
> Fixes: 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present")
> Reported-by: Brett Sheffield <brett@librecast.net>
> Closes: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/T/#u
> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
The patch itself is fine:
Acked-by: Michael S. Tsirkin <mst@redhat.com>
What bothers me is the timing: we
are past freeze and this new interface hasn't been tested
much.
We can either apply this, or revert the original patch for now
and reapply with this for next.
> ---
> V2 -> V3:
> - As suggested by MST: Clarify in tuntap.rst and the UAPI header what
> enabling IFF_BACKPRESSURE opts into: an attached qdisc becomes effective
> instead of the driver tail-dropping when the internal ring is full.
> - Avoid lines over 75 characters.
> - Update comment in tun_net_xmit() to include IFF_BACKPRESSURE.
> - Brett: Update in commit message that the referenced tests were TCP.
>
> V1 -> V2:
> - Sashiko: Ensure detached queues are woken on re-attach by calling the
> new tun_force_wake_queue() helper from tun_attach(), and reuse it
> across the existing wake paths.
> - Specify the failing test case in the commit message.
>
> V1: https://lore.kernel.org/netdev/20260704112058.95421-1-simon.schippers@tu-dortmund.de/T/#u
> V2: https://lore.kernel.org/netdev/20260706094242.115992-1-simon.schippers@tu-dortmund.de/T/#u
>
> Documentation/networking/tuntap.rst | 22 +++++++++++++
> drivers/net/tun.c | 51 ++++++++++++++++++++---------
> include/uapi/linux/if_tun.h | 4 +++
> tools/include/uapi/linux/if_tun.h | 1 +
> 4 files changed, 62 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/networking/tuntap.rst b/Documentation/networking/tuntap.rst
> index 4d7087f727be..5921a924c2ae 100644
> --- a/Documentation/networking/tuntap.rst
> +++ b/Documentation/networking/tuntap.rst
> @@ -206,6 +206,28 @@ enable is true we enable it, otherwise we disable it::
> return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
> }
>
> +3.4 qdisc backpressure
> +----------------------
> +
> +Starting with Linux 7.2, IFF_BACKPRESSURE can be set to enable qdisc
> +backpressure. Without it, TX drops occur when the internal ring buffer
> +is full, so any attached qdisc is effectively bypassed and applications
> +only learn about congestion through those drops.
> +
> +With it, the kernel stops instead, letting the qdisc hold and schedule
> +packets, so its AQM, shaping and fairness actually apply. This helps
> +protocols like TCP, which cut throughput in reaction to packet drops.
> +With IFF_BACKPRESSURE, drops then only occur as a rare race. Backpressure
> +requires a qdisc to be attached and has no effect with noqueue.
> +
> +The txqueuelen can be reduced alongside this flag to further shift
> +buffering into the qdisc and reduce bufferbloat, but comes at possible
> +performance cost.
> +
> +When running multiple network streams in parallel through a single
> +TUN/TAP queue, the flag may reduce performance due to the extra overhead
> +of the backpressure mechanism.
> +
> Universal TUN/TAP device driver Frequently Asked Question
> =========================================================
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index ffbe6f13fb1f..5941e8f302ea 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -98,7 +98,8 @@ static void tun_default_link_ksettings(struct net_device *dev,
> #define TUN_FASYNC IFF_ATTACH_QUEUE
>
> #define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
> - IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS)
> + IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS | \
> + IFF_BACKPRESSURE)
>
> #define GOODCOPY_LEN 128
>
> @@ -694,6 +695,20 @@ static void tun_detach_all(struct net_device *dev)
> module_put(THIS_MODULE);
> }
>
> +static void tun_force_wake_queue(struct tun_struct *tun,
> + struct tun_file *tfile)
> +{
> + /* Ensure that the producer can not stop the
> + * queue concurrently by taking locks.
> + */
> + spin_lock_bh(&tfile->tx_ring.consumer_lock);
> + spin_lock(&tfile->tx_ring.producer_lock);
> + netif_wake_subqueue(tun->dev, tfile->queue_index);
> + tfile->cons_cnt = 0;
> + spin_unlock(&tfile->tx_ring.producer_lock);
> + spin_unlock_bh(&tfile->tx_ring.consumer_lock);
> +}
> +
> static int tun_attach(struct tun_struct *tun, struct file *file,
> bool skip_filter, bool napi, bool napi_frags,
> bool publish_tun)
> @@ -737,11 +752,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file,
> goto out;
> }
>
> - spin_lock(&tfile->tx_ring.consumer_lock);
> - tfile->cons_cnt = 0;
> - spin_unlock(&tfile->tx_ring.consumer_lock);
> tfile->queue_index = tun->numqueues;
> tfile->socket.sk->sk_shutdown &= ~RCV_SHUTDOWN;
> + tun_force_wake_queue(tun, tfile);
>
> if (tfile->detached) {
> /* Re-attach detached tfile, updating XDP queue_index */
> @@ -1077,7 +1090,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>
> spin_lock(&tfile->tx_ring.producer_lock);
> ret = __ptr_ring_produce(&tfile->tx_ring, skb);
> - if (!qdisc_txq_has_no_queue(queue) &&
> + if ((tun->flags & IFF_BACKPRESSURE) &&
> + !qdisc_txq_has_no_queue(queue) &&
> __ptr_ring_check_produce(&tfile->tx_ring) == -ENOSPC) {
> netif_tx_stop_queue(queue);
> /* Paired with smp_mb() in __tun_wake_queue() */
> @@ -1088,8 +1102,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> spin_unlock(&tfile->tx_ring.producer_lock);
>
> if (ret) {
> - /* This should be a rare case if a qdisc is present, but
> - * can happen due to lltx.
> + /* This should be a rare case if IFF_BACKPRESSURE is enabled and
> + * a qdisc is present, but can happen due to lltx.
> * Since skb_tx_timestamp(), skb_orphan(),
> * run_ebpf_filter() and pskb_trim() could have tinkered
> * with the SKB, returning NETDEV_TX_BUSY is unsafe and
> @@ -2151,8 +2165,12 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> static void __tun_wake_queue(struct tun_struct *tun,
> struct tun_file *tfile, int consumed)
> {
> - struct netdev_queue *txq = netdev_get_tx_queue(tun->dev,
> - tfile->queue_index);
> + struct netdev_queue *txq;
> +
> + if (!(tun->flags & IFF_BACKPRESSURE))
> + return;
> +
> + txq = netdev_get_tx_queue(tun->dev, tfile->queue_index);
>
> /* Paired with smp_mb__after_atomic() in tun_net_xmit() */
> smp_mb();
> @@ -2764,7 +2782,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> struct tun_struct *tun;
> struct tun_file *tfile = file->private_data;
> struct net_device *dev;
> - int err;
> + int err, i;
>
> if (tfile->detached)
> return -EINVAL;
> @@ -2893,8 +2911,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> /* Make sure persistent devices do not get stuck in
> * xoff state.
> */
> - if (netif_running(tun->dev))
> - netif_tx_wake_all_queues(tun->dev);
> + if (netif_running(tun->dev)) {
> + for (i = 0; i < tun->numqueues; i++) {
> + tfile = rtnl_dereference(tun->tfiles[i]);
> + tun_force_wake_queue(tun, tfile);
> + }
> + }
>
> strscpy(ifr->ifr_name, tun->dev->name);
> return 0;
> @@ -3693,10 +3715,7 @@ static int tun_queue_resize(struct tun_struct *tun)
> if (!ret) {
> for (i = 0; i < tun->numqueues; i++) {
> tfile = rtnl_dereference(tun->tfiles[i]);
> - spin_lock(&tfile->tx_ring.consumer_lock);
> - netif_wake_subqueue(tun->dev, tfile->queue_index);
> - tfile->cons_cnt = 0;
> - spin_unlock(&tfile->tx_ring.consumer_lock);
> + tun_force_wake_queue(tun, tfile);
> }
> }
>
> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
> index 79d53c7a1ebd..a0ddc50a7534 100644
> --- a/include/uapi/linux/if_tun.h
> +++ b/include/uapi/linux/if_tun.h
> @@ -69,6 +69,10 @@
> #define IFF_NAPI_FRAGS 0x0020
> /* Used in TUNSETIFF to bring up tun/tap without carrier */
> #define IFF_NO_CARRIER 0x0040
> +/* Stop the queue instead of dropping when the internal ring is full, so an
> + * attached qdisc applies backpressure instead of being bypassed.
> + */
> +#define IFF_BACKPRESSURE 0x0080
> #define IFF_NO_PI 0x1000
> /* This flag has no real effect */
> #define IFF_ONE_QUEUE 0x2000
> diff --git a/tools/include/uapi/linux/if_tun.h b/tools/include/uapi/linux/if_tun.h
> index 2ec07de1d73b..97b670f5bc0a 100644
> --- a/tools/include/uapi/linux/if_tun.h
> +++ b/tools/include/uapi/linux/if_tun.h
> @@ -67,6 +67,7 @@
> #define IFF_TAP 0x0002
> #define IFF_NAPI 0x0010
> #define IFF_NAPI_FRAGS 0x0020
> +#define IFF_BACKPRESSURE 0x0080
> #define IFF_NO_PI 0x1000
> /* This flag has no real effect */
> #define IFF_ONE_QUEUE 0x2000
> --
> 2.43.0
^ permalink raw reply
* [PATCH v2] PCI: rcar-gen4: Isolate driver to ARM64
From: Marek Vasut @ 2026-07-14 13:19 UTC (permalink / raw)
To: linux-pci
Cc: Marek Vasut, kernel test robot, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, Yoshihiro Shimoda, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
The driver includes linux/irqchip/arm-gic-v3.h which pulls in headers
which are available only on ARM and ARM64, on other architectures the
headers are not present and the driver fails to build. This driver is
used only on ARM64 hardware, isolate its build only to ARM64 to avoid
build failures on other architectures.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
V2: This is a rework of PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
which isolates the driver build to ARM64 via Kconfig instead:
https://lore.kernel.org/linux-pci/CAMuHMdVvWE7YZgKvreSn_vJLOVD4eMmn3TCGOyqSXksqjBCwvg@mail.gmail.com/
https://lore.kernel.org/linux-pci/20260714110041.GA1349622@bhelgaas/
---
drivers/pci/controller/dwc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index 49a7a2c50ca15..3260d916110b2 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -346,7 +346,7 @@ config PCIE_RCAR_GEN4
config PCIE_RCAR_GEN4_HOST
tristate "Renesas R-Car Gen4 PCIe controller (host mode)"
- depends on ARCH_RENESAS || COMPILE_TEST
+ depends on ARM64 && (ARCH_RENESAS || COMPILE_TEST)
depends on PCI_MSI
select PCIE_DW_HOST
select PCIE_RCAR_GEN4
@@ -357,7 +357,7 @@ config PCIE_RCAR_GEN4_HOST
config PCIE_RCAR_GEN4_EP
tristate "Renesas R-Car Gen4 PCIe controller (endpoint mode)"
- depends on ARCH_RENESAS || COMPILE_TEST
+ depends on ARM64 && (ARCH_RENESAS || COMPILE_TEST)
depends on PCI_ENDPOINT
select PCIE_DW_EP
select PCIE_RCAR_GEN4
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
From: Marek Vasut @ 2026-07-14 13:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bjorn Helgaas, Marc Zyngier, linux-pci, kernel test robot,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring,
Yoshihiro Shimoda, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdVvWE7YZgKvreSn_vJLOVD4eMmn3TCGOyqSXksqjBCwvg@mail.gmail.com>
On 7/14/26 9:54 AM, Geert Uytterhoeven wrote:
Hello Geert,
>>>> So in the end, it is either this patch or limit the build to
>>>> arm/arm64 . At least this patch still allows building this driver
>>>> with more compilers on the various build bots, so I would opt for
>>>> this patch here.
>>>
>>> I like the build coverage, but duplicating the #define doesn't really
>>> seem good to me. It makes readability worse because cscope/tags now
>>> sees two definitions without an obvious reason.
>>
>> I can rename the macro, or ... sigh ... I can reduce the driver to build
>
> That would obfuscate the code?
>
>> only on ARM/ARM64. Which one do you prefer ?
>
> Just add the dependency for compile-testing, just like
> PCIE_IPROC_PLATFORM does.
I will send a V2 shortly.
^ permalink raw reply
* Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
From: Marek Vasut @ 2026-07-14 13:17 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Marc Zyngier, linux-pci, kernel test robot,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring,
Yoshihiro Shimoda, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260714110041.GA1349622@bhelgaas>
On 7/14/26 1:00 PM, Bjorn Helgaas wrote:
> On Mon, Jul 13, 2026 at 08:05:38PM +0200, Marek Vasut wrote:
>> On 7/13/26 7:54 PM, Bjorn Helgaas wrote:
>>> On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
>>>> On 7/10/26 10:30 AM, Marc Zyngier wrote:
>>>>> On Thu, 09 Jul 2026 21:10:03 +0100,
>>>>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>>>>>>
>>>>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
>>>>>> copy the one GITS_TRANSLATER register offset macro directly into
>>>>>> the driver. This repairs the ability to build the driver on
>>>>>> non-ARM non-GIC targets the way it was possible until now, which
>>>>>> retains good build test coverage.
>>>> ...
>>>
>>>> So in the end, it is either this patch or limit the build to
>>>> arm/arm64 . At least this patch still allows building this driver
>>>> with more compilers on the various build bots, so I would opt for
>>>> this patch here.
>>>
>>> I like the build coverage, but duplicating the #define doesn't really
>>> seem good to me. It makes readability worse because cscope/tags now
>>> sees two definitions without an obvious reason.
>>
>> I can rename the macro, or ... sigh ... I can reduce the driver to build
>> only on ARM/ARM64. Which one do you prefer ?
>
> I think a dependency on ARM/ARM64 is preferable.
I will send a V2 shortly.
^ permalink raw reply
* Re: [RFC PATCH] firmware: scmi: Make SCMI arch independent
From: Ulf Hansson @ 2026-07-14 13:16 UTC (permalink / raw)
To: Cristian Marussi
Cc: Michal Simek, linux-kernel, monstr, git, vincent.guittot,
Souvik.Chakravarty, Alex Shi, Andy Shevchenko,
Bartosz Golaszewski, Brian Masney, David Lechner, Dongliang Mu,
Fabio Estevam, Frank Li, Guenter Roeck, Jonathan Cameron,
Jonathan Corbet, Len Brown, Liam Girdwood, Linus Walleij,
Lukasz Luba, Mark Brown, Michael Turquette, Nuno Sá,
Pavel Machek, Peng Fan, Pengutronix Kernel Team, Philipp Zabel,
Rafael J. Wysocki, Sascha Hauer, Shuah Khan, Stephen Boyd,
Sudeep Holla, Ulf Hansson, Viresh Kumar, Yanteng Si, arm-scmi,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-arm-kernel, open list:COMMON CLK FRAMEWORK,
open list:DOCUMENTATION, open list:GPIO SUBSYSTEM,
open list:HARDWARE MONITORING,
open list:IIO SUBSYSTEM AND DRIVERS, open list:ENERGY MODEL
In-Reply-To: <ak_Eu_eQKalPMwo-@pluto>
On Thu, Jul 9, 2026 at 5:56 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
> On Thu, Jul 09, 2026 at 03:27:00PM +0200, Michal Simek wrote:
> > On heterogenious systems like AMD/Xilinx FPGA there is a need to talk to
> > SCMI server from different architectures than ARM that's why remove
> > ARM/ARM64 Kconfig dependency with also remove ARM from description and
> > rename folder to reflect it.
>
> While I understand dropping the dependency on ARM (I always wanted to do
> that and test if it worked at all on some otehr archs with QEMU), I am
> not sure about the whole renaming party ? why is needed just for
> cosmetic reasons ? it is at the end an arm originated protocol so I dont
> see it as a being wrong to be named as such even though used by other
> archs...I have not really strong opinion on this...
This is certainly not my call to make, but I have to admit that I
fully agree with the above.
Usually we don't rename files that indicate a legacy platform name,
just because a new company/platform wants to make use of it.
>
> ... my concern really is ... wont this full scale rename simply generate
> a lot of un-needed churn for future fixes and/or backporting ?
We have some git magic to overcome most of these problems, but it's
not always straightforward, I think.
>
> Thanks,
> Cristian
Kind regards
Uffe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox