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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAAhV-H6GE3q4qaPo9OvNkYOzatR-8BMYeGQ8hdmvKVZXbQF2rw@mail.gmail.com>
Date: Wed, 17 Dec 2025 14:55:36 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Niklas Schnelle <schnelle@...ux.ibm.com>
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 Thu, Dec 4, 2025 at 5:45 AM Niklas Schnelle <schnelle@...ux.ibm.com> wrote:
>
> 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?
Commit 2410e3301fcc seems to have no relationship with current problems.

The LS2K3000 problem that commit a02fd05661d73 want to resolve is we
have such a device:
bus=0, device=6,  fun=0,  GPU
bus=0, device=6,  fun=1,  DC
The GPU part can be disabled and in which case there is a device
without func0, so need a hack.

>
> 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().
I have confirmed that 20 in decimal is right. Devices between dev-20
and dev-0x20 are completely sane.

>
> 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.
By redoing this test we found there is only one AHCI detected, and the
BDF is: bus=0, device=8, fun=0.

With or without this patch, only one AHCI. But without this patch, the
AHCI initialization doesn't hang.

Huacai

>
> Thanks,
> Niklas Schnelle