> From: Tian, Kevin <kevin.tian@xxxxxxxxx> > Sent: Thursday, March 30, 2023 9:10 AM > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Sent: Wednesday, March 29, 2023 11:50 PM > > > > On Wed, Mar 29, 2023 at 09:41:26AM +0000, Tian, Kevin wrote: > > > > > We could extend bind_iommufd to return the group id or introduce a > > > new ioctl to query it per dev_id. > > > > > Once that is in place looks we don't need a new _INFO ioctl? > > > > The iommu_group and the reset group are different things > > > > The issue is processing the BDF strings, not the group ID. > > > > Probably we should have some way for iommufd to report the group_id > > from the dev_id? > > > > Yes, that is my thought. Though iommu_group and reset group are > different things we could still leverage existing _INFO ioctl once there > is a way to associated dev_id to group_id. Please ignore this comment. Yes they are different things so even if a dev_id is in a group_id reported on a reset BDF string it doesn't mean this dev_id is in the reset group. Qemu can know that all affected devices are either owned by itself or not used by other processes if dev_id's opened by itself can be associated to all group_id's reported in the BDF strings. But it still lacks of information to tell the reset dependency within those opened devices within Qemu. So we do need a new _INFO ioctl for cdev. :/
