On 29.01.2026 15:09, Roger Pau Monné wrote: > On Thu, Jan 29, 2026 at 02:08:27PM +0100, Jan Beulich wrote: >> Legacy PCI devices don't have any extended config space. Reading any part >> thereof may return all ones or other arbitrary data, e.g. in some cases >> base config space contents repeatedly. >> >> Logic follows Linux 6.19-rc's pci_cfg_space_size(), albeit leveraging our >> determination of device type; in particular some comments are taken >> verbatim from there. Like with Linux'es CONFIG_PCI_QUIRKS, only the alias >> detection logic is covered by the new "pci=no-quirks". The singular access >> at PCI_CFG_SPACE_SIZE is left unconditional. >> >> Signed-off-by: Jan Beulich <[email protected]> >> Acked-by: Roger Pau Monné <[email protected]> >> --- >> The warning near the bottom of pci_check_extcfg() may be issued multiple >> times for a single device now. Should we try to avoid that? >> >> Note that no vPCI adjustments are done here, but they're going to be >> needed: Whatever requires extended capabilities will need re- >> evaluating / newly establishing / tearing down in case an invocation of >> PHYSDEVOP_pci_mmcfg_reserved alters global state. >> --- >> v3: Add command line (sub-)option. >> v2: Major re-work to also check upon PHYSDEVOP_pci_mmcfg_reserved >> invocation. >> >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -2009,12 +2009,21 @@ Only effective if CONFIG_PARTIAL_EMULATI >> behavior.** >> >> ### pci >> - = List of [ serr=<bool>, perr=<bool> ] >> + = List of [ serr=<bool>, perr=<bool>, quirks=<bool> ] >> + >> +* `serr` and `perr` >> >> Default: Signaling left as set by firmware. >> >> -Override the firmware settings, and explicitly enable or disable the >> -signalling of PCI System and Parity errors. >> + Override the firmware settings, and explicitly enable or disable the >> + signalling of PCI System and Parity errors. >> + >> +* `quirks` >> + >> + Default: `on` >> + >> + In its negative form, allows to suppress certain quirk workarounds, in >> case >> + they cause issues. > > Not that I oppose to this, but I've assumed that you would introduce > an option to fallback to the previous behavior where Xen would just > assume extended space to be accessible.
But that would be wrong. It didn't even occur to me that you could have wanted that. Jan
