> From: Alex Williamson <alex.williamson@xxxxxxxxxx>
> Sent: Wednesday, April 17, 2024 1:57 AM
>
> On Fri, 12 Apr 2024 01:21:21 -0700
> Yi Liu <yi.l.liu@xxxxxxxxx> wrote:
>
> > + */
> > +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;
> > +};
>
> Building on Kevin's comment on the cover letter, if we could describe
> an offset for emulating a PASID capability, this seems like the place
> we'd do it. I think we're not doing that because we'd like an in-band
> mechanism for a device to report unused config space, such as a DVSEC
> capability, so that it can be implemented on a physical device. As
> noted in the commit log here, we'd also prefer not to bloat the kernel
> with more device quirks.
>
> In an ideal world we might be able to jump start support of that DVSEC
> option by emulating the DVSEC capability on top of the PASID capability
> for PFs, but unfortunately the PASID capability is 8 bytes while the
> DVSEC capability is at least 12 bytes, so we can't implement that
> generically either.
Yeah, that's a problem.
>
> I don't know there's any good solution here or whether there's actually
> any value to the PASID capability on a PF, but do we need to consider
> leaving a field+flag here to describe the offset for that scenario?
Yes, I prefer to this way.
> Would we then allow variant drivers to take advantage of it? Does this
> then turn into the quirk that we're trying to avoid in the kernel
> rather than userspace and is that a problem? Thanks,
>
We don't want to proactively pursue quirks in the kernel.
But if a variant driver exists for other reasons, I don't see why it
should be prohibited from deciding an offset to ease the
userspace. 😊
