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, Alex
