Thread (119 messages) 119 messages, 10 authors, 2026-03-19

Re: [PATCH v2 04/22] vfio/pci: Register a file handler with Live Update Orchestrator

From: Pranjal Shrivastava <praan@google.com>
Date: 2026-02-25 22:29:52
Also in: kexec, kvm, linux-kselftest, linux-mm, linux-pci, lkml

On Wed, Feb 25, 2026 at 10:06:18PM +0000, Pranjal Shrivastava wrote:
On Wed, Feb 25, 2026 at 02:33:28PM -0700, Alex Williamson wrote:
quoted
On Thu, 29 Jan 2026 21:24:51 +0000
David Matlack [off-list ref] wrote:
quoted
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 0c771064c0b8..19e88322af2c 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -258,6 +258,10 @@ static int __init vfio_pci_init(void)
 	int ret;
 	bool is_disable_vga = true;
 
+	ret = vfio_pci_liveupdate_init();
+	if (ret)
+		return ret;
+
 #ifdef CONFIG_VFIO_PCI_VGA
 	is_disable_vga = disable_vga;
 #endif
@@ -266,8 +270,10 @@ static int __init vfio_pci_init(void)
 
 	/* Register and scan for devices */
 	ret = pci_register_driver(&vfio_pci_driver);
-	if (ret)
+	if (ret) {
+		vfio_pci_liveupdate_cleanup();
 		return ret;
+	}
 
 	vfio_pci_fill_ids();
 
@@ -281,6 +287,7 @@ 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..b84e63c0357b
--- /dev/null
+++ b/drivers/vfio/pci/vfio_pci_liveupdate.c
@@ -0,0 +1,69 @@
...
quoted
+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)
+{
+	if (!liveupdate_enabled())
+		return 0;
+
+	return liveupdate_register_file_handler(&vfio_pci_liveupdate_fh);
+}
liveupdate_register_file_handler() "pins" vfio-pci with a
try_module_get().  Since this is done in our module_init function and
unregister occurs in our module_exit function, rather than relative
to any actual device binding or usage, this means vfio-pci CANNOT be
unloaded.  That seems bad.  Thanks,
Hmm... IIUC the concern here is about liveupdate policy if the user 
wants to unload a module which was previously marked for preservation?

AFAICT, In such a case, the user is expected to close the LUO session FD,
which "unpreserves" the FD. Finally, when rmmod is executed, the __exit 
(vfio_pci_cleanup) calls vfio_pci_liveupdate_cleanup() which ends up 
calling liveupdate_unregister_file_handler(), thereby dropping the ref
held by the liveupdate orchestrator which allows the module to be
unloaded.
Ohh wait, You're right, Alex. I just realized the __exit won't even be 
reached because of the internal pin. The current implementation creates
a catch-22 where the module pins itself during init and can't reach the
unregister call in exit. I believe we should drop the ref when the user
closes the session FD? Additionally, should we move try_module_get out of
the global liveupdate_register_file_handler() and instead take the ref
only when a file is actually marked for preservation?

Thanks,
Praan
I think we should document this policy somewhere or have a dev_warn to
scream at the users when they try unloading the module without closing
the session FD.

Thanks,
Praan
quoted
Alex
quoted
+
+void vfio_pci_liveupdate_cleanup(void)
+{
+	if (!liveupdate_enabled())
+		return;
+
+	liveupdate_unregister_file_handler(&vfio_pci_liveupdate_fh);
+}
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help