From: Jason Gunthorpe <jgg@nvidia.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Zhi Wang <zhi.a.wang@intel.com>,
intel-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 24/34] drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
Date: Mon, 11 Apr 2022 15:33:22 -0300 [thread overview]
Message-ID: <20220411183322.GZ2120790@nvidia.com> (raw)
In-Reply-To: <20220411141403.86980-25-hch@lst.de>
On Mon, Apr 11, 2022 at 04:13:53PM +0200, Christoph Hellwig wrote:
> All the dmabufs are torn down when th VGPU is released, so there is
> no need for extra refcounting here.
'th' -> 'the'
I think the specific argument is that intel_vgpu_query_plane() is only
called from intel_vgpu_ioctl() which has to happen while the device is
open so intel_vgpu_query_plane() has no issue.
dmabuf_gem_object_free() is OK because:
intel_vgpu_close_device
__intel_vgpu_release
intel_gvt_release_vgpu
intel_vgpu_dmabuf_cleanup
Menaing dmabuf->vgpu was already NULL once close_device is passed, and
the vfio_device reference is held automatically from open_device->close_device
And similarly intel_vgpu_dmabuf_cleanup() is OK because it is called
by the above.
The other places that call intel_vgpu_dmabuf_cleanup() are redundant
with the close_device path.
Though the 'release_work' callpath is buggy, for many reasons, but not
for this series.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 90443306a9ad4..01e54b45c5c1b 100644
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -139,7 +139,6 @@ static void dmabuf_gem_object_free(struct kref *kref)
> dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj, list);
> if (dmabuf_obj == obj) {
Not for this series but it seems like there is something off about
the locking here:
if (vgpu && vgpu->active && !list_empty(&vgpu->dmabuf_obj_list_head)) {
This is called under the dmabuf lock but active is protected by the
vgpu_lock.. It seems strange that vgpu->active could be false but the
device is still open, so maybe it is not possible.
Jason
next prev parent reply other threads:[~2022-04-11 18:33 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-11 14:13 refactor the i915 GVT support and move to the modern mdev API v3 Christoph Hellwig
2022-04-11 14:13 ` [PATCH 01/34] drm/i915/gvt: remove module refcounting in intel_gvt_{,un}register_hypervisor Christoph Hellwig
2022-04-11 14:13 ` [PATCH 02/34] drm/i915/gvt: remove enum hypervisor_type Christoph Hellwig
2022-04-11 15:23 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 03/34] drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops Christoph Hellwig
2022-04-11 15:23 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 04/34] drm/i915/gvt: don't override the include path Christoph Hellwig
2022-04-11 15:24 ` Jason Gunthorpe
2022-04-11 16:09 ` Jani Nikula
2022-04-11 14:13 ` [PATCH 05/34] drm/i915/gvt: cleanup the Makefile Christoph Hellwig
2022-04-11 15:25 ` Jason Gunthorpe
2022-04-11 16:11 ` Jani Nikula
2022-04-11 16:51 ` Christoph Hellwig
2022-04-13 12:33 ` Jani Nikula
2022-04-13 13:39 ` Wang, Zhi A
2022-04-13 13:43 ` Jason Gunthorpe
2022-04-13 14:26 ` Wang, Zhi A
2022-04-13 14:45 ` Jason Gunthorpe
2022-04-21 6:40 ` Joonas Lahtinen
2022-04-11 14:13 ` [PATCH 06/34] drm/i915/gvt: move the gvt code into kvmgt.ko Christoph Hellwig
2022-04-11 18:43 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 07/34] drm/i915/gvt: remove intel_gvt_ops Christoph Hellwig
2022-04-11 15:32 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 08/34] drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops Christoph Hellwig
2022-04-11 16:00 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 09/34] drm/i915/gvt: remove the unused from_virt_to_mfn op Christoph Hellwig
2022-04-11 16:00 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 10/34] drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu Christoph Hellwig
2022-04-11 16:12 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 11/34] drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu Christoph Hellwig
2022-04-11 16:13 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 12/34] drm/i915/gvt: remove vgpu->handle Christoph Hellwig
2022-04-11 16:14 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 13/34] drm/i915/gvt: devirtualize ->{read,write}_gpa Christoph Hellwig
2022-04-11 16:15 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 14/34] drm/i915/gvt: devirtualize ->{get,put}_vfio_device Christoph Hellwig
2022-04-11 16:26 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 15/34] drm/i915/gvt: devirtualize ->set_edid and ->set_opregion Christoph Hellwig
2022-04-11 16:27 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 16/34] drm/i915/gvt: devirtualize ->detach_vgpu Christoph Hellwig
2022-04-11 16:27 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 17/34] drm/i915/gvt: devirtualize ->inject_msi Christoph Hellwig
2022-04-11 16:28 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 18/34] drm/i915/gvt: devirtualize ->is_valid_gfn Christoph Hellwig
2022-04-11 16:29 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 19/34] drm/i915/gvt: devirtualize ->gfn_to_mfn Christoph Hellwig
2022-04-11 16:29 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 20/34] drm/i915/gvt: devirtualize ->{enable,disable}_page_track Christoph Hellwig
2022-04-11 16:31 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 21/34] drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page Christoph Hellwig
2022-04-11 18:08 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 22/34] drm/i915/gvt: devirtualize dma_pin_guest_page Christoph Hellwig
2022-04-11 18:09 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 23/34] drm/i915/gvt: remove struct intel_gvt_mpt Christoph Hellwig
2022-04-11 18:13 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 24/34] drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs Christoph Hellwig
2022-04-11 18:33 ` Jason Gunthorpe [this message]
2022-04-11 14:13 ` [PATCH 25/34] drm/i915/gvt: streamline intel_vgpu_create Christoph Hellwig
2022-04-11 18:37 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 26/34] drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers Christoph Hellwig
2022-04-11 18:38 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 27/34] drm/i915/gvt: remove kvmgt_guest_{init,exit} Christoph Hellwig
2022-04-11 18:41 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 28/34] drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev Christoph Hellwig
2022-04-11 18:36 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 29/34] drm/i915/gvt: merge gvt.c into kvmgvt.c Christoph Hellwig
2022-04-11 18:42 ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 30/34] vfio/mdev: Remove vfio_mdev.c Christoph Hellwig
2022-04-12 20:51 ` Kirti Wankhede
2022-04-11 14:14 ` [PATCH 31/34] vfio/mdev: Remove mdev_parent_ops dev_attr_groups Christoph Hellwig
2022-04-12 20:51 ` Kirti Wankhede
2022-04-11 14:14 ` [PATCH 32/34] vfio/mdev: Remove mdev_parent_ops Christoph Hellwig
2022-04-12 20:51 ` Kirti Wankhede
2022-04-11 14:14 ` [PATCH 33/34] vfio/mdev: Use the driver core to create the 'remove' file Christoph Hellwig
2022-04-12 20:52 ` Kirti Wankhede
2022-04-11 14:14 ` [PATCH 34/34] vfio/mdev: Remove mdev drvdata Christoph Hellwig
2022-04-12 20:52 ` Kirti Wankhede
2022-04-13 13:47 ` refactor the i915 GVT support and move to the modern mdev API v3 Wang, Zhi A
2022-04-13 15:46 ` Christoph Hellwig
2022-04-13 15:58 ` Jani Nikula
2022-04-13 16:27 ` Christoph Hellwig
2022-04-13 23:13 ` Wang, Zhi A
2022-04-13 23:20 ` Jason Gunthorpe
2022-04-14 12:20 ` Wang, Zhi A
2022-04-14 13:34 ` Jason Gunthorpe
2022-04-14 13:39 ` Wang, Zhi A
2022-04-14 13:41 ` Jason Gunthorpe
2022-04-14 13:44 ` Jani Nikula
2022-04-14 13:40 ` Jani Nikula
2022-04-14 13:43 ` Jason Gunthorpe
2022-04-14 14:25 ` Wang, Zhi A
2022-04-14 14:38 ` Jason Gunthorpe
2022-04-20 7:08 ` Christoph Hellwig
2022-04-20 7:12 ` Wang, Zhi A
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=20220411183322.GZ2120790@nvidia.com \
--to=jgg@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.a.wang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox