Re: [PATCH v3 for-4.21 4/4] PCI: drop pci_segments_init()

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Feb 10, 2025 at 11:01:04AM +0100, Jan Beulich wrote:
> On 06.02.2025 16:08, Roger Pau Monné wrote:
> > On Tue, Feb 04, 2025 at 02:04:35PM +0100, Jan Beulich wrote:
> >> Have callers invoke pci_add_segment() directly instead: With radix tree
> >> initialization moved out of the function, its name isn't quite
> >> describing anymore what it actually does.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > 
> > IMO I would rather not add the segment here, and just make sure that
> > all callers that add segments have proper error reporting when it
> > fails.
> 
> Maybe. Yet then things may (on x86) work fine with secondary segments not
> properly working. A log from one of the few multi-segment systems that I
> had seen data from suggested that none of the devices on the secondary
> segment were actually used by anything. This was, if I'm not mistaken,
> the underlying reason why (on x86) we demand segment 0 to have proper
> representation, but do things best effort only for other segments. Which
> isn't to say that we can't change things and do better.
> 
> >  Maybe alloc_pseg() should gain a printk on failure?
> 
> Not sure that would buy us much, especially if (on x86) it's seg 0 which
> is affected.
> 
> For the patch at hand - do you then suggest to simply drop it? The plan
> here wasn't to re-work what we do, just tidy slightly how we do things.

I feel like acpi_mmcfg_init() is an obscure place to do this.  It
won't be strange to shuffle that call around and forgot it's also
adding segment 0.

I would prefer if such allocation of segment 0 was done in
__start_xen(), as that makes it much easier to identify dependencies
and prevent such kind of re-ordering mistakes.

Thanks, Roger.