> From: Alex Williamson <alex.williamson@xxxxxxxxxx> > Sent: Tuesday, March 28, 2023 10:26 PM > > On Tue, 28 Mar 2023 06:19:06 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > > > Sent: Tuesday, March 28, 2023 11:32 AM > > > > > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > > > Sent: Tuesday, March 28, 2023 3:26 AM > > > > > > > > Additionally, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO has a flags arg > that > > > > isn't used, why do we need a new ioctl vs defining > > > > VFIO_PCI_HOT_RESET_FLAG_IOMMUFD_DEV_ID. > > > > > > Sure. I can follow this suggestion. BTW. I have a doubt here. This new > flag > > > is set by user. What if in the future kernel has new extensions and needs > > > to report something new to the user and add new flags to tell user? Such > > > flag is set by kernel. Then the flags field may have two kinds of flags > (some > > > set by user while some set by kernel). Will it mess up the flags space? > > > > > > > flags in a GET_INFO ioctl is for output. > > > > if user needs to use flags as input to select different type of info then it > should > > be split into multiple GET_INFO cmds. > > I don't know that that's actually a rule, however we don't currently > test flags is zero for input, so in this case I think we are stuck with > it only being for output. > > Alternatively, should VFIO_DEVICE_GET_PCI_HOT_RESET_INFO > automatically > return the dev_id variant of the output and set a flag to indicate this > is the case when called on a device fd opened as a cdev? Thanks, Personally I prefer that user asks for dev_id info explicitly. The major reason that we return dev_id is that the group/bdf info is not enough for the device fd passing case. But if qemu opens device by itself, the group/bdf info is still enough. So a device opened as a cdev doesn't mean it should return dev_id, it depends on if user has the bdf knowledge. Regards, Yi Liu
