-----Original Message----- From: Liu, Yi L yi.l.liu@intel.com Sent: Tuesday, November 28, 2023 11:12 AM Subject: Re: [PATCH 3/3] vfio: Report PASID capability via VFIO_DEVICE_FEATURE ioctl
On 2023/11/27 15:28, Duan, Zhenzhong wrote:
-----Original Message----- From: Liu, Yi L yi.l.liu@intel.com Sent: Monday, November 27, 2023 2:39 PM Subject: [PATCH 3/3] vfio: Report PASID capability via VFIO_DEVICE_FEATURE ioctl
This reports the PASID capability data to userspace via VFIO_DEVICE_FEATURE, hence userspace could probe PASID capability by it. This is a bit different with other capabilities which are reported to userspace when the user reads the device's PCI configuration space. There are two reasons for this.
First, Qemu by default exposes all available PCI capabilities in vfio-pci config space to the guest as read-only, so adding PASID capability in the vfio-pci config space will make it exposed to the guest automatically while an old Qemu doesn't really support it.
Second, PASID capability does not exit on VFs (instead shares the cap of the PF). Creating a virtual PASID capability in vfio-pci config space needs to find a hole to place it, but doing so may require device specific knowledge to avoid potential conflict with device specific registers like hiden bits in VF config space. It's simpler by moving this burden to the VMM instead of maintaining a quirk system in the kernel.
Suggested-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Yi Liu yi.l.liu@intel.com
drivers/vfio/pci/vfio_pci_core.c | 47 ++++++++++++++++++++++++++++++++ include/uapi/linux/vfio.h | 13 +++++++++ 2 files changed, 60 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c index 1929103ee59a..8038aa45500e 100644 --- a/drivers/vfio/pci/vfio_pci_core.c +++ b/drivers/vfio/pci/vfio_pci_core.c @@ -1495,6 +1495,51 @@ static int vfio_pci_core_feature_token(struct vfio_device *device, u32 flags, return 0; }
+static int vfio_pci_core_feature_pasid(struct vfio_device *device, u32 flags,
struct vfio_device_feature_pasid __user*arg,
size_t argsz)+{
- struct vfio_pci_core_device *vdev =
container_of(device, struct vfio_pci_core_device, vdev);- struct vfio_device_feature_pasid pasid = { 0 };
- struct pci_dev *pdev = vdev->pdev;
- u32 capabilities = 0;
- int ret;
- /* We do not support SET of the PASID capability */
- ret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET,
sizeof(pasid));- if (ret != 1)
return ret;- /*
* Needs go to PF if the device is VF as VF shares its PF's* PASID Capability.*/- if (pdev->is_virtfn)
pdev = pci_physfn(pdev);- if (!pdev->pasid_enabled)
goto out;Does a PF bound to VFIO have pasid enabled by default?
Today, host iommu driver (at least intel iommu driver) enables it in the time of device probe and seems not changed afterward. So yes, VFIO should see it if pasid is enabled.
Isn't the guest kernel's responsibility to enable pasid cap of an assigned PF?
guest kernel should not have the capability to change host's pasid configuration. It can only write to its own vconfig emulated by hypervisor.
Understood, thanks Yi.
BRs. Zhenzhong