[PATCH v2 10/22] vfio/pci: Skip reset of preserved device after Live Update
Jacob Pan
jacob.pan at linux.microsoft.com
Fri Mar 13 08:39:18 PDT 2026
Hi David,
On Thu, 12 Mar 2026 23:39:45 +0000
David Matlack <dmatlack at google.com> wrote:
> On 2026-03-09 10:32 AM, David Matlack wrote:
> > On Fri, Feb 27, 2026 at 9:57 AM Alex Williamson <alex at shazbot.org>
> > wrote:
>
> > > Sorry if I don't have the whole model in my head yet, but is
> > > exposing the restriction to the vfio user of the device
> > > sufficient to manage the liveupdate orchestration? For example,
> > > a VFIO_DEVICE_INFO_CAP pushes the knowledge to QEMU... what does
> > > QEMU do with that knowledge? Who imposes the policy decision to
> > > decide what support is sufficient?
> >
> > Hm.. good questions. I don't think we want userspace inspecting bits
> > exposed by the kernel and trying to infer exactly what's being
> > preserved and whether it's "good enough" to use. And such a UAPI
> > would become tech debt once we finish development, I suspect.
> >
> > A better approach would be to hide this support from userspace until
> > we decide it is ready for production use-cases.
> >
> > To enable development and testing, we can add an opt-in mechanism
>
> Here is what I am trending towards sending in v3 as the opt-in
> mechanism:
>
> diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
> index 1e82b44bda1a..770231554221 100644
> --- a/drivers/vfio/pci/Kconfig
> +++ b/drivers/vfio/pci/Kconfig
> @@ -58,6 +58,27 @@ config VFIO_PCI_ZDEV_KVM
> config VFIO_PCI_DMABUF
> def_bool y if VFIO_PCI_CORE && PCI_P2PDMA && DMA_SHARED_BUFFER
>
> +config VFIO_PCI_LIVEUPDATE
> + bool "VFIO PCI support for Live Update (EXPERIMENTAL)"
> + depends on LIVEUPDATE && VFIO_PCI
> + help
> + Support for preserving devices bound to vfio-pci across a
> Live
> + Update. The eventual goal is that preserved devices can run
> + uninterrupted during a Live Update, including DMA to
> preserved
> + memory buffers and P2P. However there are many steps still
> needed to
> + achieve this, including:
> +
> + - Preservation of iommufd files
> + - Preservation of IOMMU driver state
In the interim, what do you think about moving forward with noiommu
mode without preserving IOMMU driver state? I’ve tested your
vfio_pci_liveupdate_kexec_test with the noiommu cdev, and it works as
expected.
> + - Preservation of PCI state (BAR resources, device state,
> ...)
> + - Preservation of vfio-pci driver state
> +
> + This option should only be enabled by developers working on
> + implementing this support. Once enough support has landed
> in the
> + kernel, this option will no longer be marked EXPERIMENTAL.
> +
> + If you don't know what to do here, say N.
> +
> source "drivers/vfio/pci/mlx5/Kconfig"
>
> source "drivers/vfio/pci/hisilicon/Kconfig"
More information about the kexec
mailing list