> From: Jason Gunthorpe <[email protected]>
> 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?
> 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.
> @@ -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.
what about adding a check of it with .sriov_configure() in
vfio_pci_core_register_device() to save changes in every driver?
