在 2026/9/22 11:53, David Matlack 写道:
> 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