From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
Sent: Thursday, July 13, 2023 11:44 AM
On 2023/7/13 11:24, Tian, Kevin wrote:
*fault,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
iopf_paramstruct device *dev)I am not sure I understand how does it know the cookie type is
* 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);
different,for PASID 0?
Between IOPF and IOMMUFD use of the cookie, cookie types are
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"?