> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > Sent: Wednesday, August 14, 2024 2:39 PM > > On 2024/8/6 22:20, Jason Gunthorpe wrote: > > On Mon, Aug 05, 2024 at 05:35:17AM +0000, Tian, Kevin wrote: > > > >> Okay. With that I edited my earlier reply a bit by removing the note > >> of cmdline option, adding DVSEC possibility, and making it clear that > >> the PASID option is in vIOMMU: > >> > >> " > >> Overall this sounds a feasible path to move forward - starting with > >> the VMM to find the gap automatically if PASID is opted in vIOMMU. > >> Devices with hidden registers may fail. Devices with volatile > >> config space due to FW upgrade or cross vendors may fail to migrate. > >> Then evolving it to the file-based scheme, and there is time to discuss > >> any intermediate improvement (fixed quirks, DVSEC, etc.) in between. > >> " > >> > >> Jason, your thoughts? > > > > This thread is big and I've read it quickly, but I could support the > > above summary. > > > > thanks for the ideas. I think we still need a uapi to report if the device > supports PASID or not. Do we have agreement on where should this uapi be > defined? vfio or iommufd. IOMMUFD_CMD_GET_HW_INFO. > > Besides, I've a question on how the userspace know the hidden registers > when trying to find a gap for the vPASID cap. It should only know the > standard pci caps. > for the initial implementation VMM doesn't know any hidden registers. The user passes a new vIOMMU option to the VMM for exposing the PASID capability in vIOMMU and in device, based on info in IOMMUFD_CMD_GET_HW_INFO. The VMM identifies a hole between existing caps to put the vPASID cap. If a device with hidden registers doesn’t work correctly then then a quirk may be added for it.
