> 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"?
