Hi, Jason,
> From: Jason Gunthorpe <[email protected]>
> Sent: Friday, June 25, 2021 10:36 PM
>
> The only thing that needs to be done to get the 1:1 step is to broadly
> define how the other two cases will work so we don't get into trouble
> and set some way to exclude the problematic cases from even getting to
> iommu_fd in the first place.
>
> For instance if we go ahead and create /dev/vfio/device nodes we could
> do this only if the group was 1:1, otherwise the group cdev has to be
> used, along with its API.
>
I may misunderstand your position in last reply.
The bottom line is that iommu fd uAPI and helper functions should be
device-centric (no group fd carried). This is what this sketch tries to
achieve.
However I'm getting confused on your position on vfio uAPIs.
At some point I feel you are OK to keep vfio group fd:
"For others, I don't think this is *strictly* necessary, we can
probably still get to the device_fd using the group_fd and fit in
/dev/ioasid. It does make the rest of this more readable though."
https://lore.kernel.org/linux-iommu/ph0pr12mb54811863b392c644e5365446dc...@ph0pr12mb5481.namprd12.prod.outlook.com/T/#m1b1d2b4d6413e3b32ba972a97c2c6a16bf491796
But you are also obviously against faking group for mdev.
Combining with the last paragraph above, are you actually suggesting
that 1:1 group (including mdev) should use a new device-centric vfio
uAPI (without group fd) while existing group-centric vfio uAPI is only
kept for 1:N group (with slight semantics change in my sketch to match
device-centric iommu fd API)?
If yes, some assumptions in this sketch might be changed. For example,
with /dev/vfio/device node I'm not sure how the user can pass {iommu_fd,
device_cookie} to establish the security context when opening the node
(not via an indirect group ioctl). Then it implies that we may have to allow
the user open a device before it is put into a security context, thus the
safe guard may have to be enabled on mmap() for 1:1 group. This is a
different sequence from the existing group-centric model.
Anyway, appreciate if you can elaborate your thoughts so we can further
think about them.
Thanks
Kevin
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
