> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> Sent: Friday, May 19, 2023 10:04 AM
>
> On 2023/5/18 20:02, Jason Gunthorpe wrote:
> > On Thu, May 18, 2023 at 03:05:23PM +0800, Baolu Lu wrote:
> >
> >> If so, perhaps we need some special treatment for ARM as a user hwpt
> >> actually presents the PASID table of the device and the guest setting
> >> pasid table entry will not be propagated to host. Then, the @pasid in
> >> above interfaces is meaningless.
> >
> > As above, when attaching to a RID you'd still pass in the *data
>
> Yes! Merging these with hwpt attach/detach would be more logical.
Probably we still need a way in iommu core to differentiate whether
to look at *data according to {RID} alone or {RID, PASID} when receiving
a fault request tagged by {struct device, pasid} from the underlying
iommu driver.
That might be just implementation detail, though.
>
> >
> >> 1) Move iommu faults uapi from uapi/linux/iommu.h to uapi/linux
> >> /iommufd.h and remove the former.
> >
> > Please no, delete all the dead code from here and move whatever is
> > still in use into include/linux/
> >
> > Then we can talk about what parts of it become uAPI and how best to
> > manage that on a patch by patch basis.
>
> Okay, let's rebuild it from the ground up.
>
yes. Actually that uapi is incomplete. It contains only definitions of
data structures but no actual command. It's hard to say that definition
is sufficient w/o actually involving the command.
