On Wed, Jun 12, 2024 at 10:19:46AM -0300, Jason Gunthorpe wrote:
> > > I prefer not to mess the definition of user API data and the kernel
> > > driver implementation. The kernel driver may change in the future, but
> > > the user API will remain stable for a long time.
> >
> > sure it remains stable for reasonable reason. Here we defined some
> > fields but they are even not used and checked in the kernel. IMHO it
> > suggests redundant definition. If there is value to keep them, do we
> > need to at least verify them same as the completion record?
>
> They are not here for the kernel, they are here for userspace.
>
> A single HWPT and a single fault queue can be attached to multiple
> devices we need to return the dev_id so that userspace can know which
> device initiated the PRI. Same with PASID.
>
> The only way we could remove them is if we are sure that no vIOMMU
> requires RID or PASID in the virtual fault queue PRI fault message.. I
> don't think that is true?
>
> Cookie is not a replacement, cookie is an opaque value for the kernel
> to use to match a response to a request.
Oh I got this wrong, the above is the response, yeah we can ditch
everything but the cookie, and code right?
struct iommu_hwpt_page_response {
__u32 cookie;
__u32 code;
};
What is the workflow here? We expect the VMM will take the vIOMMU
response and match it to a request cookie for the kernel to complete?
Jason
