Re: [PATCH for-4.20 2/3] x86/PCI: init segments earlier

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 03/02/2025 1:03 pm, Jan Beulich wrote:
> On 03.02.2025 14:00, Jan Beulich wrote:
>> On 03.02.2025 13:45, Roger Pau Monné wrote:
>>> On Thu, Jan 30, 2025 at 12:12:31PM +0100, Jan Beulich wrote:
>>>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
>>>> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
>>>> @@ -402,8 +402,6 @@ void __init acpi_mmcfg_init(void)
>>>>  {
>>>>      bool valid = true;
>>>>  
>>>> -    pci_segments_init();
>>>> -
>>>>      /* MMCONFIG disabled */
>>>>      if ((pci_probe & PCI_PROBE_MMCONF) == 0)
>>>>          return;
>>>> --- a/xen/drivers/passthrough/x86/iommu.c
>>>> +++ b/xen/drivers/passthrough/x86/iommu.c
>>>> @@ -55,6 +55,8 @@ void __init acpi_iommu_init(void)
>>>>  {
>>>>      int ret = -ENODEV;
>>>>  
>>>> +    pci_segments_init();
>>> My preference might be to just place the pci_segments_init() call in
>>> __start_xen(),
>> As said in reply to Andrew - I was considering doing so as an alternative
>> to the moving done here. I can certainly do so, in case some non-negative
>> reply comes back from him.
> Oh, and: With further adjustments following from what Andrew had outlined,
> I'm actually moving the invocation of what was pci_segments_init() back to
> where it's now. (Which doesn't mean that couldn't be done from
> __start_xen(); just mentioning it.)

The name acpi_mmcfg_init() at least has a PCI implication, given mmcfg.

I know it's late in 4.20, and moving pci_segments_init() would be
acceptable at this juncture.

However, if you're making progress with improving radix trees, I think
that would be a better approach and probably fine to be considered at
this point.

~Andrew