On 03.02.2025 15:23, Andrew Cooper wrote:
> 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.
Well, let me submit v2 then with all those new patches.
Jan
