Hi David, On Thu, 29 Jan 2026 22:33:13 +0000 David Matlack <[email protected]> wrote:
> On 2026-01-29 02:21 PM, Jacob Pan wrote: > > On Thu, 29 Jan 2026 21:24:57 +0000 David Matlack > > <[email protected]> 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.
