[Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

Jason Gunthorpe jgg at nvidia.com
Thu Mar 23 12:02:04 UTC 2023


On Thu, Mar 23, 2023 at 03:15:20AM +0000, Liu, Yi L wrote:
> > From: Jason Gunthorpe <jgg at nvidia.com>
> > Sent: Wednesday, March 22, 2023 9:43 PM
> > 
> > On Wed, Mar 22, 2023 at 01:33:09PM +0000, Liu, Yi L wrote:
> > 
> > > Thanks. So this new _INFO only reports a limited scope instead of
> > > the full list of affected devices. Also, it is not static scope since device
> > > may be opened just after the _INFO returns.
> > 
> > Yes, it would be simplest for qemu to do the query after it gains a
> > new dev_id and then it can add the new dev_id with the correct reset
> > group.
> 
> I see. QEMU can decide. For now, it seems like QEMU doesn't store
> such the info return by the existing _INFO ioctl. It is used in the hot
> reset helper and freed before it returns. Though, I'm not sure whether
> QEMU will store the dev_id info returned by the new _INFO. Perhaps
> Alex can give some guidance.

That seems a bit confusing, qemu should take the reset group
information and encode it so that the guest can know it as well.

If all it does is blindly invoke the hot_reset with the right
parameters then what was the point of all this discussion?
 
> btw.  Another question about this new _INFO ioctl. If there are affected
> devices that have not been bound to vfio driver yet, should this new _INFO
> ioctl fail all the same with EPERM? 

Yeah, it should EPERM the same as the normal hot reset if it can't
marshal the device list.

Jason


More information about the Intel-gfx mailing list