> From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
> Sent: Wednesday, August 14, 2024 4:19 PM
>
> On 2024/8/14 15:38, Tian, Kevin wrote:
> >> 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.
>
> I see. TBH. The existing GET_HW_INFO is for iommu hw info. Extending it to
> report PASID supporting makes it cover device capability now. I may need to
> add one more capability enum in struct iommu_hw_info just like the below
> one. Perhaps name it as iommufd_device_capabilities. And only set the
> PASID
> capability in the new device capability when the device's or its PF's pasid
> cap is enabled. Does it look good?
Just add a new bit in iommufd_hw_capabilities.
Anyway PASID is meaningful only when both device and IOMMU supports
it. Here we are reporting what IOMMU capabilities meaningful to a given
device so checking both does make sense.
>
>
> /**
> * enum iommufd_hw_capabilities
> * @IOMMU_HW_CAP_DIRTY_TRACKING: IOMMU hardware support for
> dirty tracking
> * If available, it means the following APIs
> * are supported:
> *
> * IOMMU_HWPT_GET_DIRTY_BITMAP
> * IOMMU_HWPT_SET_DIRTY_TRACKING
> *
> */
> enum iommufd_hw_capabilities {
> IOMMU_HW_CAP_DIRTY_TRACKING = 1 << 0,
> };
>
> >>
> >> 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.
>
> I see. But we cannot know it until a guest device driver failed. This is
> acceptable. right? Perhaps this should be documented somewhere to let the
> user/device vendor know before safely exposing vPASID cap on a device. :)
>
presumably in VMM.
