Potential issue with hypervisor_isolated_pci_functions() handling

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

Hi Huacai, Hi Jan, Hi Bjorn,

I noticed that with commit a02fd05661d7 ("PCI: Extend isolated function
probing to LoongArch") LoongArch now also makes use of the isolated
function probing. First, nice to see this sees more users and that the
interface is useful to you. 

Seeing this, I was reminded of an issue I ran into when using this
mechanism with SR-IOV capable devices. In that case VFs with devfn > 7
and PCI_SLOT(devfn) != 0 wouldn't get probed.
This is because if a device is found next_fn() will check whether dev-
>multifunction is set. So if for example devfn == 8 is found (fn == 0)
dev->multifunction won't be set in pci_scan_slot() and for VFs it's
also not set via PCI_HEADER_TYPE_MFD. So we won't check for devfn == 9
even though that could very well be there.

Now for s390 this currently doesn't cause issues because for all
multifunction devices we have, we either get a VF alone and then since
commit 25f39d3dcb48 ("s390/pci: Ignore RID for isolated VFs") use devfn
== 0, or we have the parent PF passed-through and then VFs always get
hot plugged after SR-IOV enable, which then uses
pci_scan_single_device(). And for non VFs we always have devfn == 0
and/or devfn == 1 and multifunction via the header. So in a sense the
above commit works around the issue, though that wasn't its primary
intention.

Did either of you also run into this issue or can reproduce it?

Somewhat related, if ARI is enabled this would also break the isolated
function case including on s390 where ARI is used by the platform
firmware, but detected as off by Linux because there is no struct
pci_dev associated with the PCI bus. If I patch Linux to correctly
detect ARI, it no longer finds an isolated PF with devfn == 1.

Thanks,
Niklas Schnelle