All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>,
	Xiaoguang Chen <xiaoguang.chen@intel.com>,
	chris@chris-wilson.co.uk, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, zhenyuw@linux.intel.com,
	zhiyuan.lv@intel.com, intel-gvt-dev@lists.freedesktop.org,
	zhi.a.wang@intel.com, kevin.tian@intel.com
Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Date: Tue, 20 Jun 2017 10:35:03 +0200	[thread overview]
Message-ID: <1497947703.16795.4.camel@redhat.com> (raw)
In-Reply-To: <20170619085409.26f5c14c@w520.home>

  Hi,

> > Hmm, plane isn't really an ID, it is a type, with type being either
> > DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think
> > the
> > flage above make sense.
> 
> The intention was that ..._REGION_ID and ...PLANE_ID are describing
> what the vfio_device_query_gfx_plane.id field represents, either a
> region index or a plane identifier.  The type of plane would be
> represented within the vfio_device_gfx_plane_info struct.

The planes don't really have an id, we should rename that to
plane_type, or maybe drm_plane_type (simliar to the drm_format_*
fields), to avoid that confusion.

plane_type is set by userspace to specify what kind of plane it asks
for.

> > Also I think it would be useful to have some way to figure the
> > device
> > capabilities as the userspace workflow will look quite different
> > for
> > the two cases.
> 
> In the region case, VFIO_DEVICE_GET_REGION_INFO would include a
> device
> specific region with a hopefully common identifier to identify it as
> a
> graphics framebuffer.

Ok, that should work to figure whenever the mdev supports a plane
region or not.

> In the dmabuf case,VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
> plane as a "plane ID" and some sort of
> VFIO_DEVICE_GET_GFX_PLANE(VFIO_GFX_TYPE_DMABUF) ioctl would be
> necessary to get a file descriptor to that plane.
> 
> What else are you thinking we need?  Thanks,

I need to know whenever the mdev supports dmabufs or not, at device
initialization time (because dmabufs require opengl support), when
VFIO_DEVICE_QUERY_GFX_PLANE doesn't work due to the guest not having
the device initialized yet.

Maybe we should have a error field in the ioctl struct, or we need to
clearly define error codes so the kernel doesn't just throw EINVAL in
all cases.

Or just a VFIO_DEVICE_GFX_CAPS ioctl which returns NONE, REGION or
DMABUF.

cheers,
  Gerd

WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Xiaoguang Chen <xiaoguang.chen@intel.com>,
	intel-gvt-dev@lists.freedesktop.org, zhiyuan.lv@intel.com
Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations
Date: Tue, 20 Jun 2017 10:35:03 +0200	[thread overview]
Message-ID: <1497947703.16795.4.camel@redhat.com> (raw)
In-Reply-To: <20170619085409.26f5c14c@w520.home>

  Hi,

> > Hmm, plane isn't really an ID, it is a type, with type being either
> > DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think
> > the
> > flage above make sense.
> 
> The intention was that ..._REGION_ID and ...PLANE_ID are describing
> what the vfio_device_query_gfx_plane.id field represents, either a
> region index or a plane identifier.  The type of plane would be
> represented within the vfio_device_gfx_plane_info struct.

The planes don't really have an id, we should rename that to
plane_type, or maybe drm_plane_type (simliar to the drm_format_*
fields), to avoid that confusion.

plane_type is set by userspace to specify what kind of plane it asks
for.

> > Also I think it would be useful to have some way to figure the
> > device
> > capabilities as the userspace workflow will look quite different
> > for
> > the two cases.
> 
> In the region case, VFIO_DEVICE_GET_REGION_INFO would include a
> device
> specific region with a hopefully common identifier to identify it as
> a
> graphics framebuffer.

Ok, that should work to figure whenever the mdev supports a plane
region or not.

> In the dmabuf case,VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
> plane as a "plane ID" and some sort of
> VFIO_DEVICE_GET_GFX_PLANE(VFIO_GFX_TYPE_DMABUF) ioctl would be
> necessary to get a file descriptor to that plane.
> 
> What else are you thinking we need?  Thanks,

I need to know whenever the mdev supports dmabufs or not, at device
initialization time (because dmabufs require opengl support), when
VFIO_DEVICE_QUERY_GFX_PLANE doesn't work due to the guest not having
the device initialized yet.

Maybe we should have a error field in the ioctl struct, or we need to
clearly define error codes so the kernel doesn't just throw EINVAL in
all cases.

Or just a VFIO_DEVICE_GFX_CAPS ioctl which returns NONE, REGION or
DMABUF.

cheers,
  Gerd

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

  reply	other threads:[~2017-06-20  8:34 UTC|newest]

Thread overview: 105+ 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   ` [Intel-gfx] " Ville Syrjälä
2017-06-15 10:21     ` Ville Syrjälä
2017-06-20  9:01     ` [Intel-gfx] " Zhang, Tina
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 [this message]
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               ` [Intel-gfx] " Zhang, Tina
2017-06-20  8:41                 ` Zhang, Tina
2017-06-20 10:57                 ` [Intel-gfx] " Gerd Hoffmann
2017-06-20 10:57                   ` Gerd Hoffmann
2017-06-20 15:00                   ` [Intel-gfx] " Alex Williamson
2017-06-20 15:00                     ` Alex Williamson
2017-06-20 17:07                     ` Kirti Wankhede
2017-06-20 17:07                       ` Kirti Wankhede
2017-06-20 23:01                     ` [Intel-gfx] " Zhang, Tina
2017-06-20 23:01                       ` Zhang, Tina
2017-06-20 23:22                       ` [Intel-gfx] " Alex Williamson
2017-06-20 23:22                         ` Alex Williamson
2017-06-21  9:20                         ` [Intel-gfx] " Zhang, Tina
2017-06-21  9:20                           ` Zhang, Tina
2017-06-21 11:03                           ` [Intel-gfx] " Gerd Hoffmann
2017-06-21 11:03                             ` Gerd Hoffmann
2017-06-21 18:59                             ` Alex Williamson
2017-06-21 18:59                               ` Alex Williamson
2017-06-22  8:30                               ` Gerd Hoffmann
2017-06-22  8:30                                 ` Gerd Hoffmann
2017-06-22 18:54                                 ` [Intel-gfx] " Alex Williamson
2017-06-22 18:54                                   ` Alex Williamson
2017-06-23  7:26                                   ` [Intel-gfx] " Gerd Hoffmann
2017-06-23  7:26                                     ` Gerd Hoffmann
2017-06-23  7:49                                     ` [Intel-gfx] " Zhi Wang
2017-06-23  7:49                                       ` Zhi Wang
2017-06-23  8:31                                       ` Gerd Hoffmann
2017-06-23  8:31                                         ` Gerd Hoffmann
2017-06-23 16:40                                         ` Alex Williamson
2017-06-23 16:40                                           ` Alex Williamson
2017-06-23 17:15                                     ` [Intel-gfx] " Alex Williamson
2017-06-23 17:15                                       ` Alex Williamson
2017-06-26  6:17                                       ` [Intel-gfx] " Gerd Hoffmann
2017-06-26  6:17                                         ` Gerd Hoffmann
2017-06-22  0:21                             ` [Intel-gfx] " Zhang, Tina
2017-06-22  0:21                               ` Zhang, Tina
2017-06-21  7:34                     ` [Intel-gfx] " Gerd Hoffmann
2017-06-21  7:34                       ` Gerd Hoffmann
2017-06-23 21:58                   ` [Intel-gfx] " Zhang, Tina
2017-06-23 21:58                     ` Zhang, Tina
2017-06-26  6:39                     ` [Intel-gfx] " Gerd Hoffmann
2017-06-26  6:39                       ` Gerd Hoffmann
2017-06-26 17:28                       ` [Intel-gfx] " Alex Williamson
2017-06-26 17:28                         ` Alex Williamson
2017-06-27  6:12                         ` [Intel-gfx] " Gerd Hoffmann
2017-06-27  6:12                           ` Gerd Hoffmann
2017-06-28 12:48                           ` [Intel-gfx] " Zhang, Tina
2017-06-28 12:48                             ` Zhang, Tina
2017-06-29  6:41                             ` [Intel-gfx] " Gerd Hoffmann
2017-06-29  6:41                               ` Gerd Hoffmann
2017-06-29  8:39                               ` [Intel-gfx] " Daniel Vetter
2017-06-29  8:39                                 ` Daniel Vetter
2017-07-04  0:47                                 ` [Intel-gfx] " Zhang, Tina
2017-07-04  0:47                                   ` 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=1497947703.16795.4.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=kevin.tian@intel.com \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xiaoguang.chen@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.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.