On Tue, Sep 22, 2026 at 11:36 AM Zhu Yanjun <yanjun.zhu@linux.dev> wrote:

在 2026/9/18 13:06, David Matlack 写道:

Future Work
-----------

Following this series, we expect to make further improvements to the PCI
core support for Live Update:

   - Allow P2P across Live Update by avoiding resizing or moving
     preserved device BARs and preserving all upstream bridge windows.

   - Support preserving Virtual Functions by preserving SR-IOV
     configuration on PFs and enumerating VFs after Live Update.

Preserving the PCIe topology, bus numbers, ACS, and Bus Mastering across
kexec is a foundational step for minimizing downtime.

As we look toward complete end-to-end support for DMA preservation
across Live Update—especially for VFIO device passthrough and dma-buf
sharing scenarios—IOMMU table/domain preservation becomes crucial to
prevent IOMMU page faults when devices continue performing DMA during kexec.

I would like to ask about the current status and roadmap regarding IOMMU
Live Update / KHO (Kexec Handover) support:

Is there an ongoing effort or RFC series for IOMMU handover / page-table
preservation currently in development or under discussion?

How is the coordination between the PCI core Live Update mechanisms and
the IOMMU subsystem being envisioned for preserving IOVA mappings (e.g.,
restoring domains or handing over root tables)?

Any pointers to active discussion threads, RFCs, or future plans
regarding IOMMU participation in Live Update would be greatly appreciated.

The first IOMMU series to support Live update, can be found here:

  https://lore.kernel.org/linux-iommu/20260921004834.2601285-1-skhawaja@google.com/

Thanks.

I have a question regarding the restoration sequencing when module dependencies are involved during a Live Update reboot.

For the standard hardware/driver stack, the sequence seems to naturally follow the kernel's early initcalls and device probing (e.g., IOMMU early hardware handover -> PCI bus topology/BME preservation -> IOMMU domain attach & DMA ownership claim -> VFIO/iommufd cdev binding).

However, if there is a custom kernel module or subsystem (let's call it Module A) that is not part of the standard PCI/IOMMU device probe callback chain, but strictly depends on the fully restored state of PCI, IOMMU, and VFIO/iommufd:

1. What is the recommended or standardized way in the Live Update architecture to guarantee that Module A's restoration happens after all its underlying dependencies (PCI / IOMMU / VFIO) have completely finished their restore processes?

2. Is the expectation to rely on LUO (Live Update Orchestrator) phase notification callbacks (e.g., late restore notifiers), Driver Core mechanisms like -EPROBE_DEFER / device_link, or something else?

Any guidance on how cross-subsystem restoration order and async probe dependencies should be handled in the Live Update framework would be greatly appreciated.

Thanks,

Yanjun Zhu

The IOMMU series builds on top of the PCI core support (this series)
and the VFIO series linked further up in the cover letter.

-- 
Best Regards,
Yanjun.Zhu