On 2023/7/13 16:01, Tian, Kevin wrote:
From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
Sent: Thursday, July 13, 2023 11:44 AM
On 2023/7/13 11:24, Tian, Kevin wrote:
From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
Sent: Wednesday, July 12, 2023 11:13 AM
On 2023/7/12 6:02, Jacob Pan wrote:
On Tue, 11 Jul 2023 09:06:42 +0800, Lu Baolu<baolu.lu@xxxxxxxxxxxxxxx>
wrote:
@@ -158,7 +158,7 @@ int iommu_queue_iopf(struct iommu_fault
*fault,
struct device *dev)
* As long as we're holding param->lock, the queue can't be
unlinked
* from the device and therefore cannot disappear.
*/
- iopf_param = param->iopf_param;
+ iopf_param = iommu_get_device_fault_cookie(dev, 0);
I am not sure I understand how does it know the cookie type is
iopf_param
for PASID 0?
Between IOPF and IOMMUFD use of the cookie, cookie types are
different,
right?
The fault cookie is managed by the code that delivers or handles the
faults. The sva and IOMMUFD paths are exclusive.
what about siov? A siov-capable device can support sva and iommufd
simultaneously.
For siov case, the pasid should be global. RID and each pasid are still
exclusive, so I don't see any problem. Did I overlook anything?
they are exclusive but it's weird to see some pasids (for sva) on this
device are tracked by slot#0 while other pasids (for iommufd) occupies
per-pasid slot.
why not generalizing them given you name it as "per-pasid fault cookie"?
Yeah! Get your point now. At least the partial list should be per-pasid.
Let me invest more time on this.
Best regards,
baolu
