Re: [PATCH v2 2/4] PCI: determine whether a device has extended config space

[Jan Beulich <jbeulich@xxxxxxxx>]

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 <jbeulich@xxxxxxxx>
> 
> Reviewed-by: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>

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