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?
/**
* 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. :)
--
Regards,
Yi Liu
