> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, March 29, 2023 11:58 PM > > 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. Agree. > > > 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. > IIRC we discussed this subgroup concept in the thread of reviewing my high level design proposal 2yrs ago. The consensus at the moment was that subgroup is architecturally allowed w/o DMA aliasing issues but we're yet to see a real demand of relaxing current group restriction to support it. Also with time moving newer platforms should have less multi-devices group so the need of subgroup is further decreased. So I'm also inclined to laying the existing group restriction with cdev for now. Then can we make a decision how this group_id might be reported? In nesting series we'll have a GET_INFO ioctl per dev_id. It could be extended to report group_id too. Or alternatively just return it in BIND_IOMMUFD together with dev_id.
