> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, April 23, 2024 8:40 PM > > On Fri, Apr 12, 2024 at 01:21:21AM -0700, Yi Liu wrote: > > Today, vfio-pci hides the PASID capability of devices from userspace. Unlike > > other PCI capabilities, PASID capability is going to be reported to user by > > VFIO_DEVICE_FEATURE. Hence userspace could probe PASID capability by > it. > > This is a bit different from the other capabilities which are reported to > > userspace when the user reads the device's PCI configuration space. There > > are two reasons for this. > > I'm thinking this probably does not belong in VFIO, iommufd should > report what the device, driver and OS is able to do with this > device. PASID support is at least 50% an iommu property too. We have PASID capability in both device side and iommu side. VFIO is for the former and iommufd is for the latter. both should report the capability only if that cap exists and is enabled by OS. > > This is a seperate issue to forming the config space. > > I didn't notice anything about SIOV in this, are we tackling it later? yes. > > IIRC we need the vIOMMU to specify a vPASID during attach and somehow > that gets mapped into a pPASID and synchronized with the KVM ENQCMD > translation? > yes, that is the original plan. More accurately the vfio attach uAPI is always about a pPASID. The mapping will be added separately to iommufd and synced with KVM. But internally we are evaluating whether there is enough value to justify adding this complexity to the kernel. It's the main burden in SIOVr1. Given the limited usages very likely we'll only do the basic SIOV support w/o the vPASID cap...
