On Wed, Mar 29, 2023 at 09:49:44AM -0600, Alex Williamson wrote: > > We could extend bind_iommufd to return the group id or introduce a > > new ioctl to query it per dev_id. > > That would be ironic to go to all this trouble to remove groups from > the API only to have them show up here. Groups always had to be part of the API for advanced cases like qemu - the point was to make them a small side bit of information not front and center in control of everything. > For example, devices within a group cannot be bound to separate > iommufds due to lack of isolation, which is handled via DMA ownership, > but barring DMA aliasing issues, due to conventional PCI buses or > quirks, cdev could allow devices within the same group to be managed by > separate IOAS's. Maybe some future kernel could do this, the API allows it at least.. > So the group information really isn't enough for > userspace to infer address space restrictions with cdev anyway. > > Therefore aren't we expecting this to be denied at attach_ioas() and > QEMU shouldn't be making these sorts of assumptions for cdev anyway? I guess we could make an API specifically to report same-iommu_domina information? I was assuming qemu would use the group for now as I don't see a likely future when we would relax that restriction.. So I was keeping a "add it when we need it" attitude here. Jason
