PCI: liveupdate: PCI core support for Live Update

Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable it to participate in the preservation of PCI devices across Live Update. Essentially, this commit enables the PCI core to allocate a struct (struct pci_ser) and preserve it across a Live Update whenever at least one device is preserved.

Preserving PCI devices across Live Update is built on top of the Live Update Orchestrator's (LUO) support for file preservation. Drivers are expected to expose a file to userspace to represent a single PCI device and support preservation of that file. This is intended primarily to support preservation of PCI devices bound to VFIO drivers.

This commit enables drivers to register their liveupdate_file_handler with the PCI core so that the PCI core can do its own tracking and enforcement of which devices are preserved.

pci_liveupdate_register_flb(driver_file_handler); pci_liveupdate_unregister_flb(driver_file_handler);

When the first file (with a handler registered with the PCI core) is preserved, the PCI core will be notified to allocate its tracking struct (pci_ser). When the last file is unpreserved (i.e. preservation cancelled) the PCI core will be notified to free struct pci_ser.

This struct is preserved across a Live Update using KHO and can be fetched by the PCI core during early boot (e.g. during device enumeration) so that it knows which devices were preserved.

Note: This commit only allocates struct pci_ser and preserves it across Live Update. A subsequent commit will add an API for drivers to tell the PCI core exactly which devices are being preserved.

Note: There is no reason to check for kho_is_enabled() since it can be assumed to return true. If KHO was not enabled then Live Update would not be enabled and these routines would never run.

Reviewed-by Pranjal Shrivastava <[email protected]>

Signed-off-by David Matlack <[email protected]>

---

Documentation/core-api/liveupdate.rst |   4 +
MAINTAINERS                           |  13 +++
drivers/pci/Kconfig                   |  15 +++
drivers/pci/Makefile                  |   1 +
drivers/pci/liveupdate.c              | 158 ++++++++++++++++++++++++++
include/linux/kho/abi/pci.h           |  63 ++++++++++
include/linux/pci.h                   |   1 +
include/linux/pci_liveupdate.h        |  30 +++++
8 files changed, 285 insertions(+)

create mode 100644 drivers/pci/liveupdate.c
create mode 100644 include/linux/kho/abi/pci.h
create mode 100644 include/linux/pci_liveupdate.h

Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable it to participate in the preservation of PCI devices across Live Update. Essentially, this commit enables the PCI core to allocate a struct (struct pci_ser) and preserve it across a Live Update whenever at least one device is preserved.

Preserving PCI devices across Live Update is built on top of the Live Update Orchestrator's (LUO) support for file preservation. Drivers are expected to expose a file to userspace to represent a single PCI device and support preservation of that file. This is intended primarily to support preservation of PCI devices bound to VFIO drivers.

This commit enables drivers to register their liveupdate_file_handler with the PCI core so that the PCI core can do its own tracking and enforcement of which devices are preserved.

  pci_liveupdate_register_flb(driver_file_handler);
  pci_liveupdate_unregister_flb(driver_file_handler);

When the first file (with a handler registered with the PCI core) is preserved, the PCI core will be notified to allocate its tracking struct (pci_ser).

When the last file is unpreserved (i.e. preservation cancelled) the PCI core will be notified to free struct pci_ser.

This struct is preserved across a Live Update using KHO and can be fetched by the PCI core during early boot (e.g. during device enumeration) so that it knows which devices were preserved.

Note: This commit only allocates struct pci_ser and preserves it across Live Update. A subsequent commit will add an API for drivers to tell the PCI core exactly which devices are being preserved.

Note: There is no reason to check for kho_is_enabled() since it can be assumed to return true. If KHO was not enabled then Live Update would not be enabled and these routines would never run.

Reviewed-by Pranjal Shrivastava <[email protected]>

Signed-off-by David Matlack <[email protected]>

---
 Documentation/core-api/liveupdate.rst |   4 +
 MAINTAINERS                           |  13 +++
 drivers/pci/Kconfig                   |  15 +++
 drivers/pci/Makefile                  |   1 +
 drivers/pci/liveupdate.c              | 158 ++++++++++++++++++++++++++
 include/linux/kho/abi/pci.h           |  63 ++++++++++
 include/linux/pci.h                   |   1 +
 include/linux/pci_liveupdate.h        |  30 +++++
 8 files changed, 285 insertions(+)
 create mode 100644 drivers/pci/liveupdate.c
 create mode 100644 include/linux/kho/abi/pci.h
 create mode 100644 include/linux/pci_liveupdate.h

Documentation/core-api/liveupdate.rst +4 -0

index 5a292d0f3706..b3c689e633c1 100644
@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
+.. _luo:
+
 ========================
 Live Update Orchestrator
 ========================

@@ -18,6 +20,8 @@ LUO Preserving File Descriptors
 .. kernel-doc:: kernel/liveupdate/luo_file.c
    :doc: LUO File Descriptors
 
+.. _flb:
+
 LUO File Lifecycle Bound Global Data
 ====================================
 .. kernel-doc:: kernel/liveupdate/luo_flb.c

MAINTAINERS +13 -0

index a3ed337e827d..9cc7b9291ace 100644
@@ -20824,6 +20824,19 @@ L:	[email protected]
 S:	Supported
 F:	Documentation/PCI/pci-error-recovery.rst
 
+PCI LIVE UPDATE
+M:	David Matlack <[email protected]>
+R:	Pasha Tatashin <[email protected]>
+R:	Mike Rapoport <[email protected]>
+R:	Pratyush Yadav <[email protected]>
+L:	[email protected]
+L:	[email protected]
+S:	Maintained
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
+F:	drivers/pci/liveupdate.c
+F:	include/linux/kho/abi/pci.h
+F:	include/linux/pci_liveupdate.h
+
 PCI MSI DRIVER FOR ALTERA MSI IP
 L:	[email protected]
 S:	Orphan

drivers/pci/Kconfig +15 -0

index 0c7408509ba2..3781e2b5f095 100644
@@ -271,6 +271,21 @@ config VGA_ARB_MAX_GPUS
 	  Reserves space in the kernel to maintain resource locking for
 	  multiple GPUS.  The overhead for each GPU is very small.
 
+config PCI_LIVEUPDATE
+	bool "PCI Live Update Support"
+	depends on PCI && LIVEUPDATE
+	help
+	  Enable PCI core support for preserving PCI devices across Live
+	  Update. This, in combination with support in a device's driver,
+	  enables PCI devices to run and perform memory transactions
+	  uninterrupted during a kexec for Live Update.
+
+	  This option should only be enabled by users who plan to use Live
+	  Update for kernel upgrades and require preserving PCI devices during
+	  those upgrades.
+
+	  If unsure, say N.
+
 source "drivers/pci/hotplug/Kconfig"
 source "drivers/pci/controller/Kconfig"
 source "drivers/pci/endpoint/Kconfig"

drivers/pci/Makefile +1 -0

index 41ebc3b9a518..e8d003cb6757 100644
@@ -16,6 +16,7 @@ obj-$(CONFIG_PROC_FS)		+= proc.o
 obj-$(CONFIG_SYSFS)		+= pci-sysfs.o slot.o
 obj-$(CONFIG_ACPI)		+= pci-acpi.o
 obj-$(CONFIG_GENERIC_PCI_IOMAP) += iomap.o
+obj-$(CONFIG_PCI_LIVEUPDATE)	+= liveupdate.o
 endif
 
 obj-$(CONFIG_OF)		+= of.o

drivers/pci/liveupdate.c new file +158 -0

new file mode 100644
index 000000000000..fffb41a66ca7
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright (c) 2026, Google LLC.
+ * David Matlack <[email protected]>
+ */
+
+/**
+ * DOC: PCI Live Update
+ *
+ * The PCI subsystem participates in the Live Update process to enable drivers
+ * to preserve their PCI devices across kexec.
+ *
+ * :ref:`FLB <flb>` Data
+ * =====================
+ *
+ * PCI device preservation across Live Update is built on top of the
+ * :ref:`LUO <luo>` support for file preservation across kexec. Drivers are
+ * expected to expose a file to represent a single PCI device and support
+ * preservation of that file with ``ioctl(LIVEUPDATE_SESSION_PRESERVE_FD)``.
+ * This allows userspace to control the preservation of devices and ensure
+ * proper lifecycle management while a device is preserved. The first intended
+ * use-case is preserving vfio-pci device files.
+ *
+ * The PCI core maintains its own state about what devices are being preserved
+ * across Live Update using FLB data in LUO. Essentially, this allows the PCI
+ * core to allocate struct pci_ser when the first device (file) is preserved
+ * and free it when the last device (file) is unpreserved. After kexec, the
+ * PCI core can fetch the struct pci_ser (which was constructed by the previous
+ * kernel) from LUO at any time (e.g. during enumeration) so that it knows
+ * which devices were preserved.
+ *
+ * To enable the PCI core to be notified whenever a file representing a device
+ * is preserved, drivers must register their struct liveupdate_file_handler with
+ * the PCI core by using the following APIs:
+ *
+ *  * ``pci_liveupdate_register_flb(driver_file_handler)``
+ *  * ``pci_liveupdate_unregister_flb(driver_file_handler)``
+ */
+
+#define pr_fmt(fmt) "PCI: liveupdate: " fmt
+
+#include <linux/io.h>
+#include <linux/kexec_handover.h>
+#include <linux/kho/abi/pci.h>
+#include <linux/kho_block.h>
+#include <linux/liveupdate.h>
+#include <linux/mm.h>
+#include <linux/mutex.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+
+/**
+ * struct pci_flb_outgoing - Outgoing PCI FLB object
+ * @ser: Pointer to the preserved struct pci_ser.
+ * @block_set: The KHO block set holding the outgoing devices.
+ *
+ * This structure holds the runtime state for the outgoing PCI Live Update
+ * state. It wraps the serialized pci_ser and the block_set used to manage
+ * the serialized entries.
+ */
+struct pci_flb_outgoing {
+	struct pci_ser *ser;
+	struct kho_block_set block_set;
+};
+
+static int pci_flb_preserve(struct liveupdate_flb_op_args *args)
+{
+	struct pci_flb_outgoing *outgoing __free(kfree) = NULL;
+	struct pci_ser *ser;
+
+	outgoing = kzalloc_obj(*outgoing);
+	if (!outgoing)
+		return -ENOMEM;
+
+	ser = kho_alloc_preserve(sizeof(*ser));
+	if (IS_ERR(ser))
+		return PTR_ERR(ser);
+
+	ser->version = PCI_LUO_FLB_VERSION;
+	ser->nr_devices = 0;
+	ser->devices = 0;
+
+	outgoing->ser = ser;
+	kho_block_set_init(&outgoing->block_set, sizeof(struct pci_dev_ser));
+
+	args->obj = no_free_ptr(outgoing);
+	args->data = virt_to_phys(ser);
+	pr_debug("Preserved struct pci_ser (0x%llx)\n", args->data);
+	return 0;
+}
+
+static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)
+{
+	struct pci_flb_outgoing *outgoing = args->obj;
+
+	pr_debug("Unpreserving struct pci_ser (0x%llx)\n", args->data);
+
+	WARN_ON(outgoing->ser->nr_devices);
+	kho_block_set_destroy(&outgoing->block_set);
+	kho_unpreserve_free(outgoing->ser);
+	kfree(outgoing);
+}
+
+static int pci_flb_retrieve(struct liveupdate_flb_op_args *args)
+{
+	pr_debug("Retrieving struct pci_ser (0x%llx)\n", args->data);
+	args->obj = phys_to_virt(args->data);
+	return 0;
+}
+
+static void pci_flb_finish(struct liveupdate_flb_op_args *args)
+{
+	pr_debug("Finished struct pci_ser (0x%llx)\n", args->data);
+	kho_restore_free(args->obj);
+}
+
+static struct liveupdate_flb_ops pci_liveupdate_flb_ops = {
+	.preserve = pci_flb_preserve,
+	.unpreserve = pci_flb_unpreserve,
+	.retrieve = pci_flb_retrieve,
+	.finish = pci_flb_finish,
+	.owner = THIS_MODULE,
+};
+
+static struct liveupdate_flb pci_liveupdate_flb = {
+	.ops = &pci_liveupdate_flb_ops,
+	.compatible = PCI_LUO_FLB_COMPATIBLE,
+};
+
+/**
+ * pci_liveupdate_register_flb() - Register a file handler with the PCI core
+ * @fh: The file handler to register.
+ *
+ * Drivers should call pci_liveupdate_register_flb() to register their
+ * struct liveupdate_file_handler with the PCI core. This enables the PCI core
+ * to allocate its outgoing struct pci_ser whenever the first device is
+ * preserved, and free it when the last device is unpreserved.
+ *
+ * Return: 0 on success, <0 on failure.
+ */
+int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
+{
+	pr_debug("Registering file handler \"%s\"\n", fh->compatible);
+	return liveupdate_register_flb(fh, &pci_liveupdate_flb);
+}
+EXPORT_SYMBOL_GPL(pci_liveupdate_register_flb);
+
+/**
+ * pci_liveupdate_unregister_flb() - Unregister a file handler with the PCI core
+ * @fh: The file handler to unregister.
+ */
+void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh)
+{
+	pr_debug("Unregistering file handler \"%s\"\n", fh->compatible);
+	liveupdate_unregister_flb(fh, &pci_liveupdate_flb);
+}
+EXPORT_SYMBOL_GPL(pci_liveupdate_unregister_flb);

include/linux/kho/abi/pci.h new file +63 -0

new file mode 100644
index 000000000000..d4881c2d2fc9
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+/*
+ * Copyright (c) 2026, Google LLC.
+ * David Matlack <[email protected]>
+ */
+
+#ifndef _LINUX_KHO_ABI_PCI_H
+#define _LINUX_KHO_ABI_PCI_H
+
+#include <linux/bug.h>
+#include <linux/compiler.h>
+#include <linux/types.h>
+
+/**
+ * DOC: PCI File-Lifecycle Bound (FLB) Live Update ABI
+ *
+ * This header defines the ABI for preserving core PCI state across kexec using
+ * Live Update File-Lifecycle Bound (FLB) data.
+ *
+ * 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 PCI_LUO_FLB_VERSION number.
+ */
+
+#define PCI_LUO_FLB_COMPATIBLE "pci"
+#define PCI_LUO_FLB_VERSION 1
+
+/**
+ * struct pci_dev_ser - Serialized state about a single PCI device.
+ *
+ * @domain: The device's PCI domain number (segment).
+ * @bdf: The device's PCI bus, device, and function number.
+ * @refcount: Reference count used by the PCI core to keep track of whether it
+ *            is done using a device's struct pci_dev_ser. The value of the
+ *            refcount is equal to 1 when the struct pci_dev_ser is in use, and
+ *            0 otherwise.
+ */
+struct pci_dev_ser {
+	u32 domain;
+	u16 bdf;
+	u16 refcount;
+} __packed;
+
+/**
+ * struct pci_ser - PCI Subsystem Live Update State
+ *
+ * This struct tracks state about all devices that are being preserved across
+ * a Live Update for the next kernel.
+ *
+ * @version: The version of the "pci" FLB struct. This field must never be
+ *           deleted, moved, or resized, as the kernel depends on always being
+ *           able to check the struct pci_ser version number.
+ * @nr_devices: The number of devices that were preserved.
+ * @devices: Physical address of the first KHO block containing pci_dev_ser.
+ */
+struct pci_ser {
+	u32 version;
+	u32 nr_devices;
+	u64 devices;
+} __packed;
+
+#endif /* _LINUX_KHO_ABI_PCI_H */

include/linux/pci.h +1 -0

index ebb5b9d76360..da58aa101e4c 100644
@@ -43,6 +43,7 @@
 #include <uapi/linux/pci.h>
 
 #include <linux/pci_ids.h>
+#include <linux/pci_liveupdate.h>
 
 #define PCI_STATUS_ERROR_BITS (PCI_STATUS_DETECTED_PARITY  | \
 			       PCI_STATUS_SIG_SYSTEM_ERROR | \

include/linux/pci_liveupdate.h new file +30 -0

new file mode 100644
index 000000000000..8ec98beefcb4
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * PCI Live Update support (Public/Driver API)
+ *
+ * Copyright (c) 2026, Google LLC.
+ * David Matlack <[email protected]>
+ */
+#ifndef LINUX_PCI_LIVEUPDATE_H
+#define LINUX_PCI_LIVEUPDATE_H
+
+#include <linux/liveupdate.h>
+#include <linux/types.h>
+
+struct pci_dev;
+
+#ifdef CONFIG_PCI_LIVEUPDATE
+int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh);
+void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh);
+#else
+static inline int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh)
+{
+}
+#endif
+
+#endif /* LINUX_PCI_LIVEUPDATE_H */

Signature · 1 line

2.55.0.487.gaf234c4eb3-goog

Quoted 5 lines · David Matlack

Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable it to participate in the preservation of PCI devices across Live Update. Essentially, this commit enables the PCI core to allocate a struct (struct pci_ser) and preserve it across a Live Update whenever at least one device is preserved.

I assume pci_ser is the state the PCI core needs to preserve across kexec so the new kernel's enumeration doesn't interrupt the device operation. And that whatever state the endpoint drivers need to adopt/inherit the device in the new kernel is managed without any help from the PCI core?

Quoted 5 lines

Preserving PCI devices across Live Update is built on top of the Live Update Orchestrator's (LUO) support for file preservation. Drivers are expected to expose a file to userspace to represent a single PCI device and support preservation of that file. This is intended primarily to support preservation of PCI devices bound to VFIO drivers.

Where do drivers expose this file? sysfs? I guess it's a file per preserved device? Thinking like a driver writer, I'm expecting a hint about how to expose this file (should also be in the file doc somehere if it's not already).

Quoted 7 lines

This commit enables drivers to register their liveupdate_file_handler with the PCI core so that the PCI core can do its own tracking and enforcement of which devices are preserved.

  pci_liveupdate_register_flb(driver_file_handler);
  pci_liveupdate_unregister_flb(driver_file_handler);

So a driver calls pci_liveupdate_register_flb() once, then pci_liveupdate_preserve() once for each device it wants preserved?

Quoted 3 lines

When the first file (with a handler registered with the PCI core) is preserved, the PCI core will be notified to allocate its tracking struct (pci_ser).

The passive voice here makes the actors a bit obscure. I guess a LIVEUPDATE_SESSION_PRESERVE_FD ioctl on some per-device file kicks this off?

I guess the pci_ser allocation is in pci_liveupdate_flb_ops.preserve(), i.e., pci_flb_preserve()?

So the PCI core tracker (pci_ser) isn't actually allocated at the time of pci_liveupdate_register_flb(); it's allocated on the first LIVEUPDATE_SESSION_PRESERVE_FD ioctl for a driver that has called pci_liveupdate_register_flb()?

IIUC the call tree for that ioctl looks something like this:

<driver>
pci_liveupdate_register_flb
liveupdate_register_flb(fh, &pci_liveupdate_flb)

luo_session_ioctl

    op = &luo_session_ioctl_ops[...]
    op->execute                               # eg luo_session_preserve_fd()
      luo_session_preserve_fd
        luo_preserve_file
          luo_flb_file_preserve
            luo_flb_file_preserve_one
              if (outgoing_count == 0)        # only for first FLB device
                flb->ops->preserve            # eg pci_flb_preserve()
                  pci_flb_preserve
                    ser = kho_alloc_preserve  <-- alloc pci_ser
                outgoing.count = 1
          fh->ops->preserve                   # something not included here

pci_liveupdate_preserve
pci_liveupdate_preserve_device
dev_ser = pci_flb_alloc_dev_ser <-- alloc per-dev PCI core serialized state dev_ser->bdf = pci_dev_id(dev)

Seems like kind of an awkward way to allocate pci_ser. Couldn't it be allocated on the first call to pci_liveupdate_register_flb()? That would be a lot easier for driver writers to trace through.

Quoted 2 lines

When the last file is unpreserved (i.e. preservation cancelled) the PCI core will be notified to free struct pci_ser.

There's a lot going on behind "PCI core will be notified". I assume these refer to the first-time behavior of luo_flb_file_preserve_one() and last-time behavior of liveupdate_flb_put_outgoing(), which is honestly kind of hard to suss out.

This series doesn't include a caller of pci_liveupdate_preserve() (or pci_liveupdate_register_flb()), so I can't figure out the ordering. Obviously pci_liveupdate_register_flb() must be first.

I first thought pci_liveupdate_preserve() would be called via the fh->ops->preserve() in the luo_session_preserve_fd() ioctl path, but it's not. pci_liveupdate_preserve() is intended for the driver to call it directly. But it looks like it has to be called *after* the ioctl? Obviously I'm confused :)

Quoted 7 lines · Bjorn Helgaas

Quoted 5 lines · David Matlack

Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable it to participate in the preservation of PCI devices across Live Update. Essentially, this commit enables the PCI core to allocate a struct (struct pci_ser) and preserve it across a Live Update whenever at least one device is preserved.

Quoted 5 lines

I assume pci_ser is the state the PCI core needs to preserve across kexec so the new kernel's enumeration doesn't interrupt the device operation. And that whatever state the endpoint drivers need to adopt/inherit the device in the new kernel is managed without any help from the PCI core?

Yes.

Quoted 10 lines

Quoted 5 lines

Preserving PCI devices across Live Update is built on top of the Live Update Orchestrator's (LUO) support for file preservation. Drivers are expected to expose a file to userspace to represent a single PCI device and support preservation of that file. This is intended primarily to support preservation of PCI devices bound to VFIO drivers.

Where do drivers expose this file? sysfs? I guess it's a file per preserved device? Thinking like a driver writer, I'm expecting a hint about how to expose this file (should also be in the file doc somehere if it's not already).

There is no requirement about how drivers do this from the PCI core perspective. For all intents and purposes, the VFIO PCI variant drivers are the only drivers that are going to be supported in the next 1-2 years. They expose a misc character device for each file.

Quoted 9 lines

Quoted 6 lines

This commit enables drivers to register their liveupdate_file_handler with the PCI core so that the PCI core can do its own tracking and enforcement of which devices are preserved.

  pci_liveupdate_register_flb(driver_file_handler);
  pci_liveupdate_unregister_flb(driver_file_handler);

So a driver calls pci_liveupdate_register_flb() once, then pci_liveupdate_preserve() once for each device it wants preserved?

Yes

Quoted 7 lines

Quoted 3 lines

When the first file (with a handler registered with the PCI core) is preserved, the PCI core will be notified to allocate its tracking struct (pci_ser).

The passive voice here makes the actors a bit obscure. I guess a LIVEUPDATE_SESSION_PRESERVE_FD ioctl on some per-device file kicks this off?

Yes. (And I will reduce the passive voice in the next version.)

Quoted 2 lines

I guess the pci_ser allocation is in pci_liveupdate_flb_ops.preserve(), i.e., pci_flb_preserve()?

Yes.

Quoted 4 lines

So the PCI core tracker (pci_ser) isn't actually allocated at the time of pci_liveupdate_register_flb(); it's allocated on the first LIVEUPDATE_SESSION_PRESERVE_FD ioctl for a driver that has called pci_liveupdate_register_flb()?

Yes. The first device that gets preserved triggers the allocation of struct pci_ser. And the last device that gets unpreserved (preservation cancelled) triggers the freeing of struct pci_ser.

Quoted 19 lines

IIUC the call tree for that ioctl looks something like this:

<driver>
pci_liveupdate_register_flb
liveupdate_register_flb(fh, &pci_liveupdate_flb)

luo_session_ioctl

    op = &luo_session_ioctl_ops[...]
    op->execute                               # eg luo_session_preserve_fd()
      luo_session_preserve_fd
        luo_preserve_file
          luo_flb_file_preserve
            luo_flb_file_preserve_one
              if (outgoing_count == 0)        # only for first FLB device
                flb->ops->preserve            # eg pci_flb_preserve()
                  pci_flb_preserve
                    ser = kho_alloc_preserve  <-- alloc pci_ser
                outgoing.count = 1
          fh->ops->preserve                   # something not included here

Quoted 3 lines

Seems like kind of an awkward way to allocate pci_ser. Couldn't it be allocated on the first call to pci_liveupdate_register_flb()? That would be a lot easier for driver writers to trace through.

I agree the LUO FLB API is a bit awkward, but this is how it works.

If we allocated it during pci_liveupdate_register_flb() we would then need to stash it in a global variable to hand-off the LUO later. Despite the awkwardness of FLBs, it is useful to avoid globals and have LUO management the lifetime.

Quoted 7 lines

Quoted 2 lines

When the last file is unpreserved (i.e. preservation cancelled) the PCI core will be notified to free struct pci_ser.

There's a lot going on behind "PCI core will be notified". I assume these refer to the first-time behavior of luo_flb_file_preserve_one() and last-time behavior of liveupdate_flb_put_outgoing(), which is honestly kind of hard to suss out.

Quoted 3 lines

This series doesn't include a caller of pci_liveupdate_preserve() (or pci_liveupdate_register_flb()), so I can't figure out the ordering. Obviously pci_liveupdate_register_flb() must be first.

In every version of this patch series I have sent I included a link to the vfio-pci driver changes that build on top of this, rebased that series on top of this one, uploaded it to my GitHub, and included a link in the cover letter. Here is the relevant section from the v8 cover letter:

. This series was tested in conjunction with v5 of the VFIO PCI driver . series:
.
. https://lore.kernel.org/kvm/[email protected]/
.
. The full set of patches used for testing can be found on GitHub. .
. https://github.com/dmatlack/linux/tree/liveupdate/pci/base/v8-with-vfio

Quoted 5 lines

I first thought pci_liveupdate_preserve() would be called via the fh->ops->preserve() in the luo_session_preserve_fd() ioctl path, but it's not. pci_liveupdate_preserve() is intended for the driver to call it directly. But it looks like it has to be called *after* the ioctl? Obviously I'm confused :)

It is called by the driver during it's fh->ops->preserve() callback. In other words, it is called during the ioctl by the driver.

LUO just knows that a file has been preserved and what preserve() callback it needs to run to preserve that file. It is has no idea which files correspond to devices or which devices. The file could be a memfd for all LUO knows. That's why the driver has to call into the PCI core via pci_liveupdate_preserve() to let it know that a device is being preserved, and which.

Quoted 27 lines · David Matlack

Quoted 7 lines · Bjorn Helgaas

Quoted 5 lines · David Matlack

Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable it to participate in the preservation of PCI devices across Live Update. Essentially, this commit enables the PCI core to allocate a struct (struct pci_ser) and preserve it across a Live Update whenever at least one device is preserved.

Quoted 5 lines

I assume pci_ser is the state the PCI core needs to preserve across kexec so the new kernel's enumeration doesn't interrupt the device operation. And that whatever state the endpoint drivers need to adopt/inherit the device in the new kernel is managed without any help from the PCI core?

Yes.

Quoted 10 lines

Quoted 5 lines

Preserving PCI devices across Live Update is built on top of the Live Update Orchestrator's (LUO) support for file preservation. Drivers are expected to expose a file to userspace to represent a single PCI device and support preservation of that file. This is intended primarily to support preservation of PCI devices bound to VFIO drivers.

Where do drivers expose this file? sysfs? I guess it's a file per preserved device? Thinking like a driver writer, I'm expecting a hint about how to expose this file (should also be in the file doc somehere if it's not already).

Quoted 4 lines

There is no requirement about how drivers do this from the PCI core perspective. For all intents and purposes, the VFIO PCI variant drivers are the only drivers that are going to be supported in the next 1-2 years. They expose a misc character device for each file.

If this file isn't relevant to the PCI core, maybe we don't need to mention it here. It doesn't seem like it motivates this patch.

Quoted 27 lines

Quoted 9 lines

Quoted 6 lines

This commit enables drivers to register their liveupdate_file_handler with the PCI core so that the PCI core can do its own tracking and enforcement of which devices are preserved.

  pci_liveupdate_register_flb(driver_file_handler);
  pci_liveupdate_unregister_flb(driver_file_handler);

So a driver calls pci_liveupdate_register_flb() once, then pci_liveupdate_preserve() once for each device it wants preserved?

Yes

Quoted 7 lines

Quoted 3 lines

When the first file (with a handler registered with the PCI core) is preserved, the PCI core will be notified to allocate its tracking struct (pci_ser).

The passive voice here makes the actors a bit obscure. I guess a LIVEUPDATE_SESSION_PRESERVE_FD ioctl on some per-device file kicks this off?

Yes. (And I will reduce the passive voice in the next version.)

Quoted 2 lines

I guess the pci_ser allocation is in pci_liveupdate_flb_ops.preserve(), i.e., pci_flb_preserve()?

Yes.

Quoted 28 lines

Quoted 4 lines

So the PCI core tracker (pci_ser) isn't actually allocated at the time of pci_liveupdate_register_flb(); it's allocated on the first LIVEUPDATE_SESSION_PRESERVE_FD ioctl for a driver that has called pci_liveupdate_register_flb()?

Yes. The first device that gets preserved triggers the allocation of struct pci_ser. And the last device that gets unpreserved (preservation cancelled) triggers the freeing of struct pci_ser.

Quoted 19 lines

IIUC the call tree for that ioctl looks something like this:

<driver>
pci_liveupdate_register_flb
liveupdate_register_flb(fh, &pci_liveupdate_flb)

luo_session_ioctl

    op = &luo_session_ioctl_ops[...]
    op->execute                               # eg luo_session_preserve_fd()
      luo_session_preserve_fd
        luo_preserve_file
          luo_flb_file_preserve
            luo_flb_file_preserve_one
              if (outgoing_count == 0)        # only for first FLB device
                flb->ops->preserve            # eg pci_flb_preserve()
                  pci_flb_preserve
                    ser = kho_alloc_preserve  <-- alloc pci_ser
                outgoing.count = 1
          fh->ops->preserve                   # something not included here

So IIUC this part of the path looks like this, which answers my question below about ordering of pci_ser and pci_liveupdate_preserve():

              fh->ops->preserve                   # eg vfio_pci_liveupdate_preserve()
                vfio_pci_liveupdate_preserve
                  pci_liveupdate_preserve
                    pci_liveupdate_preserve_device
                      dev_ser = pci_flb_alloc_dev_ser  <-- alloc per-dev PCI core serialized state
                      dev_ser->bdf = pci_dev_id(dev)

Quoted 10 lines

Quoted 3 lines

Seems like kind of an awkward way to allocate pci_ser. Couldn't it be allocated on the first call to pci_liveupdate_register_flb()? That would be a lot easier for driver writers to trace through.

I agree the LUO FLB API is a bit awkward, but this is how it works.

If we allocated it during pci_liveupdate_register_flb() we would then need to stash it in a global variable to hand-off the LUO later. Despite the awkwardness of FLBs, it is useful to avoid globals and have LUO management the lifetime.

It seems like pci_ser is a singleton by design, so a global variable doesn't sound like it would be terrible to me.

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

When the last file is unpreserved (i.e. preservation cancelled) the PCI core will be notified to free struct pci_ser.

There's a lot going on behind "PCI core will be notified". I assume these refer to the first-time behavior of luo_flb_file_preserve_one() and last-time behavior of liveupdate_flb_put_outgoing(), which is honestly kind of hard to suss out.

Could we say something specific and PCI-related here, to help connect the dots? Most of these paths are outside the PCI core.

IIUC luo_session essentially has a refcount (outgoing.count) incremented by each LIVEUPDATE_SESSION_PRESERVE_FD ioctl, and the 0->1 transition in luo_flb_file_preserve_one() ends up calling pci_flb_preserve(), where pci_ser is allocated.

And the refcount is decremented by luo_flb_file_unpreserve() (in a luo_session .release() function), where the 1->0 transition in liveupdate_flb_put_outgoing() calls pci_flb_unpreserve() where pci_ser is deallocated.

That gets into a lot of detail, probably too much for a commit log. Maybe mentioning the function names by which the PCI core is notified to alloc/free pci_ser would be enough of a bread crumb.

Quoted 26 lines

Quoted 3 lines

This series doesn't include a caller of pci_liveupdate_preserve() (or pci_liveupdate_register_flb()), so I can't figure out the ordering. Obviously pci_liveupdate_register_flb() must be first.

In every version of this patch series I have sent I included a link to the vfio-pci driver changes that build on top of this, rebased that series on top of this one, uploaded it to my GitHub, and included a link in the cover letter. Here is the relevant section from the v8 cover letter:

. This series was tested in conjunction with v5 of the VFIO PCI driver . series:
.
. https://lore.kernel.org/kvm/[email protected]/
.
. The full set of patches used for testing can be found on GitHub. .
. https://github.com/dmatlack/linux/tree/liveupdate/pci/base/v8-with-vfio

Quoted 5 lines

I first thought pci_liveupdate_preserve() would be called via the fh->ops->preserve() in the luo_session_preserve_fd() ioctl path, but it's not. pci_liveupdate_preserve() is intended for the driver to call it directly. But it looks like it has to be called *after* the ioctl? Obviously I'm confused :)

Quoted 2 lines

It is called by the driver during it's fh->ops->preserve() callback. In other words, it is called during the ioctl by the driver.

I think the updated call tree above shows the connection?

Quoted 168 lines · Bjorn Helgaas

Quoted 27 lines · David Matlack

Quoted 7 lines · Bjorn Helgaas

Quoted 5 lines · David Matlack

Set up a File-Lifecycle-Bound (FLB) handler for the PCI core to enable it to participate in the preservation of PCI devices across Live Update. Essentially, this commit enables the PCI core to allocate a struct (struct pci_ser) and preserve it across a Live Update whenever at least one device is preserved.

Quoted 5 lines

I assume pci_ser is the state the PCI core needs to preserve across kexec so the new kernel's enumeration doesn't interrupt the device operation. And that whatever state the endpoint drivers need to adopt/inherit the device in the new kernel is managed without any help from the PCI core?

Yes.

Quoted 10 lines

Quoted 5 lines

Preserving PCI devices across Live Update is built on top of the Live Update Orchestrator's (LUO) support for file preservation. Drivers are expected to expose a file to userspace to represent a single PCI device and support preservation of that file. This is intended primarily to support preservation of PCI devices bound to VFIO drivers.

Where do drivers expose this file? sysfs? I guess it's a file per preserved device? Thinking like a driver writer, I'm expecting a hint about how to expose this file (should also be in the file doc somehere if it's not already).

Quoted 4 lines

There is no requirement about how drivers do this from the PCI core perspective. For all intents and purposes, the VFIO PCI variant drivers are the only drivers that are going to be supported in the next 1-2 years. They expose a misc character device for each file.

If this file isn't relevant to the PCI core, maybe we don't need to mention it here. It doesn't seem like it motivates this patch.

Quoted 27 lines

Quoted 9 lines

Quoted 6 lines

This commit enables drivers to register their liveupdate_file_handler with the PCI core so that the PCI core can do its own tracking and enforcement of which devices are preserved.

  pci_liveupdate_register_flb(driver_file_handler);
  pci_liveupdate_unregister_flb(driver_file_handler);

So a driver calls pci_liveupdate_register_flb() once, then pci_liveupdate_preserve() once for each device it wants preserved?

Yes

Quoted 7 lines

Quoted 3 lines

When the first file (with a handler registered with the PCI core) is preserved, the PCI core will be notified to allocate its tracking struct (pci_ser).

The passive voice here makes the actors a bit obscure. I guess a LIVEUPDATE_SESSION_PRESERVE_FD ioctl on some per-device file kicks this off?

Yes. (And I will reduce the passive voice in the next version.)

Quoted 2 lines

I guess the pci_ser allocation is in pci_liveupdate_flb_ops.preserve(), i.e., pci_flb_preserve()?

Yes.

Quoted 28 lines

Quoted 4 lines

So the PCI core tracker (pci_ser) isn't actually allocated at the time of pci_liveupdate_register_flb(); it's allocated on the first LIVEUPDATE_SESSION_PRESERVE_FD ioctl for a driver that has called pci_liveupdate_register_flb()?

Yes. The first device that gets preserved triggers the allocation of struct pci_ser. And the last device that gets unpreserved (preservation cancelled) triggers the freeing of struct pci_ser.

Quoted 19 lines

IIUC the call tree for that ioctl looks something like this:

<driver>
pci_liveupdate_register_flb
liveupdate_register_flb(fh, &pci_liveupdate_flb)

luo_session_ioctl

    op = &luo_session_ioctl_ops[...]
    op->execute                               # eg luo_session_preserve_fd()
      luo_session_preserve_fd
        luo_preserve_file
          luo_flb_file_preserve
            luo_flb_file_preserve_one
              if (outgoing_count == 0)        # only for first FLB device
                flb->ops->preserve            # eg pci_flb_preserve()
                  pci_flb_preserve
                    ser = kho_alloc_preserve  <-- alloc pci_ser
                outgoing.count = 1
          fh->ops->preserve                   # something not included here

So IIUC this part of the path looks like this, which answers my question below about ordering of pci_ser and pci_liveupdate_preserve():

              fh->ops->preserve                   # eg vfio_pci_liveupdate_preserve()
                vfio_pci_liveupdate_preserve
                  pci_liveupdate_preserve
                    pci_liveupdate_preserve_device
                      dev_ser = pci_flb_alloc_dev_ser  <-- alloc per-dev PCI core serialized state
                      dev_ser->bdf = pci_dev_id(dev)

Quoted 10 lines

Quoted 3 lines

Seems like kind of an awkward way to allocate pci_ser. Couldn't it be allocated on the first call to pci_liveupdate_register_flb()? That would be a lot easier for driver writers to trace through.

I agree the LUO FLB API is a bit awkward, but this is how it works.

If we allocated it during pci_liveupdate_register_flb() we would then need to stash it in a global variable to hand-off the LUO later. Despite the awkwardness of FLBs, it is useful to avoid globals and have LUO management the lifetime.

It seems like pci_ser is a singleton by design, so a global variable doesn't sound like it would be terrible to me.

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

When the last file is unpreserved (i.e. preservation cancelled) the PCI core will be notified to free struct pci_ser.

There's a lot going on behind "PCI core will be notified". I assume these refer to the first-time behavior of luo_flb_file_preserve_one() and last-time behavior of liveupdate_flb_put_outgoing(), which is honestly kind of hard to suss out.

Could we say something specific and PCI-related here, to help connect the dots? Most of these paths are outside the PCI core.

IIUC luo_session essentially has a refcount (outgoing.count) incremented by each LIVEUPDATE_SESSION_PRESERVE_FD ioctl, and the 0->1 transition in luo_flb_file_preserve_one() ends up calling pci_flb_preserve(), where pci_ser is allocated.

And the refcount is decremented by luo_flb_file_unpreserve() (in a luo_session .release() function), where the 1->0 transition in liveupdate_flb_put_outgoing() calls pci_flb_unpreserve() where pci_ser is deallocated.

That gets into a lot of detail, probably too much for a commit log. Maybe mentioning the function names by which the PCI core is notified to alloc/free pci_ser would be enough of a bread crumb.

Quoted 26 lines

Quoted 3 lines

This series doesn't include a caller of pci_liveupdate_preserve() (or pci_liveupdate_register_flb()), so I can't figure out the ordering. Obviously pci_liveupdate_register_flb() must be first.

In every version of this patch series I have sent I included a link to the vfio-pci driver changes that build on top of this, rebased that series on top of this one, uploaded it to my GitHub, and included a link in the cover letter. Here is the relevant section from the v8 cover letter:

. This series was tested in conjunction with v5 of the VFIO PCI driver . series:
.
. https://lore.kernel.org/kvm/[email protected]/
.
. The full set of patches used for testing can be found on GitHub. .
. https://github.com/dmatlack/linux/tree/liveupdate/pci/base/v8-with-vfio

Quoted 5 lines

I first thought pci_liveupdate_preserve() would be called via the fh->ops->preserve() in the luo_session_preserve_fd() ioctl path, but it's not. pci_liveupdate_preserve() is intended for the driver to call it directly. But it looks like it has to be called *after* the ioctl? Obviously I'm confused :)

Quoted 4 lines

Quoted 2 lines

It is called by the driver during it's fh->ops->preserve() callback. In other words, it is called during the ioctl by the driver.

I think the updated call tree above shows the connection?

Yes the call tree you added above is correct. Here is an attempt at the complete picture that I plan to include in the kernel-doc in v9:

* Call Flow
* ---------
*
* ::
*
* # Driver initialization
* pci_liveupdate_register_flb(fh)
*
* # Userspace: ioctl(LIVEUPDATE_SESSION_PRESERVE_FD, devfd)
* luo_preserve_file()
* luo_flb_file_preserve()

 *       luo_flb_file_preserve_one()      # first preserved file only
 *         pci_flb_preserve()             # alloc and preserve struct pci_ser
 *     fh->ops->preserve()                # driver callback
 *       pci_liveupdate_preserve(dev)     # record this device in struct pci_ser

*
* # Userspace: preservation cancelled or session torn down
* luo_file_unpreserve_files()
* luo_flb_file_unpreserve()
* liveupdate_flb_put_outgoing() # last unpreserved file only
* pci_flb_unpreserve() # free struct pci_ser
*
* # ---------------- kexec ----------------
*
* # New kernel: PCI enumeration
* pci_setup_device()
* pci_liveupdate_setup_device()
* liveupdate_flb_get_incoming()
* luo_flb_retrieve_one() # first request only
* pci_flb_retrieve() # previous kernel's struct pci_ser
*
* # Userspace: ioctl(LIVEUPDATE_SESSION_FINISH)
* luo_file_finish_one()
* fh->ops->finish() # driver callback
* pci_liveupdate_finish(dev) # release this device's pci_dev_ser
* luo_flb_file_finish()
* liveupdate_flb_put_incoming() # last incoming file only
* pci_flb_finish() # free struct pci_ser
*

And here is an updated commit message that I hope explains everything more clearly:

PCI: liveupdate: Set up FLB handler for the PCI core

Set up a File-Lifecycle-Bound (FLB) handler so that the PCI core can preserve its own state across a Live Update kexec.

Preserving a PCI device across kexec requires preserving two independent sets of state:

- Driver state, e.g. everything vfio-pci needs so that userspace can keep using the device in the new kernel. The driver preserves this itself and the PCI core is not involved.

- PCI core state, e.g. which devices are preserved, so that the new kernel knows not to disturb them while they are still running and doing DMA. That is what this commit adds, serialized into struct pci_ser.

Userspace, not the kernel, decides which devices are preserved, and it does so through the Live Update Orchestrator's (LUO) support for file
preservation: a driver exposes a file that represents a single PCI device, and userspace preserves that device with ioctl(LIVEUPDATE_SESSION_PRESERVE_FD) on that file. Binding preservation to a file gives it proper lifecycle management, e.g. the preservation is undone if userspace cancels it or goes away. How a driver exposes that file is up to the driver and invisible to the PCI core (vfio-pci variant drivers, the first intended use-case, use their per-device cdev).

LUO only knows that a file was preserved; it does not know that the

represents a PCI device, or which one. Bridging that gap, drivers register their liveupdate_file_handler with the PCI core:

   pci_liveupdate_register_flb(driver_file_handler);
   pci_liveupdate_unregister_flb(driver_file_handler);

LUO then refcounts the PCI core's FLB against the files preserved by that handler, and that refcount drives the lifetime of struct pci_ser:

- On the first preserved file, luo_flb_file_preserve_one() calls pci_flb_preserve(), which allocates struct pci_ser and preserves it with KHO.

- On the last unpreserved file (i.e. preservation cancelled), liveupdate_flb_put_outgoing() calls pci_flb_unpreserve(), which unpreserves and frees struct pci_ser.

- In the next kernel, pci_flb_retrieve() hands the PCI core the struct pci_ser built by the previous kernel, whenever the PCI core asks for it (e.g. during enumeration), and pci_flb_finish() frees it once the PCI core is done with it.

So the flow for preserving a device, once a driver has registered, looks like this:

ioctl(LIVEUPDATE_SESSION_PRESERVE_FD)
luo_session_preserve_fd()
luo_preserve_file()
luo_flb_file_preserve()
luo_flb_file_preserve_one() # only on the first preserved file
pci_flb_preserve() # alloc + KHO-preserve pci_ser
fh->ops->preserve() # driver callback, e.g. vfio-pci

Note that struct pci_ser is deliberately not allocated when a driver calls pci_liveupdate_register_flb(). A driver can be loaded for the lifetime of the machine without ever preserving a device, and there is no reason to allocate memory and hand it to the next kernel in that case. Letting LUO own the lifetime also means the PCI core does not have to duplicate LUO's refcounting and unwind logic for preservation failures, session aborts and fd close, and the incoming side (retrieve/finish) comes from the same object rather than requiring a separate KHO FDT entry owned by the PCI core.

Note: This commit only allocates struct pci_ser and preserves it across Live Update. A subsequent commit adds pci_liveupdate_preserve(), the API drivers call from their fh->ops->preserve() callback to tell the PCI core exactly which devices are being preserved.

Note: There is no reason to check for kho_is_enabled() since it can be assumed to return true. If KHO was not enabled then Live Update would not be enabled and these routines would never run.

Add APIs to allow drivers to notify the PCI core of which devices are being preserved across a Live Update for the next kernel, i.e. "outgoing" devices.

Drivers must notify the PCI core when devices are preserved so that the PCI core can update its FLB data (struct pci_ser) and track the list of outgoing devices. pci_liveupdate_preserve() notifies the PCI core that a device must be preserved across Live Update. pci_liveupdate_unpreserve() reverses this (cancels the preservation of the device).

This tracking ensures the PCI core is fully aware of which devices may need special handling during shutdown and kexec, and so the list of preserved devices can be handed off to the next kernel.

For now, the API only supports preserving non-VF devices on a root bus (not behind an PCI-to-PCI bridges).

Reviewed-by Pranjal Shrivastava <[email protected]>

Reviewed-by Pasha Tatashin <[email protected]>

Reviewed-by Bjorn Helgaas <[email protected]>

Signed-off-by David Matlack <[email protected]>

---

drivers/pci/liveupdate.c       | 210 +++++++++++++++++++++++++++++++++
drivers/pci/liveupdate.h       |  21 ++++
drivers/pci/probe.c            |   2 +
include/linux/pci.h            |   3 +
include/linux/pci_liveupdate.h |  21 ++++
5 files changed, 257 insertions(+)

create mode 100644 drivers/pci/liveupdate.h

Add APIs to allow drivers to notify the PCI core of which devices are being preserved across a Live Update for the next kernel, i.e. "outgoing" devices.

Drivers must notify the PCI core when devices are preserved so that the PCI core can update its FLB data (struct pci_ser) and track the list of outgoing devices. pci_liveupdate_preserve() notifies the PCI core that a device must be preserved across Live Update. pci_liveupdate_unpreserve() reverses this (cancels the preservation of the device).

This tracking ensures the PCI core is fully aware of which devices may need special handling during shutdown and kexec, and so the list of preserved devices can be handed off to the next kernel.

For now, the API only supports preserving non-VF devices on a root bus (not behind an PCI-to-PCI bridges).

Reviewed-by Pranjal Shrivastava <[email protected]>

Reviewed-by Pasha Tatashin <[email protected]>

Reviewed-by Bjorn Helgaas <[email protected]>

Signed-off-by David Matlack <[email protected]>

Add APIs to allow drivers to notify the PCI core of which devices are being preserved across a Live Update for the next kernel, i.e. "outgoing" devices.

Drivers must notify the PCI core when devices are preserved so that the PCI core can update its FLB data (struct pci_ser) and track the list of outgoing devices. pci_liveupdate_preserve() notifies the PCI core that a device must be preserved across Live Update. pci_liveupdate_unpreserve() reverses this (cancels the preservation of the device).

This tracking ensures the PCI core is fully aware of which devices may need special handling during shutdown and kexec, and so the list of preserved devices can be handed off to the next kernel.

For now, the API only supports preserving non-VF devices on a root bus (not behind an PCI-to-PCI bridges).

Reviewed-by Pranjal Shrivastava <[email protected]>

Reviewed-by Pasha Tatashin <[email protected]>

Reviewed-by Bjorn Helgaas <[email protected]>

Signed-off-by David Matlack <[email protected]>

---
  drivers/pci/liveupdate.c       | 210 +++++++++++++++++++++++++++++++++
  drivers/pci/liveupdate.h       |  21 ++++
  drivers/pci/probe.c            |   2 +
  include/linux/pci.h            |   3 +
  include/linux/pci_liveupdate.h |  21 ++++
  5 files changed, 257 insertions(+)

create mode 100644 drivers/pci/liveupdate.h

drivers/pci/liveupdate.c +210 -0

index fffb41a66ca7..b003b7069cdb 100644
@@ -36,6 +36,27 @@
   *
   *  * ``pci_liveupdate_register_flb(driver_file_handler)``
   *  * ``pci_liveupdate_unregister_flb(driver_file_handler)``
+ *
+ * Device Tracking
+ * ===============
+ *
+ * Drivers must notify the PCI core when specific devices are preserved or
+ * unpreserved with the following APIs:
+ *
+ *  * ``pci_liveupdate_preserve(pci_dev)``
+ *  * ``pci_liveupdate_unpreserve(pci_dev)``
+ *
+ * This allows the PCI core to keep its FLB data (struct pci_ser) up to date
+ * with the list of **outgoing** preserved devices for the next kernel.
+ *
+ * Restrictions
+ * ============
+ *
+ * The PCI core enforces the following restrictions on which devices can be
+ * preserved. These may be relaxed in the future:
+ *
+ *  * The device cannot be a Virtual Function (VF).
+ *  * The device cannot be behind a PCI-to-PCI bridge.
   */
 
  #define pr_fmt(fmt) "PCI: liveupdate: " fmt

@@ -50,6 +71,21 @@
  #include <linux/pci.h>
  #include <linux/slab.h>
 
+#include "liveupdate.h"
+
+/**
+ * struct pci_liveupdate_global - Global state for PCI Live Update support
+ * @rwsem: Reader/writer semaphore used to protect the incoming and outgoing
+ *         FLBs, and the references to them in struct pci_dev.
+ */
+struct pci_liveupdate_global {
+	struct rw_semaphore rwsem;
+};
+
+static struct pci_liveupdate_global pci_liveupdate = {
+	.rwsem = __RWSEM_INITIALIZER(pci_liveupdate.rwsem),
+};
+
  /**
   * struct pci_flb_outgoing - Outgoing PCI FLB object
   * @ser: Pointer to the preserved struct pci_ser.

@@ -128,6 +164,180 @@ static struct liveupdate_flb pci_liveupdate_flb = {
  	.compatible = PCI_LUO_FLB_COMPATIBLE,
  };
 
+static void pci_liveupdate_flb_put_outgoing(void)
+{
+	liveupdate_flb_put_outgoing(&pci_liveupdate_flb);
+}
+
+static struct pci_flb_outgoing *pci_liveupdate_flb_get_outgoing(void)
+{
+	struct pci_flb_outgoing *outgoing = NULL;
+	int ret;
+
+	ret = liveupdate_flb_get_outgoing(&pci_liveupdate_flb, (void **)&outgoing);
+	if (ret)
+		return ERR_PTR(ret);
+
+	if (!outgoing)
+		return ERR_PTR(-ENOENT);
+
+	return outgoing;
+}
+
+static struct pci_dev_ser *pci_flb_alloc_dev_ser(struct pci_flb_outgoing *outgoing)
+{
+	struct pci_dev_ser *dev_ser;
+	struct kho_block_set_it it;
+	u64 count = 0;
+	int err;
+
+	kho_block_set_it_init(&it, &outgoing->block_set);
+
+	/* Try to find an existing, previously unpreserved, entry. */
+	while ((dev_ser = kho_block_set_it_read_entry(&it))) {
+		if (!dev_ser->refcount)
+			return dev_ser;
+
+		count++;
+	}
+
+	/* Otherwise grow the block set and reserve a new entry. */
+	err = kho_block_set_grow(&outgoing->block_set, count + 1);
+	if (err)
+		return ERR_PTR(err);
+
+	if (!count)
+		kho_block_set_it_init(&it, &outgoing->block_set);
+
+	/* This should always succeed since kho_block_set_grow() succeeded. */
+	dev_ser = kho_block_set_it_reserve_entry(&it);
+	if (WARN_ON_ONCE(!dev_ser))
+		return ERR_PTR(-ENOSPC);
+
+	return dev_ser;
+}
+
+static void pci_liveupdate_unpreserve_device(struct pci_flb_outgoing *outgoing,
+					     struct pci_dev *dev)
+{
+	struct pci_dev_ser *dev_ser = dev->liveupdate.outgoing;
+
+	if (!dev_ser) {
+		pci_warn(dev, "Cannot unpreserve device that is not preserved\n");
+		return;
+	}
+
+	pci_info(dev, "Device will no longer be preserved across next Live Update\n");
+	outgoing->ser->nr_devices--;
+	memset(dev_ser, 0, sizeof(*dev_ser));
+	dev->liveupdate.outgoing = NULL;
+}
+
+static int pci_liveupdate_preserve_device(struct pci_flb_outgoing *outgoing,
+					  struct pci_dev *dev)
+{
+	struct pci_dev_ser *dev_ser;
+
+	if (dev->is_virtfn) {
+		pci_warn(dev, "Cannot preserve Virtual Functions\n");
+		return -EINVAL;
+	}
+
+	if (dev->liveupdate.outgoing) {
+		pci_warn(dev, "Device is already preserved\n");
+		return -EBUSY;
+	}
+
+	if (!pci_is_root_bus(dev->bus)) {
+		pci_warn(dev, "Cannot preserve devices behind bridges\n");
+		return -EINVAL;
+	}
+
+	dev_ser = pci_flb_alloc_dev_ser(outgoing);
+	if (IS_ERR(dev_ser))
+		return PTR_ERR(dev_ser);
+
+	pci_info(dev, "Device will be preserved across next Live Update\n");
+	outgoing->ser->nr_devices++;
+	outgoing->ser->devices = kho_block_set_head_pa(&outgoing->block_set);
+
+	dev_ser->domain = pci_domain_nr(dev->bus);
+	dev_ser->bdf = pci_dev_id(dev);
+	dev_ser->refcount = 1;
+
+	dev->liveupdate.outgoing = dev_ser;
+	return 0;
+}
+
+/**
+ * pci_liveupdate_preserve() - Preserve a PCI device across Live Update
+ * @dev: The PCI device to preserve.
+ *
+ * pci_liveupdate_preserve() notifies the PCI core that a PCI device should be
+ * preserved across the next Live Update. Drivers are expected to call
+ * pci_liveupdate_preserve() from their struct liveupdate_file_handler
+ * preserve() callback to ensure the outgoing struct pci_ser is already set up.
+ *
+ * Returns: 0 on success, <0 on failure.
+ */
+int pci_liveupdate_preserve(struct pci_dev *dev)
+{
+	struct pci_flb_outgoing *outgoing = NULL;
+	int ret;
+
+	guard(rwsem_write)(&pci_liveupdate.rwsem);
+
+	outgoing = pci_liveupdate_flb_get_outgoing();
+	if (IS_ERR(outgoing))
+		return PTR_ERR(outgoing);
+
+	ret = pci_liveupdate_preserve_device(outgoing, dev);
+
+	pci_liveupdate_flb_put_outgoing();
+	return ret;
+}
+EXPORT_SYMBOL_GPL(pci_liveupdate_preserve);
+
+/**
+ * pci_liveupdate_unpreserve() - Cancel preservation of a PCI device
+ * @dev: The PCI device to unpreserve.
+ *
+ * pci_liveupdate_unpreserve() notifies the PCI core that a PCI device should no
+ * longer be preserved across the next Live Update. Drivers are expected to call
+ * pci_liveupdate_unpreserve() from their struct liveupdate_file_handler
+ * unpreserve() callback to ensure the outgoing struct pci_ser is already set
+ * up.
+ */
+void pci_liveupdate_unpreserve(struct pci_dev *dev)
+{
+	struct pci_flb_outgoing *outgoing = NULL;
+
+	guard(rwsem_write)(&pci_liveupdate.rwsem);
+
+	outgoing = pci_liveupdate_flb_get_outgoing();
+	if (IS_ERR(outgoing)) {
+		pci_warn(dev, "Cannot unpreserve device without outgoing Live Update state\n");
+		return;
+	}
+
+	pci_liveupdate_unpreserve_device(outgoing, dev);
+	pci_liveupdate_flb_put_outgoing();
+}
+EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve);
+
+void pci_liveupdate_cleanup_device(struct pci_dev *dev)
+{
+	/*
+	 * It should be safe to READ_ONCE() outside of the rwsem during cleanup
+	 * since there should no longer be any references to @dev on the system.
+	 *
+	 * This should never happen in practice. Drivers should block removal
+	 * while a device is preserved.
+	 */
+	if (READ_ONCE(dev->liveupdate.outgoing))
+		pci_WARN(dev, 1, "Destroying outgoing-preserved device!\n");
+}
+
  /**
   * pci_liveupdate_register_flb() - Register a file handler with the PCI core
   * @fh: The file handler to register.

drivers/pci/liveupdate.h new file +21 -0

new file mode 100644
index 000000000000..b2335581f8d0
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * PCI Live Update support (core API)
+ *
+ * Copyright (c) 2026, Google LLC.
+ * David Matlack <[email protected]>
+ */
+#ifndef DRIVERS_PCI_LIVEUPDATE_H
+#define DRIVERS_PCI_LIVEUPDATE_H
+
+#include <linux/pci.h>
+
+#ifdef CONFIG_PCI_LIVEUPDATE
+void pci_liveupdate_cleanup_device(struct pci_dev *dev);
+#else
+static inline void pci_liveupdate_cleanup_device(struct pci_dev *dev)
+{
+}
+#endif
+
+#endif /* DRIVERS_PCI_LIVEUPDATE_H */

drivers/pci/probe.c +2 -0

index dd0abbc63e18..14b66acbdb15 100644
@@ -24,6 +24,7 @@
  #include <linux/pm_runtime.h>
  #include <linux/bitfield.h>
  #include <trace/events/pci.h>
+#include "liveupdate.h"
  #include "pci.h"
 
  static struct resource busn_resource = {

@@ -2485,6 +2486,7 @@ static void pci_release_dev(struct device *dev)
 
  	pci_dev = to_pci_dev(dev);
  	pci_release_capabilities(pci_dev);
+	pci_liveupdate_cleanup_device(pci_dev);
  	pci_release_of_node(pci_dev);
  	pcibios_release_device(pci_dev);
  	pci_bus_put(pci_dev->bus);

include/linux/pci.h +3 -0

index da58aa101e4c..b41dd572a2d6 100644
@@ -593,6 +593,9 @@ struct pci_dev {
  	u8		tph_mode;	/* TPH mode */
  	u8		tph_req_type;	/* TPH requester type */
  #endif
+#ifdef CONFIG_PCI_LIVEUPDATE
+	struct pci_liveupdate liveupdate;
+#endif
  };
 
  static inline struct pci_dev *pci_physfn(struct pci_dev *dev)

include/linux/pci_liveupdate.h +21 -0

index 8ec98beefcb4..894052ad6961 100644
@@ -8,14 +8,26 @@
  #ifndef LINUX_PCI_LIVEUPDATE_H
  #define LINUX_PCI_LIVEUPDATE_H
 
+#include <linux/kho/abi/pci.h>
  #include <linux/liveupdate.h>
+#include <linux/spinlock_types.h>
  #include <linux/types.h>
 
+/**
+ * struct pci_liveupdate - PCI Live Update state for a struct pci_dev
+ * @outgoing: State preserved for the next kernel.
+ */
+struct pci_liveupdate {
+	struct pci_dev_ser *outgoing;
+};
+
  struct pci_dev;
 
  #ifdef CONFIG_PCI_LIVEUPDATE
  int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh);
  void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh);
+int pci_liveupdate_preserve(struct pci_dev *dev);
+void pci_liveupdate_unpreserve(struct pci_dev *dev);
  #else
  static inline int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
  {

@@ -25,6 +37,15 @@ static inline int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh
  static inline void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh)
  {
  }
+
+static inline int pci_liveupdate_preserve(struct pci_dev *dev)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline void pci_liveupdate_unpreserve(struct pci_dev *dev)
+{
+}
  #endif
 
  #endif /* LINUX_PCI_LIVEUPDATE_H */

Quoted 9 lines · David Matlack

Add APIs to allow drivers to notify the PCI core of which devices are being preserved across a Live Update for the next kernel, i.e. "outgoing" devices.

Drivers must notify the PCI core when devices are preserved so that the PCI core can update its FLB data (struct pci_ser) and track the list of outgoing devices. pci_liveupdate_preserve() notifies the PCI core that a device must be preserved across Live Update. pci_liveupdate_unpreserve() reverses this (cancels the preservation of the device).

Hi David,

I have a question about the pci_liveupdate_preserve() and pci_liveupdate_unpreserve() APIs.

Is it supported to call these APIs multiple times for the same PCI device? For example, a driver could do:

pci_liveupdate_preserve(pdev) -- > pci_liveupdate_unpreserve(pdev) -- > perform some operations -- > pci_liveupdate_preserve(pdev) again, before the actual Live Update starts.

From the implementation, it looks like an unpreserved pci_dev_ser entry
can be reused, so I wanted to confirm whether this preserve -- > unpreserve -- > preserve sequence is an intended and supported usage.

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Unconditional kernel panic in the incoming FLB finish path if a preserved PCI device is missing or fails setup.
- [High] pci_flb_unpreserve() destroys outgoing FLB memory without clearing device pointers, leading to a Use-After-Free.
- [High] Transient errors or version mismatches during FLB retrieval cause an immediate kernel panic on device setup.
- [Medium] Leaking preserved KHO memory for ser->devices on early error paths in pci_flb_retrieve(). --

--- Patch [3]: [PATCH v8 03/12] PCI: liveupdate: Track incoming preserved PCI devices --- commit 8fdc703d6dd44076cd03589af0bcffa13c79e7f4
Author: David Matlack <[email protected]>

PCI: liveupdate: Track incoming preserved PCI devices

This patch allows the PCI core to track incoming preserved PCI devices during enumeration. It fetches the serialized state from the Live Update Orchestrator and exposes APIs for drivers to handle incoming devices.

Quoted 4 lines

drivers/pci/liveupdate.c +0 -0

index b003b7069cdb0..5ce5f8b369029 100644

[ ... ]

Quoted 23 lines

drivers/pci/liveupdate.c +18 -1

@@ -140,15 +174,91 @@ static int pci_flb_retrieve(struct liveupdate_flb_op_args *args)
 {
+     struct pci_ser *ser = phys_to_virt(args->data);
+     struct pci_flb_incoming *incoming;
+     struct pci_dev_ser *dev_ser;
+     struct kho_block_set_it it;
+     int ret;
 
      pr_debug("Retrieving struct pci_ser (0x%llx)\n", args->data);
-     args->obj = phys_to_virt(args->data);
+
+     if (ser->version != PCI_LUO_FLB_VERSION) {
+             pr_err("Incoming PCI FLB version (v%d) is incompatible with this kernel (v%d)\n",
+                    ser->version, PCI_LUO_FLB_VERSION);
+             ret = -EINVAL;
+             goto err_restore_free;
+     }
+
+     incoming = kzalloc_obj(*incoming);
+     if (!incoming) {
+             ret = -ENOMEM;
+             goto err_restore_free;
+     }

[ ... ]

drivers/pci/liveupdate.c static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args) · line 230

Quoted 4 lines

drivers/pci/liveupdate.c +4 -0

+err_restore_free:
+     kho_restore_free(ser);
+     return ret;
+}

[Severity: Medium]
Does this error path leak the KHO memory for ser->devices?

When jumping to err_restore_free (e.g. due to a version mismatch or kzalloc failure), kho_restore_free(ser) is called, but it doesn't appear to restore or free the memory pointed to by ser->devices.

Since KHO pages are reserved across kexec, will this permanently leak the memory for the uptime of the successor kernel?

[ ... ]

Quoted 8 lines

drivers/pci/liveupdate.c +8 -0

+static void pci_check_all_devices_finished(struct pci_flb_incoming *incoming)
+{
+     struct pci_dev *dev = NULL;
+
+     if (READ_ONCE(incoming->ser->nr_devices) == 0)
+             return;
+
+     for_each_pci_dev(dev) {

drivers/pci/liveupdate.c static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)

Quoted 10 lines

drivers/pci/liveupdate.c +10 -0

+             if (READ_ONCE(dev->liveupdate.incoming))
+                     pci_emerg(dev, "Preserved device was never finished!\n");
+     }
+
+     /*
+      * This should only happen if a driver violated the contract to call
+      * pci_liveupdate_finish() (something is extremely broken).
+      */
+     panic("Some preserved devices were never finished!\n");
+}

[Severity: High]
Is an unconditional panic here safe if a preserved device is missing or fails to probe?

If a PCI device that was preserved by the previous kernel fails to probe in the new kernel (e.g. the driver module is missing, or it encounters a transient error), pci_liveupdate_finish() will never be called and incoming->ser->nr_devices will not be decremented.

When the Live Update orchestrator concludes the update and calls pci_flb_finish(), pci_check_all_devices_finished() is invoked and sees that nr_devices is still > 0. Does this mean normal system conditions like a missing driver will trigger a kernel panic?

[ ... ]

Quoted 8 lines

drivers/pci/liveupdate.c +4 -0

@@ -325,6 +435,75 @@ void pci_liveupdate_unpreserve(struct pci_dev *dev)
 }
 EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve);
 
+static struct pci_flb_incoming *pci_liveupdate_flb_get_incoming(void)
+{
+     struct pci_flb_incoming *incoming = NULL;
+     int ret;

[ ... ]

drivers/pci/liveupdate.c void pci_liveupdate_unpreserve(struct pci_dev *dev) · line 469

Quoted 10 lines

drivers/pci/liveupdate.c +10 -0

+     /*
+      * There is incoming FLB data that matches pci_liveupdate_flb.compatible
+      * but retrieve failed (pci_flb_retrieve() returned an error or LUO
+      * failed to acquire a reference to pci_liveupdate_flb_ops.owner).
+      */
+     if (ret)
+             panic("Failed to retrieve incoming FLB data (%d)\n", ret);
+
+     return incoming;
+}

[Severity: High]
Does this panic prevent the new kernel from booting if there's a simple FLB version mismatch?

During PCI enumeration in the new kernel, pci_setup_device() calls pci_liveupdate_setup_device(), which invokes pci_liveupdate_flb_get_incoming().

If pci_flb_retrieve() encounters an error like a version mismatch (-EINVAL) or an allocation failure (-ENOMEM), it returns that error code. This branch then catches the error and unconditionally panics. Will this reliably crash the new kernel during early boot and break the kexec handover fallback mechanism?

[ ... ]

I also have a question about the unpreserve path in pci_flb_unpreserve() which might lead to a regression:

drivers/pci/liveupdate.c:pci_flb_unpreserve() {
    ...
    WARN_ON(outgoing->ser->nr_devices);
    kho_block_set_destroy(&outgoing->block_set);
    kho_unpreserve_free(outgoing->ser);
    kfree(outgoing);
}

[Severity: High]
Does pci_flb_unpreserve() destroy outgoing FLB memory without clearing the device pointers?

If a driver fails to unpreserve its devices before the orchestrator aborts a Live Update, pci_flb_unpreserve() will issue a WARN_ON but proceed to destroy the block set and free the outgoing FLB object.

The dev->liveupdate.outgoing pointers on the pci_dev structs are left dangling. If a new Live Update is subsequently initiated and the driver attempts to preserve the device again, pci_liveupdate_preserve_device() will access dev->liveupdate.outgoing->refcount via the dangling pointer:

drivers/pci/liveupdate.c:pci_liveupdate_preserve_device() {
    ...
    if (dev->liveupdate.outgoing) {
        if (!dev->liveupdate.outgoing->refcount) {
    ...
}

Can this lead to a use-after-free of the KHO block set memory?

--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

During PCI enumeration, the previous kernel might have passed state about devices that were preserved across kexec. The PCI core needs to fetch this state to identify which devices are "incoming" and require special handling.

Add pci_liveupdate_setup_device() which is called during device setup to fetch the serialized state (struct pci_ser) from the Live Update Orchestrator. The first time this happens, pci_flb_retrieve() will run and convert the array of pci_dev_ser structs into an xarray so that it can be looked up efficiently.

If a device is found in the xarray, the PCI core stores a pointer to its state in dev->liveupdate_incoming until pci_liveupdate_finish() is called by the driver. This pointer allows the PCI core and drivers to apply Live Update-specific logic to incoming devices in subsequent commits.

Drivers can check if a device is an incoming preserved device (e.g. during probe) by calling pci_liveupdate_is_incoming().

CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the domain and bdf can be guaranteed to fit in an unsigned long and be used as the xarray key.

Reviewed-by Pranjal Shrivastava <[email protected]>

Signed-off-by David Matlack <[email protected]>

---

MAINTAINERS                    |   1 +
drivers/pci/Kconfig            |   2 +-
drivers/pci/liveupdate.c       | 256 ++++++++++++++++++++++++++++++++-
drivers/pci/liveupdate.h       |   5 +
drivers/pci/probe.c            |   3 +
include/linux/pci_liveupdate.h |  13 ++
6 files changed, 277 insertions(+), 3 deletions(-)

drivers/pci/liveupdate.c +5 -0

+
+	xa_destroy(&incoming->xa);
+	kho_block_set_destroy(&incoming->block_set);
+	kho_restore_free(incoming->ser);
+	kfree(incoming);

}

During PCI enumeration, the previous kernel might have passed state about devices that were preserved across kexec. The PCI core needs to fetch this state to identify which devices are "incoming" and require special handling.

Add pci_liveupdate_setup_device() which is called during device setup to fetch the serialized state (struct pci_ser) from the Live Update Orchestrator. The first time this happens, pci_flb_retrieve() will run and convert the array of pci_dev_ser structs into an xarray so that it can be looked up efficiently.

+ * The PCI core does not enforce any ordering of ``pci_liveupdate_finish()`` and
+ * ``pci_liveupdate_preserve()``. i.e. A PCI device can be **outgoing**
+ * (preserved for next kernel) and **incoming** (preserved by previous kernel)

static int pci_flb_preserve(struct liveupdate_flb_op_args *args) {

Quoted 11 lines · David Matlack

During PCI enumeration, the previous kernel might have passed state about devices that were preserved across kexec. The PCI core needs to fetch this state to identify which devices are "incoming" and require special handling.

Add pci_liveupdate_setup_device() which is called during device setup to fetch the serialized state (struct pci_ser) from the Live Update Orchestrator. The first time this happens, pci_flb_retrieve() will run and convert the array of pci_dev_ser structs into an xarray so that it can be looked up efficiently.

Quoted 3 lines

+ * The PCI core does not enforce any ordering of ``pci_liveupdate_finish()`` and
+ * ``pci_liveupdate_preserve()``. i.e. A PCI device can be **outgoing**
+ * (preserved for next kernel) and **incoming** (preserved by previous kernel)

Thinking about how this will be rendered in the formatted doc, I think "i.e." is really part of the sentence, so in U.S. usage this would be:

``pci_liveupdate_preserve()``, i.e., a PCI device can be ...

I understand British usage generally omits the comma after, so that's OK too, but IIUC the first part of the sentence shouldn't be terminated with a period, and the "A" shouldn't be capitalized as if it's a new sentence.

Similar issue in "PCI: liveupdate: Document driver binding responsibilities" later:

bound to the correct driver. i.e. The PCI core does not protect ...

drivers/pci/liveupdate.c struct pci_flb_outgoing { · line 136

Quoted 5 lines

drivers/pci/liveupdate.c +4 -0

+static unsigned long pci_ser_xa_key(u32 domain, u16 bdf)
+{
+	return (unsigned long)domain << 16 | bdf;
+}

Add blank line.

Quoted 2 lines

static int pci_flb_preserve(struct liveupdate_flb_op_args *args) {

During PCI enumeration, the previous kernel might have passed state about devices that were preserved across kexec. The PCI core needs to fetch this state to identify which devices are "incoming" and require special handling.

Add pci_liveupdate_setup_device() which is called during device setup to fetch the serialized state (struct pci_ser) from the Live Update Orchestrator. The first time this happens, pci_flb_retrieve() will run and convert the array of pci_dev_ser structs into an xarray so that it can be looked up efficiently.

If a device is found in the xarray, the PCI core stores a pointer to its state in dev->liveupdate_incoming until pci_liveupdate_finish() is called by the driver. This pointer allows the PCI core and drivers to apply Live Update-specific logic to incoming devices in subsequent commits.

Drivers can check if a device is an incoming preserved device (e.g. during probe) by calling pci_liveupdate_is_incoming().

CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the domain and bdf can be guaranteed to fit in an unsigned long and be used as the xarray key.

Reviewed-by Pranjal Shrivastava <[email protected]>

Signed-off-by David Matlack <[email protected]>

---
  MAINTAINERS                    |   1 +
  drivers/pci/Kconfig            |   2 +-
  drivers/pci/liveupdate.c       | 256 ++++++++++++++++++++++++++++++++-
  drivers/pci/liveupdate.h       |   5 +
  drivers/pci/probe.c            |   3 +
  include/linux/pci_liveupdate.h |  13 ++
  6 files changed, 277 insertions(+), 3 deletions(-)

MAINTAINERS +1 -0

index 9cc7b9291ace..08a724b860dc 100644
@@ -20834,6 +20834,7 @@ L:	[email protected]
  S:	Maintained
  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
  F:	drivers/pci/liveupdate.c
+F:	drivers/pci/liveupdate.h
  F:	include/linux/kho/abi/pci.h
  F:	include/linux/pci_liveupdate.h
 

drivers/pci/Kconfig +0 -0

index 3781e2b5f095..8af20f558086 100644

drivers/pci/Kconfig +0 -0

  	help
  	  Enable PCI core support for preserving PCI devices across Live
  	  Update. This, in combination with support in a device's driver,

drivers/pci/liveupdate.c +254 -2

index b003b7069cdb..5ce5f8b36902 100644
@@ -49,6 +49,20 @@
   * This allows the PCI core to keep its FLB data (struct pci_ser) up to date
   * with the list of **outgoing** preserved devices for the next kernel.
   *
+ * After kexec, whenever a device is enumerated, the PCI core will check if it
+ * is an **incoming** preserved device (i.e. preserved by the previous kernel)
+ * by checking the incoming FLB data (struct pci_ser).
+ *
+ * Drivers must notify the PCI core when an **incoming** device is done
+ * participating in the incoming Live Update with the following API:
+ *
+ *  * ``pci_liveupdate_finish(pci_dev)``
+ *
+ * The PCI core does not enforce any ordering of ``pci_liveupdate_finish()`` and
+ * ``pci_liveupdate_preserve()``. i.e. A PCI device can be **outgoing**
+ * (preserved for next kernel) and **incoming** (preserved by previous kernel)
+ * at the same time.
+ *
   * Restrictions
   * ============
   *

@@ -100,6 +114,26 @@ struct pci_flb_outgoing {
  	struct kho_block_set block_set;
  };
 
+/**
+ * struct pci_flb_incoming - Incoming PCI FLB object
+ * @ser: The incoming struct pci_ser from the previous kernel.
+ * @xa: Xarray used to quickly lookup devices in @ser.
+ * @block_set: The KHO block set holding the incoming devices.
+ *
+ * This structure holds the runtime state for the incoming PCI Live Update
+ * state. It wraps the serialized pci_ser, the block_set used to restore
+ * the serialized entries, and an xarray for fast lookups.
+ */
+struct pci_flb_incoming {
+	struct pci_ser *ser;
+	struct xarray xa;
+	struct kho_block_set block_set;
+};
+
+static unsigned long pci_ser_xa_key(u32 domain, u16 bdf)
+{
+	return (unsigned long)domain << 16 | bdf;
+}
  static int pci_flb_preserve(struct liveupdate_flb_op_args *args)
  {
  	struct pci_flb_outgoing *outgoing __free(kfree) = NULL;

@@ -140,15 +174,91 @@ static void pci_flb_unpreserve(struct liveupdate_flb_op_args *args)
 
  static int pci_flb_retrieve(struct liveupdate_flb_op_args *args)
  {
+	struct pci_ser *ser = phys_to_virt(args->data);
+	struct pci_flb_incoming *incoming;
+	struct pci_dev_ser *dev_ser;
+	struct kho_block_set_it it;
+	int ret;
+
  	pr_debug("Retrieving struct pci_ser (0x%llx)\n", args->data);
-	args->obj = phys_to_virt(args->data);
+
+	if (ser->version != PCI_LUO_FLB_VERSION) {
+		pr_err("Incoming PCI FLB version (v%d) is incompatible with this kernel (v%d)\n",
+		       ser->version, PCI_LUO_FLB_VERSION);
+		ret = -EINVAL;
+		goto err_restore_free;
+	}
+
+	incoming = kzalloc_obj(*incoming);
+	if (!incoming) {
+		ret = -ENOMEM;
+		goto err_restore_free;
+	}
+
+	incoming->ser = ser;
+	xa_init(&incoming->xa);
+
+	kho_block_set_init(&incoming->block_set, sizeof(struct pci_dev_ser));
+	ret = kho_block_set_restore(&incoming->block_set, ser->devices);
+	if (ret)
+		goto err_free_incoming;
+
+	kho_block_set_it_init(&it, &incoming->block_set);
+	while ((dev_ser = kho_block_set_it_read_entry(&it))) {
+		unsigned long key;
+
+		if (!dev_ser->refcount)
+			continue;
+
+		key = pci_ser_xa_key(dev_ser->domain, dev_ser->bdf);
+		ret = xa_insert(&incoming->xa, key, dev_ser, GFP_KERNEL);
+		if (ret)
+			goto err_block_set_destroy;
+	}
+
+	args->obj = incoming;
  	return 0;
+
+err_block_set_destroy:
+	kho_block_set_destroy(&incoming->block_set);
+err_free_incoming:
+	xa_destroy(&incoming->xa);
+	kfree(incoming);
+err_restore_free:
+	kho_restore_free(ser);
+	return ret;
+}
+
+static void pci_check_all_devices_finished(struct pci_flb_incoming *incoming)
+{
+	struct pci_dev *dev = NULL;
+
+	if (READ_ONCE(incoming->ser->nr_devices) == 0)
+		return;
+
+	for_each_pci_dev(dev) {
+		if (READ_ONCE(dev->liveupdate.incoming))
+			pci_emerg(dev, "Preserved device was never finished!\n");
+	}
+
+	/*
+	 * This should only happen if a driver violated the contract to call
+	 * pci_liveupdate_finish() (something is extremely broken).
+	 */
+	panic("Some preserved devices were never finished!\n");
  }
 
  static void pci_flb_finish(struct liveupdate_flb_op_args *args)
  {
+	struct pci_flb_incoming *incoming = args->obj;
+
  	pr_debug("Finished struct pci_ser (0x%llx)\n", args->data);
-	kho_restore_free(args->obj);
+	pci_check_all_devices_finished(incoming);
+
+	xa_destroy(&incoming->xa);
+	kho_block_set_destroy(&incoming->block_set);
+	kho_restore_free(incoming->ser);
+	kfree(incoming);
  }
 
  static struct liveupdate_flb_ops pci_liveupdate_flb_ops = {

@@ -325,6 +435,75 @@ void pci_liveupdate_unpreserve(struct pci_dev *dev)
  }
  EXPORT_SYMBOL_GPL(pci_liveupdate_unpreserve);
 
+static struct pci_flb_incoming *pci_liveupdate_flb_get_incoming(void)
+{
+	struct pci_flb_incoming *incoming = NULL;
+	int ret;
+
+	ret = liveupdate_flb_get_incoming(&pci_liveupdate_flb, (void **)&incoming);
+
+	/* Live Update is not enabled. */
+	if (ret == -EOPNOTSUPP)
+		return NULL;
+
+	/* Live Update is enabled, but there is no incoming FLB data. */
+	if (ret == -ENODATA)
+		return NULL;
+
+	/*
+	 * Live Update is enabled and there is incoming FLB data, but none of it
+	 * matches pci_liveupdate_flb.compatible.
+	 */
+	if (ret == -ENOENT)
+		return NULL;
+
+	/*
+	 * There is incoming FLB data that matches pci_liveupdate_flb.compatible
+	 * but retrieve failed (pci_flb_retrieve() returned an error or LUO
+	 * failed to acquire a reference to pci_liveupdate_flb_ops.owner).
+	 */
+	if (ret)
+		panic("Failed to retrieve incoming FLB data (%d)\n", ret);
+
+	return incoming;
+}
+
+static void pci_liveupdate_flb_put_incoming(void)
+{
+	liveupdate_flb_put_incoming(&pci_liveupdate_flb);
+}
+
+void pci_liveupdate_setup_device(struct pci_dev *dev)
+{
+	struct pci_flb_incoming *incoming;
+	struct pci_dev_ser *dev_ser;
+	unsigned long key;
+
+	guard(rwsem_write)(&pci_liveupdate.rwsem);
+
+	incoming = pci_liveupdate_flb_get_incoming();
+	if (!incoming)
+		return;
+
+	key = pci_ser_xa_key(pci_domain_nr(dev->bus), pci_dev_id(dev));
+	dev_ser = xa_load(&incoming->xa, key);
+
+	/*
+	 * This device was not preserved across Live Update, or it was preserved
+	 * but has already been probed and gone through pci_liveupdate_finish(),
+	 * e.g. due to removing and re-adding the device. Either way, it's not
+	 * treated as incoming-preserved.
+	 */
+	if (!dev_ser || !dev_ser->refcount) {
+		pci_liveupdate_flb_put_incoming();
+		return;
+	}
+
+	pci_info(dev, "Device was preserved by previous kernel across Live Update\n");
+	dev->liveupdate.incoming = dev_ser;
+	pci_liveupdate_flb_put_incoming();
+}
+
  void pci_liveupdate_cleanup_device(struct pci_dev *dev)
  {
  	/*

@@ -336,7 +515,80 @@ void pci_liveupdate_cleanup_device(struct pci_dev *dev)
  	 */
  	if (READ_ONCE(dev->liveupdate.outgoing))
  		pci_WARN(dev, 1, "Destroying outgoing-preserved device!\n");
+
+	if (READ_ONCE(dev->liveupdate.incoming))
+		pci_WARN(dev, 1, "Destroying incoming-preserved device!\n");
+}
+
+static void pci_liveupdate_finish_device(struct pci_ser *ser, struct pci_dev *dev)
+{
+	if (!dev->liveupdate.incoming) {
+		pci_warn(dev, "Cannot finish preserving an unpreserved device\n");
+		return;
+	}
+
+	if (dev->liveupdate.incoming->refcount != 1) {
+		pci_WARN(dev, 1, "Preserved device has a corrupted refcount!\n");
+		return;
+	}
+
+	/*
+	 * Drop the refcount so this device does not get treated as an incoming
+	 * device again, e.g. in case pci_liveupdate_setup_device() gets called
+	 * again because the device is hot-plugged.
+	 */
+	dev->liveupdate.incoming->refcount = 0;
+
+	pci_info(dev, "Device is finished participating in Live Update\n");
+	dev->liveupdate.incoming = NULL;
+	ser->nr_devices--;
+}
+
+/**
+ * pci_liveupdate_finish() - Finish the preservation of a PCI device
+ * @dev: The PCI device
+ *
+ * pci_liveupdate_finish() notifies the PCI core that a PCI device that was
+ * preserved across the previous Live Update has finished participating in Live
+ * Update. Drivers must call pci_liveupdate_finish() from their struct
+ * liveupdate_file_handler finish() callback to ensure the incoming struct
+ * pci_ser is allocated.
+ */
+void pci_liveupdate_finish(struct pci_dev *dev)
+{
+	struct pci_flb_incoming *incoming;
+
+	guard(rwsem_write)(&pci_liveupdate.rwsem);
+
+	incoming = pci_liveupdate_flb_get_incoming();
+	if (!incoming) {
+		pci_warn(dev, "Cannot finish preserving device without incoming FLB\n");
+		return;
+	}
+
+	pci_liveupdate_finish_device(incoming->ser, dev);
+	pci_liveupdate_flb_put_incoming();
+}
+EXPORT_SYMBOL_GPL(pci_liveupdate_finish);
+
+/**
+ * pci_liveupdate_is_incoming() - Check if a device is incoming-preserved
+ * @dev: The PCI device to check
+ *
+ * Check if a device was preserved across Live Update by the previous kernel,
+ * i.e. the device is incoming-preserved. Note that a device is only considered
+ * incoming-preserved prior to pci_liveupdate_finish(). It is up to drivers to
+ * synchronize usage of pci_liveupdate_is_incoming() with their own call to
+ * pci_liveupdate_finish() to avoid acting on stale data.
+ *
+ * Returns: True if the device is incoming-preserved, false otherwise.
+ */
+bool pci_liveupdate_is_incoming(struct pci_dev *dev)
+{
+	guard(rwsem_read)(&pci_liveupdate.rwsem);
+	return dev->liveupdate.incoming;
  }
+EXPORT_SYMBOL_GPL(pci_liveupdate_is_incoming);
 
  /**
   * pci_liveupdate_register_flb() - Register a file handler with the PCI core

drivers/pci/liveupdate.h +5 -0

index b2335581f8d0..eaaa3559fd77 100644
@@ -11,8 +11,13 @@
  #include <linux/pci.h>
 
  #ifdef CONFIG_PCI_LIVEUPDATE
+void pci_liveupdate_setup_device(struct pci_dev *dev);
  void pci_liveupdate_cleanup_device(struct pci_dev *dev);
  #else
+static inline void pci_liveupdate_setup_device(struct pci_dev *dev)
+{
+}
+
  static inline void pci_liveupdate_cleanup_device(struct pci_dev *dev)
  {
  }

drivers/pci/probe.c +3 -0

index 14b66acbdb15..5dc9d86e3597 100644
@@ -2065,6 +2065,8 @@ int pci_setup_device(struct pci_dev *dev)
  	if (pci_early_dump)
  		early_dump_pci_device(dev);
 
+	pci_liveupdate_setup_device(dev);
+
  	/* Need to have dev->class ready */
  	dev->cfg_size = pci_cfg_space_size(dev);
 

@@ -2188,6 +2190,7 @@ int pci_setup_device(struct pci_dev *dev)
  	default:				    /* unknown header */
  		pci_err(dev, "unknown header type %02x, ignoring device\n",
  			dev->hdr_type);
+		pci_liveupdate_cleanup_device(dev);
  		pci_release_of_node(dev);
  		return -EIO;
 

include/linux/pci_liveupdate.h +13 -0

index 894052ad6961..710026ada2d5 100644
@@ -16,9 +16,11 @@
  /**
   * struct pci_liveupdate - PCI Live Update state for a struct pci_dev
   * @outgoing: State preserved for the next kernel.
+ * @incoming: State preserved by the previous kernel.
   */
  struct pci_liveupdate {
  	struct pci_dev_ser *outgoing;
+	struct pci_dev_ser *incoming;
  };
 
  struct pci_dev;

@@ -28,6 +30,8 @@ int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh);
  void pci_liveupdate_unregister_flb(struct liveupdate_file_handler *fh);
  int pci_liveupdate_preserve(struct pci_dev *dev);
  void pci_liveupdate_unpreserve(struct pci_dev *dev);
+void pci_liveupdate_finish(struct pci_dev *dev);
+bool pci_liveupdate_is_incoming(struct pci_dev *dev);
  #else
  static inline int pci_liveupdate_register_flb(struct liveupdate_file_handler *fh)
  {

@@ -46,6 +50,15 @@ static inline int pci_liveupdate_preserve(struct pci_dev *dev)
  static inline void pci_liveupdate_unpreserve(struct pci_dev *dev)
  {
  }
+
+static inline void pci_liveupdate_finish(struct pci_dev *dev)
+{
+}
+
+static inline bool pci_liveupdate_is_incoming(struct pci_dev *dev)
+{
+	return false;
+}
  #endif
 
  #endif /* LINUX_PCI_LIVEUPDATE_H */

Quoted 9 lines · David Matlack

CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the domain and bdf can be guaranteed to fit in an unsigned long and be used as the xarray key.

drivers/pci/Kconfig +0 -0

index 3781e2b5f095..8af20f558086 100644

drivers/pci/Kconfig config VGA_ARB_MAX_GPUS · line 276

Quoted 5 lines

drivers/pci/Kconfig +1 -1

@@ -273,7 +273,7 @@ config VGA_ARB_MAX_GPUS
 
  config PCI_LIVEUPDATE
      bool "PCI Live Update Support"
-     depends on PCI && LIVEUPDATE
+     depends on PCI && LIVEUPDATE && 64BIT

One question about adding 64BIT to the dependency:

As I understand it, enabling CONFIG_64BIT essentially means that we are building a 64-bit kernel, and a 32-bit architecture cannot normally enable CONFIG_64BIT.

If that is the case, would depends on 64BIT be necessary here? Or is PCI Live Update already inherently restricted to 64-bit architectures by the existing LIVEUPDATE/architecture configuration, so that this dependency would be redundant?

If this problem has already discussed, I am very sorry about this.

Quoted 28 lines · Zhu Yanjun

Quoted 9 lines · David Matlack

CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the domain and bdf can be guaranteed to fit in an unsigned long and be used as the xarray key.

drivers/pci/Kconfig +0 -0

index 3781e2b5f095..8af20f558086 100644

drivers/pci/Kconfig config VGA_ARB_MAX_GPUS · line 276

Quoted 5 lines

drivers/pci/Kconfig +1 -1

@@ -273,7 +273,7 @@ config VGA_ARB_MAX_GPUS
 
  config PCI_LIVEUPDATE
      bool "PCI Live Update Support"
-     depends on PCI && LIVEUPDATE
+     depends on PCI && LIVEUPDATE && 64BIT

One question about adding 64BIT to the dependency:

As I understand it, enabling CONFIG_64BIT essentially means that we are building a 64-bit kernel, and a 32-bit architecture cannot normally enable CONFIG_64BIT.

If that is the case, would depends on 64BIT be necessary here? Or is PCI Live Update already inherently restricted to 64-bit architectures by the existing LIVEUPDATE/architecture configuration, so that this dependency would be redundant?

Quoted 1 line

If this problem has already discussed, I am very sorry about this.

The necessity is that the PCI core needs to store more than 32-bits in the unsigned long xarray key (see the snippet above). The dependency on CONFIG_64BIT ensures that unsigned long is big enough. We could probably remove the dependency but I would rather wait until someone with a 32-bit build has a real use-case for using PCI_LIVEUPDATE before putting any effort into it.

Quoted 29 lines · David Matlack

Quoted 28 lines · Zhu Yanjun

Quoted 9 lines · David Matlack

CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the domain and bdf can be guaranteed to fit in an unsigned long and be used as the xarray key.

drivers/pci/Kconfig +0 -0

index 3781e2b5f095..8af20f558086 100644

drivers/pci/Kconfig config VGA_ARB_MAX_GPUS · line 276

Quoted 5 lines

drivers/pci/Kconfig +1 -1

@@ -273,7 +273,7 @@ config VGA_ARB_MAX_GPUS
 
  config PCI_LIVEUPDATE
      bool "PCI Live Update Support"
-     depends on PCI && LIVEUPDATE
+     depends on PCI && LIVEUPDATE && 64BIT

One question about adding 64BIT to the dependency:

As I understand it, enabling CONFIG_64BIT essentially means that we are building a 64-bit kernel, and a 32-bit architecture cannot normally enable CONFIG_64BIT.

If that is the case, would depends on 64BIT be necessary here? Or is PCI Live Update already inherently restricted to 64-bit architectures by the existing LIVEUPDATE/architecture configuration, so that this dependency would be redundant?

Quoted 8 lines

Quoted 1 line

If this problem has already discussed, I am very sorry about this.

The necessity is that the PCI core needs to store more than 32-bits in the unsigned long xarray key (see the snippet above). The dependency on CONFIG_64BIT ensures that unsigned long is big enough. We could probably remove the dependency but I would rather wait until someone with a 32-bit build has a real use-case for using PCI_LIVEUPDATE before putting any effort into it.

KHO or live update themselves don't support 32-bit platforms and there are no plans to do so either. So I don't think you even need to have a dependency on 64BIT in PCI_LIVEUPDATE. Only 64 bit architectures define ARCH_SUPPORTS_KEXEC_HANDOVER, so PCI_LIVEUPDATE and others indirectly inherit the dependency.

If you'd like to be extra safe, then probably you should add a dependency to 64BIT in KEXEC_HANDOVER directly. Though I think that can be a separate patch independent from this series.

Quoted 47 lines · Pratyush Yadav

Quoted 29 lines · David Matlack

Quoted 28 lines · Zhu Yanjun

Quoted 9 lines · David Matlack

CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the domain and bdf can be guaranteed to fit in an unsigned long and be used as the xarray key.

drivers/pci/Kconfig +0 -0

index 3781e2b5f095..8af20f558086 100644

drivers/pci/Kconfig config VGA_ARB_MAX_GPUS · line 276

Quoted 5 lines

drivers/pci/Kconfig +1 -1

@@ -273,7 +273,7 @@ config VGA_ARB_MAX_GPUS
 
  config PCI_LIVEUPDATE
      bool "PCI Live Update Support"
-     depends on PCI && LIVEUPDATE
+     depends on PCI && LIVEUPDATE && 64BIT

One question about adding 64BIT to the dependency:

As I understand it, enabling CONFIG_64BIT essentially means that we are building a 64-bit kernel, and a 32-bit architecture cannot normally enable CONFIG_64BIT.

If that is the case, would depends on 64BIT be necessary here? Or is PCI Live Update already inherently restricted to 64-bit architectures by the existing LIVEUPDATE/architecture configuration, so that this dependency would be redundant?

Quoted 8 lines

Quoted 1 line

If this problem has already discussed, I am very sorry about this.

The necessity is that the PCI core needs to store more than 32-bits in the unsigned long xarray key (see the snippet above). The dependency on CONFIG_64BIT ensures that unsigned long is big enough. We could probably remove the dependency but I would rather wait until someone with a 32-bit build has a real use-case for using PCI_LIVEUPDATE before putting any effort into it.

KHO or live update themselves don't support 32-bit platforms and there are no plans to do so either. So I don't think you even need to have a dependency on 64BIT in PCI_LIVEUPDATE. Only 64 bit architectures define ARCH_SUPPORTS_KEXEC_HANDOVER, so PCI_LIVEUPDATE and others indirectly inherit the dependency.

Quoted 3 lines

If you'd like to be extra safe, then probably you should add a dependency to 64BIT in KEXEC_HANDOVER directly. Though I think that can be a separate patch independent from this series.

It should be in both places then. PCI_LIVEUPDATE explicitly requires 64BIT for its own use of unsigned long, so it should have an explicit dependency. If KEXEC_HANDOVER requires 64-bit for its own specific purposes, then it should have an explicit Kconfig dependency as well. That way if and when someone wants to add 32-bit support we know exactly which configs need to add support.

Quoted 52 lines · David Matlack

Quoted 47 lines · Pratyush Yadav

Quoted 29 lines · David Matlack

Quoted 28 lines · Zhu Yanjun

Quoted 9 lines · David Matlack

CONFIG_64BIT is now required to enable CONFIG_PCI_LIVEUPDATE so that the domain and bdf can be guaranteed to fit in an unsigned long and be used as the xarray key.

drivers/pci/Kconfig +0 -0

index 3781e2b5f095..8af20f558086 100644

drivers/pci/Kconfig config VGA_ARB_MAX_GPUS · line 276

Quoted 5 lines

drivers/pci/Kconfig +1 -1

@@ -273,7 +273,7 @@ config VGA_ARB_MAX_GPUS
 
  config PCI_LIVEUPDATE
      bool "PCI Live Update Support"
-     depends on PCI && LIVEUPDATE
+     depends on PCI && LIVEUPDATE && 64BIT

One question about adding 64BIT to the dependency:

As I understand it, enabling CONFIG_64BIT essentially means that we are building a 64-bit kernel, and a 32-bit architecture cannot normally enable CONFIG_64BIT.

If that is the case, would depends on 64BIT be necessary here? Or is PCI Live Update already inherently restricted to 64-bit architectures by the existing LIVEUPDATE/architecture configuration, so that this dependency would be redundant?

Quoted 8 lines

Quoted 1 line

If this problem has already discussed, I am very sorry about this.

The necessity is that the PCI core needs to store more than 32-bits in the unsigned long xarray key (see the snippet above). The dependency on CONFIG_64BIT ensures that unsigned long is big enough. We could probably remove the dependency but I would rather wait until someone with a 32-bit build has a real use-case for using PCI_LIVEUPDATE before putting any effort into it.

KHO or live update themselves don't support 32-bit platforms and there are no plans to do so either. So I don't think you even need to have a dependency on 64BIT in PCI_LIVEUPDATE. Only 64 bit architectures define ARCH_SUPPORTS_KEXEC_HANDOVER, so PCI_LIVEUPDATE and others indirectly inherit the dependency.

Quoted 3 lines

If you'd like to be extra safe, then probably you should add a dependency to 64BIT in KEXEC_HANDOVER directly. Though I think that can be a separate patch independent from this series.

Quoted 6 lines

It should be in both places then. PCI_LIVEUPDATE explicitly requires 64BIT for its own use of unsigned long, so it should have an explicit dependency. If KEXEC_HANDOVER requires 64-bit for its own specific purposes, then it should have an explicit Kconfig dependency as well. That way if and when someone wants to add 32-bit support we know exactly which configs need to add support.

Well, I don't think we are ever adding 32-bit support. Most 32-bit support in the kernel is being deprecated or removed, so I really don't think it makes much sense to extend KHO/live update to 32-bit architectures.

But anyway, if you'd like to explicitly mark PCI as needing 64-bit, that sounds fine too in the very very unlikely event we do add 32-bit support.

Document how driver binding works during a Live Update and what the PCI core expects of drivers and users. Note that this is only a description of the current division of responsibilities. These can change in the future if we decide.

Reviewed-by Pasha Tatashin <[email protected]>

Reviewed-by Pranjal Shrivastava <[email protected]>

Reviewed-by Samiullah Khawaja <[email protected]>

Signed-off-by David Matlack <[email protected]>

---
 drivers/pci/liveupdate.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

drivers/pci/liveupdate.c +0 -0

index 5ce5f8b36902..0f7a018ddc66 100644

During a Live Update, preserved devices must be allowed to continue performing memory transactions so the kernel cannot change the fabric topology, including bus numbers, since that would require disabling and flushing any memory transactions first.

To keep bus numbers constant, always preserve the secondary and subordinate bus numbers assigned to bridges during scanning, instead of assigning new ones, if any PCI devices were preserved. Note that the kernel preserves bus numbers even on bridges without any downstream endpoints that were preserved. This avoids accidentally assigning a bridge a new window that overlaps with a preserved device that is downstream of a different bridge.

drivers/pci/liveupdate.c +18 -0

+bool pci_liveupdate_preserve_bus_numbers(struct pci_bus *bus, struct pci_dev *dev)
+{
+	struct pci_dev *parent = bus->self;
+
+	if (dev->liveupdate.preserve_bus_numbers)
+		return true;
+
+	if (parent && parent->liveupdate.preserve_bus_numbers) {
+		/*
+		 * Preserve bus numbers if the parent bridge is required to
+		 * preserve bus numbers. Otherwise the PCI core could expand
+		 * this bridge's reservation beyond its parent (which cannot
+		 * expand).
+		 */
+		dev->liveupdate.preserve_bus_numbers = true;
+	} else {
+		/*
+		 * Otherwise preserve bus numbers if there are any incoming

Quoted 31 lines · David Matlack

During a Live Update, preserved devices must be allowed to continue performing memory transactions so the kernel cannot change the fabric topology, including bus numbers, since that would require disabling and flushing any memory transactions first.

To keep bus numbers constant, always preserve the secondary and subordinate bus numbers assigned to bridges during scanning, instead of assigning new ones, if any PCI devices were preserved. Note that the kernel preserves bus numbers even on bridges without any downstream endpoints that were preserved. This avoids accidentally assigning a bridge a new window that overlaps with a preserved device that is downstream of a different bridge.

drivers/pci/liveupdate.c +18 -0

+bool pci_liveupdate_preserve_bus_numbers(struct pci_bus *bus, struct pci_dev *dev)
+{
+	struct pci_dev *parent = bus->self;
+
+	if (dev->liveupdate.preserve_bus_numbers)
+		return true;
+
+	if (parent && parent->liveupdate.preserve_bus_numbers) {
+		/*
+		 * Preserve bus numbers if the parent bridge is required to
+		 * preserve bus numbers. Otherwise the PCI core could expand
+		 * this bridge's reservation beyond its parent (which cannot
+		 * expand).
+		 */
+		dev->liveupdate.preserve_bus_numbers = true;
+	} else {
+		/*
+		 * Otherwise preserve bus numbers if there are any incoming

drivers/pci/liveupdate.c static void pci_liveupdate_flb_put_incoming(void) · line 565

Quoted 10 lines

drivers/pci/liveupdate.c +10 -0

+		 * preserved devices. This ensures that the PCI core does not
+		 * allocate a bus number to a non-preserved device that
+		 * conflicts with the bus number already assigned to a preserved
+		 * device.
+		 *
+		 * This is slightly more restrictive than it needs to be. For
+		 * example, each host bridges have their own range of bus
+		 * numbers that won't conflict with other host bridges. But the
+		 * previous kernel should have assigned a sane bus topology and
+		 * it is simpler to just adopt that entire topology.

s/each ... bridges have their/each ... bridge has its/

It's true there should be no bus number conflicts between host bridges, but it does require the domain as well.

drivers/pci/liveupdate.c static void pci_liveupdate_flb_put_incoming(void) · line 571

Quoted 6 lines

drivers/pci/liveupdate.c +6 -0

+		 */
+		dev->liveupdate.preserve_bus_numbers =
+			pci_has_incoming_preserved_devices();
+	}
+
+	return dev->liveupdate.preserve_bus_numbers;

I'm not sure why you don't just return pci_has_incoming_preserved_devices() in all cases, which is what the commit log suggests this patch does. What's gained by all the logic here? It's not like devices will be hot-added during the kexec.

Quoted 33 lines · Bjorn Helgaas

Quoted 31 lines · David Matlack

drivers/pci/liveupdate.c +31 -0

+bool pci_liveupdate_preserve_bus_numbers(struct pci_bus *bus, struct pci_dev *dev)
+{
+	struct pci_dev *parent = bus->self;
+
+	if (dev->liveupdate.preserve_bus_numbers)
+		return true;
+
+	if (parent && parent->liveupdate.preserve_bus_numbers) {
+		/*
+		 * Preserve bus numbers if the parent bridge is required to
+		 * preserve bus numbers. Otherwise the PCI core could expand
+		 * this bridge's reservation beyond its parent (which cannot
+		 * expand).
+		 */
+		dev->liveupdate.preserve_bus_numbers = true;
+	} else {
+		/*
+		 * Otherwise preserve bus numbers if there are any incoming
+		 * preserved devices. This ensures that the PCI core does not
+		 * allocate a bus number to a non-preserved device that
+		 * conflicts with the bus number already assigned to a preserved
+		 * device.
+		 *
+		 * This is slightly more restrictive than it needs to be. For
+		 * example, each host bridges have their own range of bus
+		 * numbers that won't conflict with other host bridges. But the
+		 * previous kernel should have assigned a sane bus topology and
+		 * it is simpler to just adopt that entire topology.
+		 */
+		dev->liveupdate.preserve_bus_numbers =
+			pci_has_incoming_preserved_devices();

Quoted 8 lines

drivers/pci/liveupdate.c static void pci_liveupdate_flb_put_incoming(void) · line 571

Quoted 3 lines

drivers/pci/liveupdate.c +3 -0

+	}
+
+	return dev->liveupdate.preserve_bus_numbers;

I'm not sure why you don't just return pci_has_incoming_preserved_devices() in all cases, which is what the commit log suggests this patch does. What's gained by all the logic here? It's not like devices will be hot-added during the kexec.

To protect against pci_has_incoming_preserved_devices() flipping from true to false while the PCI core is in the middle of a scan. It is not likely to ever happen given most host bridge scanning should happen during early boot, but theoretically possible with the way the PCI core code is structured. I did not see way to structurally ensure these 2 things cannot race. A lot of the host bridge scanning happens without taking the rescan lock, for example.

Quoted 43 lines · David Matlack

Quoted 33 lines · Bjorn Helgaas

Quoted 31 lines · David Matlack

drivers/pci/liveupdate.c +31 -0

+bool pci_liveupdate_preserve_bus_numbers(struct pci_bus *bus, struct pci_dev *dev)
+{
+	struct pci_dev *parent = bus->self;
+
+	if (dev->liveupdate.preserve_bus_numbers)
+		return true;
+
+	if (parent && parent->liveupdate.preserve_bus_numbers) {
+		/*
+		 * Preserve bus numbers if the parent bridge is required to
+		 * preserve bus numbers. Otherwise the PCI core could expand
+		 * this bridge's reservation beyond its parent (which cannot
+		 * expand).
+		 */
+		dev->liveupdate.preserve_bus_numbers = true;
+	} else {
+		/*
+		 * Otherwise preserve bus numbers if there are any incoming
+		 * preserved devices. This ensures that the PCI core does not
+		 * allocate a bus number to a non-preserved device that
+		 * conflicts with the bus number already assigned to a preserved
+		 * device.
+		 *
+		 * This is slightly more restrictive than it needs to be. For
+		 * example, each host bridges have their own range of bus
+		 * numbers that won't conflict with other host bridges. But the
+		 * previous kernel should have assigned a sane bus topology and
+		 * it is simpler to just adopt that entire topology.
+		 */
+		dev->liveupdate.preserve_bus_numbers =
+			pci_has_incoming_preserved_devices();

Quoted 8 lines

drivers/pci/liveupdate.c static void pci_liveupdate_flb_put_incoming(void) · line 571

Quoted 3 lines

drivers/pci/liveupdate.c +3 -0

+	}
+
+	return dev->liveupdate.preserve_bus_numbers;

I'm not sure why you don't just return pci_has_incoming_preserved_devices() in all cases, which is what the commit log suggests this patch does. What's gained by all the logic here? It's not like devices will be hot-added during the kexec.

Quoted 7 lines

To protect against pci_has_incoming_preserved_devices() flipping from true to false while the PCI core is in the middle of a scan. It is not likely to ever happen given most host bridge scanning should happen during early boot, but theoretically possible with the way the PCI core code is structured. I did not see way to structurally ensure these 2 things cannot race. A lot of the host bridge scanning happens without taking the rescan lock, for example.

After working on this more, I do see a way to simplify the logic in pci_liveupdate_preserve_bus_numbers().

pci_liveupdate_preserve_bus_numbers() is used in 2 places during scanning. First to decide if the PCI core should preserve bus numbers or is free to allocate new ones, and second to decide if the PCI core is allowed to assign bus numbers to bridges that are missing bus numbers.

The latter case should never happen during initial scanning unless a bridge was somehow reset during the kexec, but could legitimately happen if a bridge is later hot-plugged and I did not want Live Update to unnecessarily break that scenario. But then that creates this problem where pci_has_incoming_preserved_devices() can suddenly flip from true to false at any time and I needed all the complex logic to keep it consistent for a given scan.

Instead we can split the handling of these cases:

1. When the PCI core needs to decide if it should preserve bus numbers due to Live Update, pci_liveupdate_preserve_bus_numbers() can return true forever if any device was preserved by the previous kernel, which simplifies the logic.

2. Then to handle the case of a bridge is enumerated that does not have bus numbers assigned, we can handle that separately. If we reorder this with the next commit so the PCI core knows exactly which bridges have preserved downstream endpoints, then it is possible to determine if it is safe for the PCI core to allow bus numbers to be assigned to an unconfigured bridge.

After re-ordering, we can end up with something like this:

  bool pci_liveupdate_preserve_bus_numbers(void)
  {
  	return pci_liveupdate.had_incoming;
  }

  bool pci_liveupdate_refuse_bus_numbers(struct pci_bus *bus, struct pci_dev *dev)
  {
  	struct pci_dev *bridge;

  	for_each_pci_bridge(bridge, bus) {
  		if (!bridge->liveupdate.was_incoming || bridge->subordinate)
  			continue;

  		pci_err(dev, "Not assigning bus numbers, preserved bridge %s lost its bus number configuration\n",
  			pci_name(bridge));
  		return true;
  	}

  	return false;
  }

The net effect on pci_scan_bridge_extend() is:

  bool preserve_bus_numbers = !pcibios_assign_all_busses() ||
  			    pci_liveupdate_preserve_bus_numbers();
  ...
  	if (pci_liveupdate_refuse_bus_numbers(bus, dev))
  		goto out;

We could further scope pci_liveupdate_preserve_bus_numbers() to only return true for host bridges with preserved endpoints downstream, but that doesn't seem worth the extra complexity. It also seems nice to keep the pci_liveupdate_preserve_bus_numbers() policy global to match how the existing pcibios_assign_all_busses() policy is global.

Does that look reasonable?