On 23.01.2026 23:24, Stewart Hildebrand wrote: > On 1/19/26 09:46, 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. >> >> Signed-off-by: Jan Beulich <[email protected]> > > Reviewed-by: Stewart Hildebrand <[email protected]>
Thanks, but see below (as that may change your take on it). >> --- >> Should we skip re-evaluation when pci_mmcfg_arch_enable() takes its early >> exit path? > > I don't have a strong opinion here, though I'm leaning toward it's OK as is. Maybe I need to add more context here. Not short-circuiting means that for a brief moment ->ext_cfg for a device can be wrong - between pci_check_extcfg() clearing it and then setting it again once all checks have passed. As long as only Dom0 is executing at that time, and assuming Dom0 actually issues the notification ahead of itself playing with individual devices covered by it, all is going to be fine. With hyperlaunch, however, DomU-s can't be told "not to fiddle" with devices they've been assigned. With the yet-to-be-written vPCI counterpart changes the window is actually going to get bigger for DomU-s using vPCI. For hyperlaunch this is going to be interesting anyway, on systems like the one you mentioned. First, without Dom0 / hwdom, how would we even learn we can use MCFG? And even with hwdom, how would we keep DomU-s from accessing the devices they were passed until ->ext_cfg has obtained its final state for them (and vPCI reached proper state, too)? >> 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? > > If I'm reading Linux drivers/xen/pci.c correctly, my understanding is that > dom0 > will only invoke PHYSDEVOP_pci_mmcfg_reserved once per mmcfg segment, so in > practice it's unlikely to spam. In other words, I think it's OK as is. Yes, it ought to be no more than twice, but that's still one time more than strictly needed. Hence my (mild) concern. >> 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. > > Agreed. The current patch is prerequisite for this work. Hm, perhaps we could > create a gitlab ticket for it? Personally I'm not a fan of gitlab tickets, and just in case no-one else gets to it I have this on my todo list already anyway. Jan
