RE: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

Tian, Kevin
2021-04-28T06:58:19Z

> From: Jason Gunthorpe <jgg-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Sent: Wednesday, April 28, 2021 1:12 AM
>
[...]
> > As Alex says, if this line fails because of the group restrictions,
> > that's not great because it's not very obvious what's gone wrong.
>
> Okay, that is fair, but let's solve that problem directly. For
> instance netlink has been going in the direction of adding a "extack"
> from the kernel which is a descriptive error string. If the failing
> ioctl returned the string:
>
> "cannot join this device to the IOASID because device XXX in the
> same group #10 is in use"
>
> Would you agree it is now obvious what has gone wrong? In fact would
> you agree this is a lot better user experience than what applications
> do today even though they have the group FD?
>

Currently all the discussions are around implicit vs. explicit uAPI semantics
on the group restriction. However if we look beyond group the implicit
semantics might be inevitable when dealing with incompatible iommu
domains. An existing example of iommu incompatibility is IOMMU_
CACHE. In the future there could be other incompatibilities such as
whether nested translation is supported. In the end the userspace has
to do some due diligence on understanding iommu topology and attributes
to decide how many VFIO containers or ioasid fds should be created. It
does push some burden to userspace but it's difficult to define a group-
like kernel object to enforce such restriction for iommu compatibility.
Then the best that the kernel can do is to return an informational error
message in case an incompatible device is attached to the existing domain.
If this is the perceived way to move forward anyway, I feel that removing
explicit group FD from uAPI doesn't make userspace worse...

Thanks
Kevin