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, Praanquoted
Alexquoted
+ +void vfio_pci_liveupdate_cleanup(void) +{ + if (!liveupdate_enabled()) + return; + + liveupdate_unregister_file_handler(&vfio_pci_liveupdate_fh); +}