Re: [PATCH v5 1/2] PCI: Fix isolated PCI function probing with ARI and SR-IOV

[Niklas Schnelle <schnelle@linux.ibm.com>]

On Mon, 2025-12-01 at 22:45 +0800, Huacai Chen wrote:
> 
--- snip ---
> You said that "it feels like this is just a hack to probe an odd
> topology". Yes, to some extent you are right.
> 
> 1, One of our SoC (LS2K3000) has a special device which has func1 but
> without func0. To let the PCI core scan func1 we can only make
> hypervisor_isolated_pci_functions() return true.
> 2, In the above case, PCI_SCAN_ALL_PCIE_DEVS has no help.
> 3, Though we change hypervisor_isolated_pci_functions() to resolve the
> above problem, it also lets us pass isolated PCI functions to a guest
> OS instance.
> 
> As a summary, for real machines commit a02fd05661d73a850 is a hack to
> probe an odd device, for virtual machines it allows passing isolated
> PCI functions.

Ok, thanks for the answer. So let's see how we can debug this and get
to a solution that works for both of us. Looking around a bit I see
that your pci_loongson_map_bus() has some special handling for trying
not to access non-existent devices added by your commit 2410e3301fcc
("PCI: loongson: Don't access non-existent devices"). I wonder if with
this patch applied we're running into this same issue but with a devfn
that was previously not tried and is not covered by your checks? And
maybe since your root complex doesn't return 0xff for these non-
existent devices we could end up trying to probe AHCI on such an empty
slot misinterpreting whatever it returns as matching device/vendor?

And looking at pdev_may_exist() does the "device <= 20" really make
sense with 20 in decimal? If I pull in the negation I get "device > 19"
But if it was 0x20 I'd get "device > 0x1f" which would match the
maximum value of PCI_SLOT(), though then the check would be redundant
since the device value already comes out of PCI_SLOT().

Could you try redoing the test with the AHCI hang but add a print of
the affected bus/device/function that AHCI thinks it is probing? Then
if the above theory applies we should see it trying to probe on a
device that is missing in the correctly booted case and got past your
existing checks.

Thanks,
Niklas Schnelle