Yi, On 8/16/2024 6:49 AM, Yi Liu wrote: > On 2024/8/16 01:49, Vasant Hegde wrote: >> Hi All, >> >> On 6/28/2024 2:25 PM, Yi Liu wrote: >>> This splits the preparation works of the iommu and the Intel iommu driver >>> out from the iommufd pasid attach/replace series. [1] >>> >>> To support domain replacement, the definition of the set_dev_pasid op >>> needs to be enhanced. Meanwhile, the existing set_dev_pasid callbacks >>> should be extended as well to suit the new definition. >> >> IIUC this will remove PASID from old SVA domain and attaches to new SVA domain. >> (basically attaching same dev/PASID to different process). Is that the correct? > > In brief, yes. But it's not only for SVA domain. Remember that SIOVr1 > extends the usage of PASID. At least on Intel side, a PASID may be > attached to paging domains. Right. I missed SIOV case. > >> So the expectation is replace existing PASID from PASID table only if old_domain >> is passed. Otherwise sev_dev_pasid() should throw an error right? >> > > yes. If no old_domain passed in, then it is just a normal attachment. As > you are working on AMD iommu, it would be great if you can have a patch to > make the AMD set_dev_pasid() op suit this expectation. Then it can be > incorporated in this series. :)' Sure. It should be simple. I will try to get the patch next week. -Vasant
