Re: [PATCH v2 10/22] vfio/pci: Skip reset of preserved device after Live Update

Jacob Pan
2026-01-30T00:31:59Z

Hi David,

On Thu, 29 Jan 2026 22:33:13 +0000
David Matlack <dmatlack@google.com> wrote:

> On 2026-01-29 02:21 PM, Jacob Pan wrote:
> > On Thu, 29 Jan 2026 21:24:57 +0000 David Matlack
> > <dmatlack@google.com> wrote:
>
> > > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> > > b/drivers/vfio/pci/vfio_pci_core.c index
> > > b01b94d81e28..c9f73f597797 100644 ---
> > > a/drivers/vfio/pci/vfio_pci_core.c +++
> > > b/drivers/vfio/pci/vfio_pci_core.c @@ -515,12 +515,24 @@ int
> > > vfio_pci_core_enable(struct vfio_pci_core_device *vdev) if (ret)
> > > goto out_power;
> > >
> > > - /* If reset fails because of the device lock, fail this
> > > path entirely */
> > > - ret = pci_try_reset_function(pdev);
> > > - if (ret == -EAGAIN)
> > > - goto out_disable_device;
> > > + if (vdev->liveupdate_incoming_state) {
> > > + /*
> > > + * This device was preserved by the previous
> > > kernel across a
> > > + * Live Update, so it does not need to be reset.
> > > + */
> > > + vdev->reset_works =
> > > vdev->liveupdate_incoming_state->reset_works;
> >
> > Just wondering what happened to skipping the bus master clearing. I
> > understand this version does not preserve the device itself yet; I’m
> > just curious whether there were specific difficulties that led to
> > dropping the earlier patch which skipped clearing bus master.
>
> Hi Jacob,
>
> There's several places where bus master gets cleared that we need to
> eventually eliminate to fully preserve the device.
>
> 1. vfio_pci_liveupdate_freeze() clears it during shutdown when it
> restores vdev->pci_saved_state.
> 2. pci_device_shutdown() clears it during shutdown.
> 3. vfio_pci_core_enable() clears it when the preserved device file
> is bound to an iommufd after the Live Update (in
> vfio_pci_core_enable()).
>
> I think it would be safe to skip (3) in this series, since that's very
> similar to how this series skips resets during vfio_pci_core_enable()
> for preserved devices.
>
> But I don't think it would be safe to skip (1) or (2) until the
> attached iommufd is fully preserved.
>
> If you are just asking about (3) then I agree it could be skipped and
> I can include that in the next version.

I was just asking about (3) and trying to understand the asymmetric
handling compared to reset. I don’t have a strong preference since this
is temporary—thanks for the explanation.

I’ve been testing my noiommu cdev patches on top of yours, and so far
they behave the same as with a real IOMMU. As you noted, however, final
device preservation still depends on iommufd.