Top-posting, to make this easy to process: Bjorn, sorry for bothering you, but I wondered: is below patch still in your review queue? It fixes a regression that made it to a longterm series that two people reported.
Ciao, Thorsten On 4/15/26 17:56, 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): > > ddbridge 0000:05:00.0: detected Digital Devices Cine S2 V6 DVB adapter > ddbridge 0000:05:00.0: cannot read registers > ddbridge 0000:05:00.0: fail > > BIOS assigns an incorrect BAR to the DVB adapter which doesn't fit into > the upstream bridge window. The kernel corrects the BAR assignment: > > pci 0000:07:00.0: BAR 0 [mem 0xfffffffffc500000-0xfffffffffc50ffff 64bit]: > can't claim; no compatible bridge window > pci 0000:07:00.0: BAR 0 [mem 0xfc500000-0xfc50ffff 64bit]: assigned > > Correction of the BAR assignment happens in an x86-specific fs_initcall, > pcibios_assign_resources(), after device enumeration in a subsys_initcall. > This order was introduced at the behest of Linus in 2004: > > https://git.kernel.org/tglx/history/c/a06a30144bbc > > No other architecture performs such a late BAR correction. > > Bernd bisected the issue to commit a2f1e22390ac ("PCI/ERR: Ensure error > recoverability at all times"), but it only occurs in the absence of commit > 4d4c10f763d7 ("PCI: Explicitly put devices into D0 when initializing"). > This combination exists in stable kernel v6.12.70, but not in mainline, > hence Bernd cannot reproduce the issue with mainline. > > 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: > > vfio_pci_core_register_device() > vfio_pci_set_power_state() > pci_restore_state() > > But only if the device's current_state is PCI_UNKNOWN, as it was prior to > commit 4d4c10f763d7. Since the commit, it is PCI_D0, which changes the > behavior of vfio_pci_set_power_state() to no longer restore the state > without saving it first. > > Alexandre is reporting the same issue as Bernd, but in his case, mainline > is affected as well. The difference is that on Alexandre's system, the > host kernel binds a driver to the device which is unbound prior to > passthrough, whereas on Bernd's system no driver gets bound by the host > kernel. > > Unbinding sets current_state to PCI_UNKNOWN in pci_device_remove(), so > when vfio-pci is subsequently bound to the device, pci_restore_state() is > once again called without invoking pci_save_state() first. > > To robustly fix the issue, always update saved_config_space upon resource > assignment. > > Reported-by: Bernd Schumacher <[email protected]> > Tested-by: Bernd Schumacher <[email protected]> > Closes: https://lore.kernel.org/r/[email protected]/ > Reported-by: Alexandre N. <[email protected]> > Tested-by: Alexandre N. <[email protected]> > Closes: > https://lore.kernel.org/r/[email protected]/ > Fixes: a2f1e22390ac ("PCI/ERR: Ensure error recoverability at all times") > Signed-off-by: Lukas Wunner <[email protected]> > Cc: [email protected] # v6.12+ > --- > drivers/pci/setup-res.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c > index e5fcadf..1769ba9 100644 > --- a/drivers/pci/setup-res.c > +++ b/drivers/pci/setup-res.c > @@ -102,6 +102,7 @@ static void pci_std_update_resource(struct pci_dev *dev, > int resno) > } > > pci_write_config_dword(dev, reg, new); > + dev->saved_config_space[reg / 4] = new; > pci_read_config_dword(dev, reg, &check); > > if ((new ^ check) & mask) { > @@ -112,6 +113,7 @@ static void pci_std_update_resource(struct pci_dev *dev, > int resno) > if (res->flags & IORESOURCE_MEM_64) { > new = region.start >> 16 >> 16; > pci_write_config_dword(dev, reg + 4, new); > + dev->saved_config_space[(reg + 4) / 4] = new; > pci_read_config_dword(dev, reg + 4, &check); > if (check != new) { > pci_err(dev, "%s: error updating (high %#010x != > %#010x)\n",
