On 2021/11/19 13:44, Tian, Kevin wrote:
From: Jason Gunthorpe <jgg@xxxxxxxxxx>
Sent: Thursday, November 18, 2021 9:33 PM
In concept a singleton group is different from a
multi-devices group which has only one device bound to driver...
Really? Why? I don't see it that way..
A singleton group is just a multi-device group that hasn't been
hotplugged yet.
We don't seem to have the concept of a "true" singleton group which is
permanently single due to HW features.
This series aims to avoid conflict having both user and kernel drivers
mixed in a multi-devices group.
Well, the difference is just in literal. I don't know the background
why the existing iommu_attach_device() users want to do it this
way. But given the condition in iommu_attach_device() it could
in theory imply some unknown hardware-level side effect which
may break the desired functionality once the group size grows
beyond singleton. Is it a real case? I don't know...
You are now redefining that condition from singleton group to
multi-devices group with single driver bound. As long as no object
from existing driver users, I'm fine with it. But still want to raise
awareness as it does change the existing semantics (though might
be considered as an imperfect way).
The singleton group requirement for iommu_attach/detach_device() was
added by below commit:
commit 426a273834eae65abcfc7132a21a85b3151e0bce
Author: Joerg Roedel <jroedel@xxxxxxx>
Date: Thu May 28 18:41:30 2015 +0200
iommu: Limit iommu_attach/detach_device to devices with their own group
This patch changes the behavior of the iommu_attach_device
and iommu_detach_device functions. With this change these
functions only work on devices that have their own group.
For all other devices the iommu_group_attach/detach
functions must be used.
Signed-off-by: Joerg Roedel <jroedel@xxxxxxx>
Joerg,can you please shed some light on the background of this
requirement? Does above idea of transition from singleton group
to group with single driver bound make sense to you?
Best regards,
baolu
