Page MenuHomeFreeBSD

linuxkpi: handle ARI
ClosedPublic

Authored by kib on Jan 4 2021, 9:35 PM.

Details

Summary

Stop trying to manually calculate RID, which cannot be done correctly by PCI_DEVFN(). Use PCI_GET_RID() method instead.

Do not use pci_find_dbsf() to go from the linux pci_dev to freebsd device_t. First, device is readily available as dev.bsddev. Second, using pci_find_dbsf() fails for ARI-enabled functions with large function numbers, because PCI_SLOT()/PCI_FUNC() are for non-ARI.

Sponsored by: Mellanox Technologies/NVidia Networking

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kib requested review of this revision.Jan 4 2021, 9:35 PM
sys/compat/linuxkpi/common/src/linux_pci.c
270

Why do we use the parent parent here ?

sys/compat/linuxkpi/common/src/linux_pci.c
270

PCI_GET_ID() requires the first arg to be bus, and ends up as the PCIB_GET_RID() call on the parent of the bus. Hans explained to me that in drm case, dev is some pseudo-device set to be child of the normally enumerated PCI device.

If this is correct, then parent-parent there just re-aligns the things to be same for drm and non-drm. I do not think it is enough to set ivars to have GET_RID() working.

Can you test drm with this patch, please ?

sys/compat/linuxkpi/common/src/linux_pci.c
270

That will resolve to the pciN device for drm and not pcibN I think.

pcib0
  pci0
    hostb0
    vgapci0
      drmn0

I'll test today and report the result.

sys/compat/linuxkpi/common/src/linux_pci.c
270

I expect that the call needs the pair pci0/vgapci0. Then pci_get_id_method() does PCIB_GET_ID(device_get_parent(pci0) == pcib0, vgapci0).

But again, this is all from the code reading. Testing and some iterations to make it work will be much appreciated.

@kib We have a special flag for the DRM case. See pdrv->isdrm .

@kib We have a special flag for the DRM case. See pdrv->isdrm .

That's what is used here.

This revision is now accepted and ready to land.Jan 6 2021, 2:30 PM
bz added a subscriber: bz.

Looks ok to me; I don't particularly like the special cases but it seems fine.

In D27960#625635, @bz wrote:

Looks ok to me; I don't particularly like the special cases but it seems fine.

Note that the case was already there. I just handled it in my change.

This revision was automatically updated to reflect the committed changes.