On 13.01.2026 11:46, Jan Beulich wrote: > On 12.01.2026 22:07, Stewart Hildebrand wrote: >> On 1/6/26 08:47, Jan Beulich wrote: >>> @@ -420,6 +467,19 @@ static struct pci_dev *alloc_pdev(struct >>> break; >>> } >>> >>> + if ( pdev->ext_cfg && >>> + /* >>> + * Regular PCI devices have 256 bytes, but PCI-X 2 and PCI Express >>> + * devices have 4096 bytes. Even if the device is capable, that >>> + * doesn't mean we can access it. Maybe we don't have a way to >>> + * generate extended config space accesses, or the device is >>> behind a >>> + * reverse Express bridge. So we try reading the dword at >>> + * PCI_CFG_SPACE_SIZE which must either be 0 or a valid extended >>> + * capability header. >>> + */ >>> + pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) == 0xffffffffU ) >>> + pdev->ext_cfg = false; >> >> I'm using a machine where >> xen/arch/x86/x86_64/mmconfig-shared.c:is_mmconf_reserved() will initially >> return >> false during Xen boot: >> >> (XEN) PCI: MCFG configuration 0: base f0000000 segment 0000 buses 00 - 3f >> (XEN) PCI: Not using MCFG for segment 0000 bus 00-3f >> >> Then, during dom0 boot, dom0 will call PHYSDEVOP_pci_mmcfg_reserved, after >> which >> MCFG becomes enabled in Xen: >> >> (XEN) PCI: Using MCFG for segment 0000 bus 00-3f >> >> On such machines where mmcfg/ECAM is initially disabled, this will >> effectively >> set ->ext_cfg to false for all devices discovered at Xen boot. >> >> I'm not really sure if I have any good suggestions, but perhaps we could add >> a >> macro or small function that returns something like >> ( pdev->ext_cfg && pci_conf_read32(pdev->sbdf, PCI_CFG_SPACE_SIZE) != >> 0xffffffffU ) >> to allow this checking to happen dynamically (but this still wouldn't handle >> the >> aliasing quirk). Maybe re-run the ext_cfg detection logic at the end of >> PHYSDEVOP_pci_mmcfg_reserved? >> >> Regardless, I'd be happy to provide my R-b without this addressed, but I am >> curious if others think this as an issue? > > Hmm, no, I forgot to consider that case (which in principle I'm well aware > of). > Will need to fix in v2.
That'll be a little interesting, since per Dom0's request we may also lose MCFG access to a range of busses. Looks like we indeed need to fully re- evaluate ->ext_cfg. Jan
