Re: [PATCH] vfio/pci: print vfio-device name to fdinfo

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Jun 24, 2025 at 10:23:03AM -0600, Alex Williamson wrote:

> I think we're specifically trying to gain visibility to the
> anon_inode:[vfio-device] in the legacy case.

Ah, I see.. 

> The @name passed to anon_inode_getfile_fmode() is described as the name
> of the "class", which is why I think we used the static
> "[vfio-device]", but I see KVM breaks the mold, adding the vcpu_id:
> 
> 	snprintf(name, sizeof(name), "kvm-vcpu-stats:%d", vcpu->vcpu_id);
> 
> We could do something similar, but maybe fdinfo is the better option,
> and if it is then dev_name() seems like the useful thing to add there
> (though we could add more than one thing).

I wouldn't encode a sysfspath (which is what you really need for a
device name) in the [] section.. fdinfo makes sense for that, but I
would return the full sysfs path to the device from the core code
rather than try to return just the BDF for PCI.

Prefix /sys/ and then userspace can inspect the directory for whatever
information it needs.

It could also return a %d within the [] that indicated which group it
was for. In most system that will tell you the device anyhow since
groups are singular.

> I don't recall if or how we accounted for the concept of vf_tokens in
> the cdev model and I don't see evidence that we did.  For instance
> vfio_pci_validate_vf_token() is only called from vfio_pci_core_match(),
> which is called as match through the vfio_device_ops, but only from
> vfio_group_ioctl_get_device_fd().  So using cdev, it appears we don't
> have the same opt-in requirement when using a VF where the PF is
> managed by a vfio-pci userspace driver.  Thanks,

Hmm.. I can't recall.

I wrote a small patch to correct this, I will post it.

Jason