From: Jason Gunthorpe <jgg@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Ankit Agrawal <ankita@nvidia.com>,
Brett Creeley <brett.creeley@amd.com>,
"Cabiddu, Giovanni" <giovanni.cabiddu@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Longfang Liu <liulongfang@huawei.com>,
qat-linux <qat-linux@intel.com>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
"Zeng, Xin" <xin.zeng@intel.com>,
Yishai Hadas <yishaih@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"patches@lists.linux.dev" <patches@lists.linux.dev>,
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
"Xu, Terrence" <terrence.xu@intel.com>,
"Jiang, Yanting" <yanting.jiang@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"Duan, Zhenzhong" <zhenzhong.duan@intel.com>
Subject: Re: [PATCH] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD
Date: Thu, 3 Jul 2025 10:41:02 -0300 [thread overview]
Message-ID: <20250703134102.GD1209783@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276CD6181F932C70CBC800E8C43A@BN9PR11MB5276.namprd11.prod.outlook.com>
On Thu, Jul 03, 2025 at 06:40:48AM +0000, Tian, Kevin wrote:
> > From: Jason Gunthorpe <jgg@nvidia.com>
> > Sent: Wednesday, June 25, 2025 2:35 AM
> >
> > This was missed during the initial implementation. The VFIO PCI encodes
> > the vf_token inside the device name when opening the device from the
> > group
> > FD, something like:
> >
> > "0000:04:10.0 vf_token=bd8d9d2b-5a5f-4f5a-a211-f591514ba1f3"
> >
> > This is used to control access to a VF unless there is co-ordination with
> > the owner of the PF.
> >
> > Since we no longer have a device name pass the token directly though
> > VFIO_DEVICE_BIND_IOMMUFD with an optional field indicated by
> > VFIO_DEVICE_BIND_TOKEN.
>
> not a complete sentence?
Since we no longer have a device name, pass the token directly through
VFIO_DEVICE_BIND_IOMMUFD using an optional field indicated by
VFIO_DEVICE_BIND_TOKEN.
> > Only users using a PCI SRIOV VF will need to
> > provide this. This is done in the usual backwards compatible way.
>
> and PF also needs to provide it when there are in-use VFs:
>
> vfio_pci_validate_vf_token():
> * When presented with a PF which has VFs in use, the user must also
> * provide the current VF token to prove collaboration with existing
> * VF users. If VFs are not in use, the VF token provided for the PF
> * device will act to set the VF token.
Too complicated, I'll just drop that sentence.
> > @@ -1583,6 +1583,7 @@ static const struct vfio_device_ops
> > hisi_acc_vfio_pci_ops = {
> > .mmap = vfio_pci_core_mmap,
> > .request = vfio_pci_core_request,
> > .match = vfio_pci_core_match,
> > + .match_token_uuid = vfio_pci_core_match_token_uuid,
>
> this matters only when the driver supports SR-IOV. currently only
> vfio-pci does.
Hmm, sriov_pf_core_dev requires sriov_config, but the normal vf_token
happens for all vfs and there is a little debugging related to it:
pci_info_ratelimited(vdev->pdev,
"VF token incorrectly provided, PF not bound to vfio-pci\n");
So maybe we want to keep it. Otherwise it sounds like you are
proposing to remove match from most of the drivers since they don't
support sriov_configure? Which ever direction I think match and
match_token_uuid should be together.
Jason
next prev parent reply other threads:[~2025-07-03 13:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 18:34 [PATCH] vfio/pci: Do vf_token checks for VFIO_DEVICE_BIND_IOMMUFD Jason Gunthorpe
2025-06-24 20:06 ` Alex Williamson
2025-07-02 14:56 ` Jason Gunthorpe
2025-07-03 6:40 ` Tian, Kevin
2025-07-03 13:41 ` Jason Gunthorpe [this message]
2025-07-10 8:29 ` Tian, Kevin
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=20250703134102.GD1209783@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=ankita@nvidia.com \
--cc=brett.creeley@amd.com \
--cc=giovanni.cabiddu@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=liulongfang@huawei.com \
--cc=mjrosato@linux.ibm.com \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=qat-linux@intel.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=terrence.xu@intel.com \
--cc=virtualization@lists.linux.dev \
--cc=xin.zeng@intel.com \
--cc=yanting.jiang@intel.com \
--cc=yi.l.liu@intel.com \
--cc=yishaih@nvidia.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.