On 27.01.2026 05:13, Stewart Hildebrand wrote: > 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.
My fear here is that an aspect like this one may easily be forgotten when later doing the actual hyperlaunch work, or when finally making PCI properly supported on Arm64 (where then dom0less would be equally affected, unless Arm has found a way to avoid the dependency on Dom0's ACPI AML parsing). > Of course, skipping re-evaluating ext_cfg would be a > welcome change if you're up for it. We can surely keep this as an incremental change to be made. I guess I want to give Roger a chance to comment before deciding whether to commit the patch here as-is. > 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. That wouldn't help much imo, as there's then still a time window where what the field says is wrong relative to what we already have accounted for in our MCFG handling. > 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. I don't like this idea, as it's functionally limiting (if MCFG becomes available only later) or functionally wrong (if, for whatever reason, MCFG becomes unavailable later). In no event would I consider returning an error from that hypercall. If anything I'd see us ignore it. > 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. Yes, and that concept simply collides with hyperlaunch's plan to launch more than just Dom0 right at boot. Dom0 booting is part of the system booting, after all. > 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. But you need to work with the hardware you've got. For customized systems it certainly is an option to arrange for firmware to suitably report what Xen needs to be independent of Dom0. But for general purpose systems this won't necessarily fly. > 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. Which isn't quite what I understand one of hyperlaunch's goals is (to have all domains be statically configured, and hence be in final, usable shape right when their booting completes). Jan
