All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Zhang, Tina" <tina.zhang@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>
Cc: "Wang, Zhenyu Z" <zhenyu.z.wang@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Chen, Xiaoguang" <xiaoguang.chen@intel.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>
Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Date: Mon, 26 Jun 2017 08:39:17 +0200	[thread overview]
Message-ID: <1498459157.20591.6.camel@redhat.com> (raw)
In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C5731B3@SHSMSX101.ccr.corp.intel.com>

  Hi,

> > With the generation we can also do something different:  Pass in
> > plane_type and
> > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in
> > case
> > the generation doesn't match.  In that case it doesn't make much
> > sense any
> > more to have a separate plane_info struct, which was added so we
> > don't have
> > to duplicate things in query-plane and get- dmabuf ioctl structs.
> 
> Comparing with the current patch, this would make user space a little
> bit harder to
> get the dmabuf by calling VFIO_DEVICE_GET_DMABUF ioctl. Is it
> efficient for
> user mode usage?

user space has to call QUERY-PLANE first, then looks if it has a dma-
buf for that, if not call GET-DMABUF.

Problem is the guest could have changed the plane between the QUERY-
PLANE and GET-DMABUF ioctls.

Current patches (v8 series) just returns plane-info on GET-DMABUF too,
so userspace can at least detect something changed.

It would be easier for userspace if GET-DMABUF throws an error in case
the plane changed since the last QUERY-PLANE ioctl.  The generation id
would be one way to handle it, but possibly it is easier if the kernel
driver just keeps track internally.  So GET-DMABUF would be defined to
return a dmabuf for the plane returned by the previous QUERY-PLANE
ioctl (on the same file handle), or return an error in case the plane
has changed meanwhile.

cheers,
  Gerd

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Zhang, Tina" <tina.zhang@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	"Chen, Xiaoguang" <xiaoguang.chen@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	"Wang, Zhi A" <zhi.a.wang@intel.com>,
	"Wang, Zhenyu Z" <zhenyu.z.wang@intel.com>
Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Date: Mon, 26 Jun 2017 08:39:17 +0200	[thread overview]
Message-ID: <1498459157.20591.6.camel@redhat.com> (raw)
In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C5731B3@SHSMSX101.ccr.corp.intel.com>

  Hi,

> > With the generation we can also do something different:  Pass in
> > plane_type and
> > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in
> > case
> > the generation doesn't match.  In that case it doesn't make much
> > sense any
> > more to have a separate plane_info struct, which was added so we
> > don't have
> > to duplicate things in query-plane and get- dmabuf ioctl structs.
> 
> Comparing with the current patch, this would make user space a little
> bit harder to
> get the dmabuf by calling VFIO_DEVICE_GET_DMABUF ioctl. Is it
> efficient for
> user mode usage?

user space has to call QUERY-PLANE first, then looks if it has a dma-
buf for that, if not call GET-DMABUF.

Problem is the guest could have changed the plane between the QUERY-
PLANE and GET-DMABUF ioctls.

Current patches (v8 series) just returns plane-info on GET-DMABUF too,
so userspace can at least detect something changed.

It would be easier for userspace if GET-DMABUF throws an error in case
the plane changed since the last QUERY-PLANE ioctl.  The generation id
would be one way to handle it, but possibly it is easier if the kernel
driver just keeps track internally.  So GET-DMABUF would be defined to
return a dmabuf for the plane returned by the previous QUERY-PLANE
ioctl (on the same file handle), or return an error in case the plane
has changed meanwhile.

cheers,
  Gerd

  reply	other threads:[~2017-06-26  6:39 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-15  8:00 [PATCH v9 0/7] drm/i915/gvt: Dma-buf support for GVT-g Xiaoguang Chen
2017-06-15  8:00 ` Xiaoguang Chen
2017-06-15  8:00 ` [PATCH v9 1/7] drm/i915/gvt: Extend the GVT-g architecture Xiaoguang Chen
2017-06-15  8:00 ` [PATCH v9 2/7] drm/i915/gvt: OpRegion support for GVT-g Xiaoguang Chen
2017-06-15  8:00   ` Xiaoguang Chen
2017-06-15  8:00 ` [PATCH v9 3/7] drm: Extend the drm format Xiaoguang Chen
2017-06-15  8:00   ` Xiaoguang Chen
2017-06-15 10:21   ` Ville Syrjälä
2017-06-15 10:21     ` [Intel-gfx] " Ville Syrjälä
2017-06-20  9:01     ` Zhang, Tina
2017-06-15  8:00 ` [PATCH v9 4/7] drm/i915/gvt: Frame buffer decoder support for GVT-g Xiaoguang Chen
2017-06-15  8:00   ` Xiaoguang Chen
2017-06-15  8:00 ` [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Xiaoguang Chen
2017-06-15  8:00   ` Xiaoguang Chen
2017-06-15 14:51   ` Kirti Wankhede
2017-06-15 14:51     ` Kirti Wankhede
2017-06-15 16:00     ` Gerd Hoffmann
2017-06-15 16:00       ` Gerd Hoffmann
2017-06-15 20:38       ` Alex Williamson
2017-06-15 20:38         ` Alex Williamson
2017-06-16 10:24         ` Gerd Hoffmann
2017-06-16 12:52           ` Alex Williamson
2017-06-16 13:32         ` Kirti Wankhede
2017-06-16 13:32           ` Kirti Wankhede
2017-06-16 16:39           ` Alex Williamson
2017-06-16 16:39             ` Alex Williamson
2017-06-16 18:28             ` Kirti Wankhede
2017-06-16 18:28               ` Kirti Wankhede
2017-06-19  6:34             ` Gerd Hoffmann
2017-06-19 14:54               ` Alex Williamson
2017-06-19 14:54                 ` Alex Williamson
2017-06-20  8:35                 ` Gerd Hoffmann
2017-06-20  8:35                   ` Gerd Hoffmann
2017-06-20 13:55                   ` Kirti Wankhede
2017-06-20 13:55                     ` Kirti Wankhede
2017-06-21  7:22                     ` Gerd Hoffmann
2017-07-12 13:18                       ` Kirti Wankhede
2017-07-12 13:18                         ` Kirti Wankhede
2017-07-14  9:58                         ` Gerd Hoffmann
2017-07-14  9:58                           ` Gerd Hoffmann
2017-06-19  6:38           ` Gerd Hoffmann
2017-06-19 14:55             ` Alex Williamson
2017-06-19 14:55               ` Alex Williamson
2017-06-20  8:41               ` Zhang, Tina
2017-06-20  8:41                 ` [Intel-gfx] " Zhang, Tina
2017-06-20 10:57                 ` Gerd Hoffmann
2017-06-20 10:57                   ` [Intel-gfx] " Gerd Hoffmann
2017-06-20 15:00                   ` Alex Williamson
2017-06-20 17:07                     ` Kirti Wankhede
2017-06-20 17:07                       ` [Intel-gfx] " Kirti Wankhede
2017-06-20 23:01                     ` Zhang, Tina
2017-06-20 23:01                       ` [Intel-gfx] " Zhang, Tina
2017-06-20 23:22                       ` Alex Williamson
2017-06-20 23:22                         ` [Intel-gfx] " Alex Williamson
2017-06-21  9:20                         ` Zhang, Tina
2017-06-21  9:20                           ` [Intel-gfx] " Zhang, Tina
2017-06-21 11:03                           ` Gerd Hoffmann
2017-06-21 18:59                             ` Alex Williamson
2017-06-22  8:30                               ` Gerd Hoffmann
2017-06-22  8:30                                 ` [Intel-gfx] " Gerd Hoffmann
2017-06-22 18:54                                 ` Alex Williamson
2017-06-22 18:54                                   ` [Intel-gfx] " Alex Williamson
2017-06-23  7:26                                   ` Gerd Hoffmann
2017-06-23  7:26                                     ` [Intel-gfx] " Gerd Hoffmann
2017-06-23  7:49                                     ` Zhi Wang
2017-06-23  7:49                                       ` Zhi Wang
2017-06-23  8:31                                       ` Gerd Hoffmann
2017-06-23 16:40                                         ` Alex Williamson
2017-06-23 16:40                                           ` [Intel-gfx] " Alex Williamson
2017-06-23 17:15                                     ` Alex Williamson
2017-06-23 17:15                                       ` [Intel-gfx] " Alex Williamson
2017-06-26  6:17                                       ` Gerd Hoffmann
2017-06-26  6:17                                         ` [Intel-gfx] " Gerd Hoffmann
2017-06-22  0:21                             ` Zhang, Tina
2017-06-22  0:21                               ` [Intel-gfx] " Zhang, Tina
2017-06-21  7:34                     ` Gerd Hoffmann
2017-06-21  7:34                       ` [Intel-gfx] " Gerd Hoffmann
2017-06-23 21:58                   ` Zhang, Tina
2017-06-23 21:58                     ` [Intel-gfx] " Zhang, Tina
2017-06-26  6:39                     ` Gerd Hoffmann [this message]
2017-06-26  6:39                       ` Gerd Hoffmann
2017-06-26 17:28                       ` Alex Williamson
2017-06-26 17:28                         ` [Intel-gfx] " Alex Williamson
2017-06-27  6:12                         ` Gerd Hoffmann
2017-06-27  6:12                           ` [Intel-gfx] " Gerd Hoffmann
2017-06-28 12:48                           ` Zhang, Tina
2017-06-28 12:48                             ` [Intel-gfx] " Zhang, Tina
2017-06-29  6:41                             ` Gerd Hoffmann
2017-06-29  6:41                               ` [Intel-gfx] " Gerd Hoffmann
2017-06-29  8:39                               ` Daniel Vetter
2017-06-29  8:39                                 ` [Intel-gfx] " Daniel Vetter
2017-07-04  0:47                                 ` Zhang, Tina
2017-07-04  0:47                                   ` [Intel-gfx] " Zhang, Tina
2017-06-20 13:35               ` Kirti Wankhede
2017-06-20 13:35                 ` Kirti Wankhede
2017-06-15  8:00 ` [PATCH v9 6/7] drm/i915/gvt: Dmabuf support for GVT-g Xiaoguang Chen
2017-06-15  8:00   ` Xiaoguang Chen
2017-06-15  8:00 ` [PATCH v9 7/7] drm/i915/gvt: Adding user interface for dma-buf Xiaoguang Chen
2017-06-15  8:00   ` Xiaoguang Chen
2017-06-15  8:03 ` ✗ Fi.CI.BAT: failure for drm/i915/gvt: dma-buf support for GVT-g (rev9) Patchwork

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=1498459157.20591.6.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tina.zhang@intel.com \
    --cc=xiaoguang.chen@intel.com \
    --cc=zhenyu.z.wang@intel.com \
    --cc=zhiyuan.lv@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.