On Thu, 16 Apr 2026, Lukas Wunner wrote: > On Thu, Apr 16, 2026 at 02:08:03PM +0300, Ilpo Järvinen wrote: > > On Wed, 15 Apr 2026, Lukas Wunner wrote: > > > Bernd reports passthrough failure of a Digital Devices Cine S2 V6 DVB > > > adapter plugged into an ASRock X570S PG Riptide board with BIOS version > > > P5.41 (09/07/2023): > [...] > > > Since a2f1e22390ac, config space is saved on enumeration, prior to BAR > > > correction. Upon passthrough, the corrected BAR is overwritten with the > > > incorrect saved value by: > > > > I'm wondering if there's something that makes this problem specific to > > only standard BARs? > > > > Can other resources, namely IOV resources or bridge windows, similarly be > > updated "too late" and not get correctly updated into the saved config > > space? > > IOV registers are not saved, they're reconstructed from pci_dev->resource[]: > > pci_restore_iov_state() > sriov_restore_state() > pci_update_resource() > pci_iov_update_resource() > > Bridge windows are saved when portdrv probes (see call to pci_save_state() > in pcie_portdrv_probe()) and that happens after the fs_initcall() because > portdrv is registered from a device_initcall(). So those should be fine > as well. > > (FWIW sashiko also flagged the bridge windows not getting saved as an > (alleged) problem.) > > Thanks for taking a look!
Okay, fair. It feels a bit odd they're all handled differently (not a problem when it comes to this patch). Maybe it would make sense to eventually restore them all from the pci_dev's resource array. Add something like pci_restore_resources() that would restore all the resources that are relevant for the type. I don't know if that's doable when it comes to the order of things, especially with sriov, but if doable, it would prevent them ever getting out of sync again and would avoid the trouble of having to save them elsewhere. -- i.
