On Tue, Oct 31, 2023 at 8:43 PM Sevincer, Abdullah <abdullah.sevin...@intel.com> wrote: > > > > +This patch can be splited as two, > > +1) Generic PCIe function to enable/disable PASID > > +2) Call generic function to disable PASID in drivers/event/dlb2/. Also > > mention which Linux kernel commit is introducing this issue in the git > > commit log. > > Hi Jerrin, > I think I need to provide more information here, then we can decide which way > we will go would be good for now. I agree to having 2 functions in pci common > code to enable/disable PASID, but we need to have hardcoded PASID cap offset > inside these functions as well since PASID capability is not exposed to user. > Hence, to be more specific > main reason to have hardcoded PASID is, rte_pci_find_ext_capability() > function to retrieve the offset returns '0' since PASID is not exposed to > user yet. > > We can see this is vfio_pci_config.c in kernel code where PASID is not > exposed to user. > [PCI_EXT_CAP_ID_PASID] = 0, /* not yet */ > > So if it is okay to go with hardcoded offset now in these functions I will > move the implementation to pci_common file.
I would suggest, add argument option to API whether to probe the capability or not? - 0 means probe and- non zero means specific PASID cap offset till Linux VFIO is exposing it.
