On 29.01.2026 16:32, Roger Pau Monné wrote: > On Thu, Jan 29, 2026 at 02:10:01PM +0100, Jan Beulich wrote: >> When, during boot, we have already correctly determined availability of >> the MMCFG access method for a given bus range, there's then no need to >> invoke pci_check_extcfg() again for every of the devices. This in >> particular avoids ->ext_cfg to transiently indicate the wrong state. >> >> Switch to using Xen style on lines being touched and immediately adjacent >> ones. >> >> Signed-off-by: Jan Beulich <[email protected]> > > Acked-by: Roger Pau Monné <[email protected]>
Thanks. > One suggestion for a further addition below. > >> --- >> v3: New. >> >> --- a/xen/arch/x86/physdev.c >> +++ b/xen/arch/x86/physdev.c >> @@ -528,6 +528,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H >> if ( !ret ) >> ret = pci_segment_iterate(info.segment, >> physdev_check_pci_extcfg, >> &info); >> + else if ( ret > 0 ) /* Indication of "no change". */ >> + ret = 0; >> >> if ( !ret && has_vpci(currd) && (info.flags & >> XEN_PCI_MMCFG_RESERVED) ) > > Maybe it doesn't need to be strictly done here, but now that > pci_mmcfg_reserved() signals whether the MMCFG was already registered, > could you also restrict the register_vpci_mmcfg_handler() call to ret > == 0? Possibly; you know vPCI better than I do. > That will also simplify the logic in register_vpci_mmcfg_handler() > since we no longer need to return 0 when the region is already > registered, returning -EEXIST should be fine if the caller is > adjusted. I think this then will want to be a separate change, with its own justification. Jan
