From: Yi Liu <yi.l.liu@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"jgg@nvidia.com" <jgg@nvidia.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>
Cc: "cohuck@redhat.com" <cohuck@redhat.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
"peterx@redhat.com" <peterx@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"lulu@redhat.com" <lulu@redhat.com>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
"joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
"Zeng, Xin" <xin.zeng@intel.com>,
"Zhao, Yan Y" <yan.y.zhao@intel.com>
Subject: Re: [PATCH 3/3] vfio: Report PASID capability via VFIO_DEVICE_FEATURE ioctl
Date: Mon, 11 Dec 2023 16:08:11 +0800 [thread overview]
Message-ID: <0bdae2ca-a200-4db1-a016-059730d1545e@intel.com> (raw)
In-Reply-To: <BN9PR11MB527639DBE4C433542F351F6D8C8BA@BN9PR11MB5276.namprd11.prod.outlook.com>
On 2023/12/7 16:47, Tian, Kevin wrote:
>> From: Liu, Yi L <yi.l.liu@intel.com>
>> Sent: Monday, November 27, 2023 2:39 PM
>>
>> +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 */
>
> this line alone is meaningless. Please explain the reason e.g. due to
> no PASID capability per VF...
sure. I think the major reason is we don't allow userspace to change the
PASID configuration. is it?
>
>> + 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.
>> + */
>
> /* VF shares the PASID capability of its PF */
got it.
>> + if (pdev->is_virtfn)
>> + pdev = pci_physfn(pdev);
>> +
>> + if (!pdev->pasid_enabled)
>> + goto out;
>> +
>> +#ifdef CONFIG_PCI_PASID
>> + pci_read_config_dword(pdev, pdev->pasid_cap + PCI_PASID_CAP,
>> + &capabilities);
>> +#endif
>
> #ifdef is unnecessary. If CONFIG_PCI_PASID is false pdev->pasid_enabled
> won't be set anyway.
it's sad that the pdev->pasid_cap is defined under #if CONFIG_PCI_PASID.
Perhaps we can have a wrapper for it.
> and it should read from PCI_PASID_CTRL which indicates whether a
> capability is actually enabled.
yes, for the EXEC and PRIV capability, needs to check if it's enabled or
not before reporting.
>
>> +/**
>> + * Upon VFIO_DEVICE_FEATURE_GET, return the PASID capability for the
>> device.
>> + * Zero width means no support for PASID.
>
> also mention the encoding of this field according to PCIe spec.
yes.
> or turn it to a plain number field.
It is not exact the same as the spec since bit0 is reserved. But
here bit0 is used as well.
>> + */
>> +struct vfio_device_feature_pasid {
>> + __u16 capabilities;
>> +#define VFIO_DEVICE_PASID_CAP_EXEC (1 << 0)
>> +#define VFIO_DEVICE_PASID_CAP_PRIV (1 << 1)
>> + __u8 width;
>> + __u8 __reserved;
>> +};
>> +#define VFIO_DEVICE_FEATURE_PASID 11
>> +
>> /* -------- API for Type1 VFIO IOMMU -------- */
>>
>> /**
>> --
>> 2.34.1
>
--
Regards,
Yi Liu
next prev parent reply other threads:[~2023-12-11 8:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 6:39 [PATCH 0/3] vfio-pci support pasid attach/detach Yi Liu
2023-11-27 6:39 ` [PATCH 1/3] vfio-iommufd: Support pasid [at|de]tach for physical VFIO devices Yi Liu
2024-01-15 17:18 ` Jason Gunthorpe
2023-11-27 6:39 ` [PATCH 2/3] vfio: Add VFIO_DEVICE_PASID_[AT|DE]TACH_IOMMUFD_PT Yi Liu
2023-11-27 6:50 ` Duan, Zhenzhong
2023-11-28 3:06 ` Yi Liu
2023-12-11 17:05 ` Alex Williamson
2023-12-12 3:02 ` Yi Liu
2023-11-27 6:39 ` [PATCH 3/3] vfio: Report PASID capability via VFIO_DEVICE_FEATURE ioctl Yi Liu
2023-11-27 7:28 ` Duan, Zhenzhong
2023-11-28 3:11 ` Yi Liu
2023-11-28 4:23 ` Duan, Zhenzhong
2023-12-07 8:47 ` Tian, Kevin
2023-12-11 8:08 ` Yi Liu [this message]
2023-12-12 2:20 ` Tian, Kevin
2023-12-12 3:26 ` Yi Liu
2023-12-12 15:31 ` Jason Gunthorpe
2023-12-13 1:59 ` Tian, Kevin
2023-12-11 18:03 ` Alex Williamson
2023-12-11 18:10 ` Jason Gunthorpe
2023-12-11 18:49 ` Alex Williamson
2023-12-12 15:35 ` Jason Gunthorpe
2023-12-13 2:10 ` Tian, Kevin
2024-01-15 9:49 ` Yi Liu
2023-12-12 2:16 ` Tian, Kevin
2023-12-12 3:44 ` Yi Liu
2023-12-12 2:43 ` Duan, Zhenzhong
2023-12-12 3:39 ` Alex Williamson
2023-12-12 3:53 ` Yi Liu
2023-12-12 15:27 ` Jason Gunthorpe
2024-01-15 8:20 ` Yi Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0bdae2ca-a200-4db1-a016-059730d1545e@intel.com \
--to=yi.l.liu@intel.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=chao.p.peng@linux.intel.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lulu@redhat.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=peterx@redhat.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=xin.zeng@intel.com \
--cc=yan.y.zhao@intel.com \
--cc=yi.y.sun@linux.intel.com \
--cc=zhenzhong.duan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.