public inbox for virtualization@lists.linux-foundation.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox