On Fri, Nov 19, 2021 at 04:06:12PM +0100, Jörg Rödel wrote: > This change came to be because the iommu_attach/detach_device() > interface doesn't fit well into a world with iommu-groups. Devices > within a group are by definition not isolated between each other, so > they must all be in the same address space (== iommu_domain). So it > doesn't make sense to allow attaching a single device within a group to > a different iommu_domain. It is the same problem VFIO has. It changes the iommu_domain of a group while it only has a single driver bound to one device in the group. Robin is also right to point out there is no guarentee that a single device group will remain a single device group after a hot plug event. This is something VFIO is also able to handle today. So, I think the solution of this series applies equally well to this problem. Let's see it in v2. > I know that in theory it is safe to allow devices within a group to be > in different domains because there iommu-groups catch multiple > non-isolation cases: > > 1) Devices behind a non-ACS capable bridge or multiple functions > of a PCI device. Here it is safe to put the devices into > different iommu-domains as long as all affected devices are > controlled by the same owner. > > 2) Devices which share a single request-id and can't be > differentiated by the IOMMU hardware. These always need to be > in the same iommu_domain. > To lift the single-domain-per-group requirement the iommu core code > needs to learn the difference between the two cases above. We had a long talk about this a while back, nobody came with compelling arguments to justify doing this work. I've just been using it as a guidepost for building APIs. If the API can accomodate #1 then it is a better design than one that cannot. Jason
