Hi Cédric, > -----Original Message----- > From: Cédric Le Goater <[email protected]> > Sent: 09 December 2025 10:11 > To: Shameer Kolothum <[email protected]>; qemu- > [email protected]; [email protected] > Cc: [email protected]; [email protected]; Jason Gunthorpe > <[email protected]>; Nicolin Chen <[email protected]>; > [email protected]; [email protected]; Nathan Chen > <[email protected]>; Matt Ochs <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > Krishnakant Jaju <[email protected]> > Subject: Re: [PATCH v5 31/32] vfio: Synthesize vPASID capability to VM > > External email: Use caution opening links or attachments > > > Hello Shameer, Yi, > > On 10/31/25 11:50, Shameer Kolothum wrote: > > From: Yi Liu <[email protected]> > > > > If user wants to expose PASID capability in vIOMMU, then VFIO would also > > report the PASID cap for this device if the underlying hardware supports > > it as well. > > > > As a start, this chooses to put the vPASID cap in the last 8 bytes of the > > vconfig space. This is a choice in the good hope of no conflict with any > > existing cap or hidden registers. For the devices that has hidden registers, > > user should figure out a proper offset for the vPASID cap. This may require > > an option for user to config it. Here we leave it as a future extension. > > There are more discussions on the mechanism of finding the proper offset. > > > > > https://lore.kernel.org/kvm/BN9PR11MB5276318969A212AD0649C7BE8CBE2 > @BN9PR11MB5276.namprd11.prod.outlook.com/ > > > > Since we add a check to ensure the vIOMMU supports PASID, only devices > > under those vIOMMUs can synthesize the vPASID capability. This gives > > users control over which devices expose vPASID. > > > > Signed-off-by: Yi Liu <[email protected]> > > Tested-by: Zhangfei Gao <[email protected]> > > Signed-off-by: Shameer Kolothum <[email protected]> > > --- > > hw/vfio/pci.c | 37 +++++++++++++++++++++++++++++++++++++ > > include/hw/iommu.h | 1 + > > 2 files changed, 38 insertions(+) > > > > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c > > index 06b06afc2b..2054eac897 100644 > > --- a/hw/vfio/pci.c > > +++ b/hw/vfio/pci.c > > @@ -24,6 +24,7 @@ > > #include <sys/ioctl.h> > > > > #include "hw/hw.h" > > +#include "hw/iommu.h" > > #include "hw/pci/msi.h" > > #include "hw/pci/msix.h" > > #include "hw/pci/pci_bridge.h" > > @@ -2500,7 +2501,12 @@ static int vfio_setup_rebar_ecap(VFIOPCIDevice > *vdev, uint16_t pos) > > > > static void vfio_add_ext_cap(VFIOPCIDevice *vdev) > > { > > + HostIOMMUDevice *hiod = vdev->vbasedev.hiod; > > + HostIOMMUDeviceClass *hiodc = > HOST_IOMMU_DEVICE_GET_CLASS(hiod); > > PCIDevice *pdev = PCI_DEVICE(vdev); > > + uint64_t max_pasid_log2 = 0; > > + bool pasid_cap_added = false; > > + uint64_t hw_caps; > > uint32_t header; > > uint16_t cap_id, next, size; > > uint8_t cap_ver; > > @@ -2578,12 +2584,43 @@ static void vfio_add_ext_cap(VFIOPCIDevice > *vdev) > > pcie_add_capability(pdev, cap_id, cap_ver, next, size); > > } > > break; > > + case PCI_EXT_CAP_ID_PASID: > > + pasid_cap_added = true; > > + /* fallthrough */ > > default: > > pcie_add_capability(pdev, cap_id, cap_ver, next, size); > > } > > > > } > > > > +#ifdef CONFIG_IOMMUFD > > The HostIOMMUDevice concept was introduced to abstract the use of > the Host IOMMU backends in VFIO (and other parts of QEMU): > > - the VFIO IOMMU type1 backend, also referred as 'legacy', > - IOMMUFD > > Adding code in VFIO under CONFIG_IOMMUFD should be avoided always > when possible. There are exceptions, such as for the definition > of the properties below in this file. This is, however, due to the > dual-bus nature of the VFIO devices and the limitation of QEMU class > inheritance. > Yes, I did see the CONFIG_IOMMUFD usage in this file, but was unaware of the reasons/constraints.
> In this case, I think we can extend HostIOMMUDevice and associated > class, to handle PASID support. Please rework this patch. I can > merge as a prereq change. I had a go at extending the HostIOMMUDeviceClass in v4 here, https://lore.kernel.org/qemu-devel/[email protected]/ Is something similar you have in mind here? > > Also, IOMMUFD backend is not supported on all platforms, so these > changes, even if correct, won't compile. Hmm..I am not sure I follow the compile failure case mentioned. Is the problem will be with HostIOMMUDevice above or within this #ifdef CONFIG_IOMMUFD block itself? Thanks, Shameer
