On Wed, 17 Apr 2024 09:20:51 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Wed, Apr 17, 2024 at 07:16:05AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Wednesday, April 17, 2024 1:50 AM > > > > > > 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? > > > > > > > sure but we at least need to reach consensus on a minimal required > > uapi covering both PF/VF to move forward so the user doesn't need > > to touch different contracts for PF vs. VF. > > Do we? The situation where the VMM needs to wholly make a up a PASID > capability seems completely new and seperate from just using an > existing PASID capability as in the PF case. But we don't actually expose the PASID capability on the PF and as argued in path 4/ we can't because it would break existing userspace. > If it needs to make another system call or otherwise to do that then > that seems fine to do incrementally?? With PASID currently hidden, VF and PF support really seem too similar not to handle them both at the same time. What's missing is a mechanism to describe unused config space where userspace can implement an emulated PASID capability. Defining a DVSEC capability to handle this seemed to be the preferred solution from the LPC discussion. PF and VF devices that implement a TBD DVSEC capability could avoid needing a variant driver. Until then we need to be careful not to undermine a future world with that preferred solution by introducing side-band mechanisms which only work for variant drivers and PF devices. Thanks, Alex
