On Fri, Dec 15, 2023 at 01:50:07AM +0000, Tian, Kevin wrote:
- Reuse Nicolin's vRID->pRID mapping. If thevRID->pRID mapping is
maintained, then intel iommu can report a vRID back to user. But intel iommu driver does not have viommu context, no place to hold the vRID-
pRID
mapping. TBH. It may require other reasons to introduce it other than the error reporting need. Anyhow, this requires more thinking and also has dependency even if it is doable in intel side.
this sounds like a cleaner way to inject knowledge which iommu driver requires to find out the user tag. but yes it's a bit weird to introduce viommu awareness in intel iommu driver when there is no such thing in real hardware.
and for this error reporting case what we actually require is the reverse map i.e. pRID->vRID. Not sure whether we can leverage the same RID mapping uAPI as for ARM/AMD but ignore viommu_id and then store vRID under device_domain_info. a bit tricky on life cycle management and also incompatible with SIOV...
let's see whether Jason has a better idea here.
I think v10 is OK
struct iommu_hwpt_invalidate { __u32 size; __u32 hwpt_id; __aligned_u64 data_uptr; __u32 data_type; __u32 entry_len; __u32 entry_num; __u32 __reserved; };
Sends the invalidation to the HWPT which matches what Intel wanted where the entire HWPT and all its associated devices are invalidated. No seperate per-device invalidation.
For error and event reporting they should be returned to userspace with the IOMMU dev_id indicating the originating PCI function.
The VMM would have to convert dev_id into vRID according to the vIOMMU instance that the device is hooked up.
In iommu land we should never have a "RID" but always some kind of device-specific "device ID" which is the index into the particular HW table, and that ID is naturally scoped to within the IOMMU instance that owns the table - so it is very much not a global ID that can be used alone in any of the uAPI.
The uAPI should use the iommufd device ID to refer to specific devices.
Jason