From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Qian Cai <cai@lca.pw>, Eric Farman <farman@linux.ibm.com>,
Joerg Roedel <jroedel@suse.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Yi Liu <yi.l.liu@intel.com>
Subject: Re: [PATCH 0/3] Allow the group FD to remain open when unplugging a device
Date: Thu, 6 Oct 2022 19:42:38 -0300 [thread overview]
Message-ID: <Yz9Z3um1HQHnEGVv@nvidia.com> (raw)
In-Reply-To: <20221006135315.3270b735.alex.williamson@redhat.com>
On Thu, Oct 06, 2022 at 01:53:15PM -0600, Alex Williamson wrote:
> On Thu, 6 Oct 2022 09:40:35 -0300
> Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> > Testing has shown that virtnodedevd will leave the group FD open for long
> > periods, even after all the cdevs have been destroyed. This blocks
> > destruction of the VFIO device and is undesirable.
> >
> > That approach was selected to accomodate SPAPR which has an broken
> > lifecyle model for the iommu_group. However, we can accomodate SPAPR by
> > realizing that it doesn't use the iommu core at all, so rules about
> > iommu_group lifetime do not apply to it.
> >
> > Giving the KVM code its own kref on the iommu_group allows the VFIO core
> > code to release its iommu_group reference earlier and we can remove the
> > sleep that only existed for SPAPR.
> >
> > Jason Gunthorpe (3):
> > vfio: Add vfio_file_is_group()
> > vfio: Hold a reference to the iommu_group in kvm for SPAPR
> > vfio: Make the group FD disassociate from the iommu_group
> >
> > drivers/vfio/pci/vfio_pci_core.c | 2 +-
> > drivers/vfio/vfio.h | 1 -
> > drivers/vfio/vfio_main.c | 90 +++++++++++++++++++++-----------
> > include/linux/vfio.h | 1 +
> > virt/kvm/vfio.c | 45 +++++++++++-----
> > 5 files changed, 94 insertions(+), 45 deletions(-)
>
> Containers aren't getting cleaned up with this series, starting and
> shutting down a libvirt managed VM with vfio-pci devices, an mtty mdev
> device, and making use of hugepages, /proc/meminfo shows the hugepages
> are not released on VM shutdown and I'm unable to subsequently restart
> the VM. Thanks,
Oh, I'm surprised the s390 testing didn't hit this!!
This hunk should remain since not all cases are closures due to device
hot unplug
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index f9cb734d3991b3..62aba3a128fb8d 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -954,6 +954,13 @@ static int vfio_group_fops_release(struct inode *inode, struct file *filep)
filep->private_data = NULL;
mutex_lock(&group->group_lock);
+ /*
+ * Device FDs hold a group file reference, therefore the group release
+ * is only called when there are no open devices.
+ */
+ WARN_ON(group->notifier.head);
+ if (group->container)
+ vfio_group_detach_container(group);
group->opened_file = NULL;
mutex_unlock(&group->group_lock);
return 0;
next prev parent reply other threads:[~2022-10-06 22:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 12:40 [PATCH 0/3] Allow the group FD to remain open when unplugging a device Jason Gunthorpe
2022-10-06 12:40 ` [PATCH 1/3] vfio: Add vfio_file_is_group() Jason Gunthorpe
2022-10-06 18:11 ` Alex Williamson
2022-10-06 12:40 ` [PATCH 2/3] vfio: Hold a reference to the iommu_group in kvm for SPAPR Jason Gunthorpe
2022-10-06 12:40 ` [PATCH 3/3] vfio: Make the group FD disassociate from the iommu_group Jason Gunthorpe
2022-10-06 19:53 ` [PATCH 0/3] Allow the group FD to remain open when unplugging a device Alex Williamson
2022-10-06 22:42 ` Jason Gunthorpe [this message]
2022-10-06 23:28 ` Matthew Rosato
2022-10-07 1:46 ` Matthew Rosato
2022-10-07 13:37 ` Jason Gunthorpe
2022-10-07 14:37 ` Matthew Rosato
2022-10-07 14:39 ` Jason Gunthorpe
2022-10-07 14:46 ` Matthew Rosato
2022-10-07 11:17 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yz9Z3um1HQHnEGVv@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=cai@lca.pw \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mjrosato@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=yi.l.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.