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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
> Sent: Friday, March 24, 2023 5:25 PM
> 
> > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > Sent: Thursday, March 23, 2023 8:02 PM
> >
> > On Thu, Mar 23, 2023 at 03:15:20AM +0000, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > > > 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.
> 
> Hi Jason, Alex,
> 
> I got a draft patch to add the new _INFO? It checks if all the affected devices
> are in the dev_set, and then gets the dev_id of all the opened devices within
> the dev_set. There is still one thing not quite clear. It is the noiommu mode.
> In this mode, there is no iommufd bind, so no dev_id. For now, I just fail this
> new _INFO ioctl if there is no iommufd_device. Hence, this new _INFO is not
> available for users that operating in noiommu mode. Is this acceptable?

The latest _INFO ioctl is in below link.

https://lore.kernel.org/kvm/20230327093458.44939-11-yi.l.liu@xxxxxxxxx/





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux