Re: [RFC PATCH 00/21] VFIO live update support

[Vipin Sharma <vipinsh@google.com>]

On 2025-10-18 20:06:41, Jason Gunthorpe wrote:
> On Sat, Oct 18, 2025 at 03:53:09PM -0700, Vipin Sharma wrote:
> > 
> > This series has very minimal PCI support. For example, it is skipping
> > DMA disable on the VFIO PCI device during kexec reboot and saving initial PCI
> > state during first open (bind) of the device.
> > 
> > We do need proper PCI support, few examples:
> > 
> > - Not disabling DMA bit on bridges upstream of the leaf VFIO PCI device node.
> 
> So limited to topology without bridges
> 
> > - Not writing to PCI config during device enumeration.
> 
> I think this should be included here
> 
> > - Not autobinding devices to their default driver. My testing works on
> >   devices which don't have driver bulit in the kernel so there is no
> >   probing by other drivers.
> 
> Good enough for now, easy to not build in such drivers.
> 
> > - PCI enable and disable calls support.
> 
> ?? Shouldn't vfio restore skip calling pci enable? Seems like there
> should be some solution here.

I think PCI subsystem when restores/enumerates a preserved device after
kexec, should enable the device and VFIO can skip calling this. By
default enable mostly does:

1. Increments enable_cnt.
2. Enables to bus master of upstream bridges.
3. Reset INTx Disable bit in command register.
4. Enables IO and Memory space bit in command register.
5. Apply fixups.
6. Sets power state to D0.

On a preserved and restored device, I think only item 1 needs to happen,
2-6 should remain same if device config space is not written during
enumeration and state is recreated by reading values in config space.

I believe this should be part of PCI preservation and restoration
series. VFIO can assume that device is enabled and skip the call or check if it is not enabled
then fail the restoration.