On 3/23/24 12:59 AM, Jason Gunthorpe wrote:
On Thu, Mar 14, 2024 at 03:41:23PM +0800, Baolu Lu wrote:
The whole cookie mechanism aims to address two things:
- Extend the domain lifetime until all pending page faults are
resolved.
Like you answered, I think the flush is a simpler scheme..
Yeah! Let me head this direction.
- Associate information about the iommu device with each attachment of
the domain so that the iommufd device object ID could be quickly
retrieved in the fault delivering path.
I see we also need to stick a pointer in the domain for iommufd to get
back to the hwpt, but that doesn't seem to need such a big system to
accomplish - just add a void *. It would make sense for the domain to
have some optional pointer to a struct for all the fault related data
that becomes allocated when a PRI domain is created..
It's not getting back hwpt from domain, just getting the iommufd_device
in the fault delivering path. The iommufd_device is not per-domain, but
per-domain-attachment.
It does make sense you'd need that, but I think something like this is
a more direct way to get it. Caller allocates the handle struct. The
iopf will provide the handle from the XA to the
callback. container_of() not void * is used to in the caller's API.
Your code looks attractive to me. It's much simpler. Thank you!
Best regards,
baolu
