On Tue, Apr 16, 2024 at 08:38:50AM +0000, Tian, Kevin wrote: > > From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > > Sent: Friday, April 12, 2024 4:21 PM > > > > A userspace VMM is supposed to get the details of the device's PASID > > capability > > and assemble a virtual PASID capability in a proper offset in the virtual PCI > > configuration space. While it is still an open on how to get the available > > offsets. Devices may have hidden bits that are not in the PCI cap chain. For > > now, there are two options to get the available offsets.[2] > > > > - Report the available offsets via ioctl. This requires device-specific logic > > to provide available offsets. e.g., vfio-pci variant driver. Or may the device > > provide the available offset by DVSEC. > > - Store the available offsets in a static table in userspace VMM. VMM gets the > > empty offsets from this table. > > > > I'm not a fan of requesting a variant driver for every PASID-capable > VF just for the purpose of reporting a free range in the PCI config space. > > It's easier to do that quirk in userspace. > > But I like Alex's original comment that at least for PF there is no reason > to hide the offset. there could be a flag+field to communicate it. or > if there will be a new variant VF driver for other purposes e.g. migration > it can certainly fill the field too. Yes, since this has been such a sticking point can we get a clean series that just enables it for PF and then come with a solution for VF? Jason
