Messages in this thread | | | Date | Mon, 20 Mar 2023 10:03:04 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v1 14/14] iommu/arm-smmu-v3: Add arm_smmu_cache_invalidate_user |
| |
On Sat, Mar 11, 2023 at 03:56:50AM -0800, Nicolin Chen wrote:
> I recall that one difficulty is to pass the vSID from the guest > down to the host kernel driver and to link with the pSID. What I > did previously for VCMDQ was to set the SID_MATCH register with > iommu_group_id(group) and set the SID_REPLACE register with the > pSID. Then hyper will use the iommu_group_id to search for the > pair of the registers, and to set vSID. Perhaps we should think > of something smarter.
We need an ioctl for this, I think. To load a map of vSID to dev_id into the driver. Kernel will convert dev_id to pSID. Driver will program the map into HW.
SW path will program the map into an xarray
> > I suspect the answer to Robin's question on how to handle errors is > > the most important deciding factor. If we have to capture and relay > > actual HW errors back to userspace that really suggests we should do > > something different than a synchronous ioctl. > > A synchronous ioctl is to return some values other than defining > cache_invalidate_user as void, like we are doing now? An fault > injection pathway to report CERROR asynchronously is what we've > been doing though -- even with Eric's previous VFIO solution.
Where is this? How does it look?
Jason
| |