On Wed, 2025-08-20 at 08:22 -0400, Jonah Palmer wrote:
> > > > > > From: Eugenio Pérez <epere...@redhat.com>
> > > > > >
> > > > > > Commit a0d7215e33 ("vhost-vdpa: do not cleanup the vdpa/vhost-net
> > > > > > structures if peer nic is present") effectively delayed the backend
> > > > > > cleanup, allowing the frontend or the guest to access it resources
> > > > > > as
> > > > > > long as the frontend is still visible to the guest.
> > > > > >
> > > > > > However it does not clean up the resources until the qemu process is
> > > > > > over. This causes an effective leak if the device is deleted with
> > > > > > device_del, as there is no way to close the vdpa device. This makes
> > > > > > impossible to re-add that device to this or other QEMU instances
> > > > > > until
> > > > > > the first instance of QEMU is finished.
> > > > > >
> > > > > > Move the cleanup from qemu_cleanup to the NIC deletion and to
> > > > > > net_cleanup.
> > > > > >
> > > > > > Fixes: a0d7215e33 ("vhost-vdpa: do not cleanup the
> > > > > > vdpa/vhost-net structures if peer nic is present")
> > > > > > Reported-by: Lei Yang <leiy...@redhat.com>
> > > > > > Signed-off-by: Eugenio Pérez <epere...@redhat.com>
> > > > > > Signed-off-by: Jonah Palmer <jonah.pal...@oracle.com>
> > > > > > Signed-off-by: Jason Wang <jasow...@redhat.com>Is it just that VDPA devices should have an unrealize() method to properly tear themselves down? The problem appears to happen to the Xen netdev when it gets torn down twice, precisely because it *was* doing the right thing for itself?
smime.p7s
Description: S/MIME cryptographic signature
