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: Tue, 20 Jun 2017 12:57:36 +0200 [thread overview]
Message-ID: <1497956256.16795.7.camel@redhat.com> (raw)
In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C56EBE0@SHSMSX101.ccr.corp.intel.com>
On Tue, 2017-06-20 at 08:41 +0000, Zhang, Tina wrote:
> Hi,
>
> Thanks for all the comments. Here are the summaries:
>
> 1. Modify the structures to make it more general.
> struct vfio_device_gfx_plane_info {
> __u64 start;
> __u64 drm_format_mod;
> __u32 drm_format;
> __u32 width;
> __u32 height;
> __u32 stride;
> __u32 size;
> __u32 x_pos;
> __u32 y_pos;
> __u32 generation;
> };
Looks good to me.
> struct vfio_device_query_gfx_plane {
> __u32 argsz;
> __u32 flags;
> #define VFIO_GFX_PLANE_FLAGS_REGION_ID (1 << 0)
> #define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1)
> struct vfio_device_gfx_plane_info plane_info;
> __u32 id;
> };
I'm not convinced the flags are a great idea. Whenever dmabufs or a
region is used is a static property of the device, not of each
individual plane.
I think we should have this for userspace to figure:
enum vfio_device_gfx_type {
VFIO_DEVICE_GFX_NONE,
VFIO_DEVICE_GFX_DMABUF,
VFIO_DEVICE_GFX_REGION,
};
struct vfio_device_gfx_query_caps {
__u32 argsz;
__u32 flags;
enum vfio_device_gfx_type;
};
Then this to query the plane:
struct vfio_device_gfx_query_plane {
__u32 argsz;
__u32 flags;
struct vfio_device_gfx_plane_info plane_info; /* out */
__u32 plane_type; /* in */
};
2. Remove dmabuf mgr fd and add these two ioctl commands to the vfio
device fd.
> VFIO_DEVICE_QUERY_GFX_PLANE : used to query
> vfio_device_gfx_plane_info.
Yes.
> VFIO_DEVICE_GET_DMABUF_FD: used to create and return the dmabuf fd.
Yes. The plane might have changed between query-plane and get-dmabuf
ioctl calls though, we must make sure we handle that somehow. Current
patches return plane_info on get-dmabuf ioctl too, so userspace can see
what it actually got.
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.
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: Tue, 20 Jun 2017 12:57:36 +0200 [thread overview]
Message-ID: <1497956256.16795.7.camel@redhat.com> (raw)
In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C56EBE0@SHSMSX101.ccr.corp.intel.com>
On Tue, 2017-06-20 at 08:41 +0000, Zhang, Tina wrote:
> Hi,
>
> Thanks for all the comments. Here are the summaries:
>
> 1. Modify the structures to make it more general.
> struct vfio_device_gfx_plane_info {
> __u64 start;
> __u64 drm_format_mod;
> __u32 drm_format;
> __u32 width;
> __u32 height;
> __u32 stride;
> __u32 size;
> __u32 x_pos;
> __u32 y_pos;
> __u32 generation;
> };
Looks good to me.
> struct vfio_device_query_gfx_plane {
> __u32 argsz;
> __u32 flags;
> #define VFIO_GFX_PLANE_FLAGS_REGION_ID (1 << 0)
> #define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1)
> struct vfio_device_gfx_plane_info plane_info;
> __u32 id;
> };
I'm not convinced the flags are a great idea. Whenever dmabufs or a
region is used is a static property of the device, not of each
individual plane.
I think we should have this for userspace to figure:
enum vfio_device_gfx_type {
VFIO_DEVICE_GFX_NONE,
VFIO_DEVICE_GFX_DMABUF,
VFIO_DEVICE_GFX_REGION,
};
struct vfio_device_gfx_query_caps {
__u32 argsz;
__u32 flags;
enum vfio_device_gfx_type;
};
Then this to query the plane:
struct vfio_device_gfx_query_plane {
__u32 argsz;
__u32 flags;
struct vfio_device_gfx_plane_info plane_info; /* out */
__u32 plane_type; /* in */
};
2. Remove dmabuf mgr fd and add these two ioctl commands to the vfio
device fd.
> VFIO_DEVICE_QUERY_GFX_PLANE : used to query
> vfio_device_gfx_plane_info.
Yes.
> VFIO_DEVICE_GET_DMABUF_FD: used to create and return the dmabuf fd.
Yes. The plane might have changed between query-plane and get-dmabuf
ioctl calls though, we must make sure we handle that somehow. Current
patches return plane_info on get-dmabuf ioctl too, so userspace can see
what it actually got.
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.
cheers,
Gerd
next prev parent reply other threads:[~2017-06-20 10:57 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 [this message]
2017-06-20 10:57 ` 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
2017-06-26 6:39 ` [Intel-gfx] " 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=1497956256.16795.7.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.