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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ba63ea826472b4f2d2a318784b710ee91fdca202.camel@linux.ibm.com>
Date: Wed, 03 Dec 2025 22:45:04 +0100
From: Niklas Schnelle <schnelle@...ux.ibm.com>
To: Huacai Chen <chenhuacai@...nel.org>
Cc: Tianrui Zhao <zhaotianrui@...ngson.cn>, Bibo Mao <maobibo@...ngson.cn>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        linux-s390	 <linux-s390@...r.kernel.org>, loongarch@...ts.linux.dev,
        Farhan
 Ali	 <alifm@...ux.ibm.com>,
        Matthew Rosato <mjrosato@...ux.ibm.com>,
        Gerald
 Schaefer	 <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens
 <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev
 <agordeev@...ux.ibm.com>,
        Sven Schnelle	 <svens@...ux.ibm.com>,
        Christian
 Borntraeger <borntraeger@...ux.ibm.com>,
        Gerd Bayer
 <gbayer@...ux.ibm.com>, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org
Subject: Re: [PATCH v5 1/2] PCI: Fix isolated PCI function probing with ARI
 and SR-IOV

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