On 1/26/26 03:58, Jan Beulich wrote: > 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)? Ah, I see. Thanks for the additional context.
First of all, to re-answer the original question, it still feels more of a nice-to-have optimization than a necessity since we don't have hyperlaunch PCI passthrough upstream yet. Of course, skipping re-evaluating ext_cfg would be a welcome change if you're up for it. An alternative approach might be to implement pci_check_extcfg() such that it only modifies ->ext_cfg if it needs to be changed, but again, I don't have an issue with it as is. With that said, what do you think if we took the stance that ->ext_cfg shouldn't be re-evaluated for a pdev while it's assigned to a domU with vPCI? I.e. we would return an error from the pci_mmcfg_reserved hypercall in this case. If I understand things correctly, conceptually speaking, from a system perspective, setting up mcfg is something that *should* be done at boot, not ad-hoc during runtime. In the hyperlaunch model that I'm envisioning, there will also be hardware/control domain separation, and we will want to limit the hardware domain's ability to interfere with other domains. So I'd consider disabling the mmcfg_reserved hypercall anyway in such a configuration. The assumption with this model is that we would not need rely on dom0 to enable mcfg the system/platform of choice. Longer term, if we really think we need to support hyperlaunch while relying on a dom0 to initialize mcfg, we could potentially delay assigning pdevs to hyperlaunch domUs until ->ext_cfg has been initialized and is not expected to change. This would imply implementing hotplug for PVH domUs (also needed for "xl pci-attach" with PVH domUs). I wrote some patches in an internal branch to expose an emulated bridge with pcie hotplug capability, laying some of the groundwork to support this, and I'll plan to eventually send this work upstream. In the scenario without a dom0, I don't have a good answer at the moment for how Xen would learn that mcfg could be used.
