From: Daniel Vetter <daniel@ffwll.ch>
To: Tina Zhang <tina.zhang@intel.com>
Cc: alex.williamson@redhat.com, kraxel@redhat.com,
chris@chris-wilson.co.uk, zhenyuw@linux.intel.com,
zhiyuan.lv@intel.com, zhi.a.wang@intel.com, kevin.tian@intel.com,
daniel@ffwll.ch, kwankhede@nvidia.com,
intel-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation
Date: Tue, 11 Jul 2017 11:15:59 +0200 [thread overview]
Message-ID: <20170711091559.2grfq3cb2kemmmvi@phenom.ffwll.local> (raw)
In-Reply-To: <1499293795-6265-1-git-send-email-tina.zhang@intel.com>
On Thu, Jul 06, 2017 at 06:29:55AM +0800, Tina Zhang wrote:
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
> get the plan and its related information.
>
> The dma-buf's life cycle is handled by user mode and tracked by kernel.
> The returned fd in struct vfio_device_query_gfx_plane can be a new
> fd or an old fd of a re-exported dma-buf. Host User mode can check the
> value of fd and to see if it need to creat new resource according to the
> new fd or just use the existed resource related to the old fd.
>
> Signed-off-by: Tina Zhang <tina.zhang@intel.com>
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index ae46105..c92bc69 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,6 +502,36 @@ struct vfio_pci_hot_reset {
>
> #define VFIO_DEVICE_PCI_HOT_RESET _IO(VFIO_TYPE, VFIO_BASE + 13)
>
> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + * struct vfio_device_query_gfx_plane)
> + * Return: 0 on success, -errno on failure.
> + */
> +
> +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;
> +};
Would be good to have a detailed spec of all this stuff, plus what's it
meant to be used for. I assume that e.g. start would be the opaque cookie
thing we've talked about, for dma-buf reuse? Otherwise I'm not sure what
it's good for, since the same gpu vram address can be reused for different
memory objects ...
> +
> +struct vfio_device_query_gfx_plane {
> + __u32 argsz;
> + __u32 flags;
> + struct vfio_device_gfx_plane_info plane_info;
> + __u32 plane_type;
> + __s32 fd; /* dma-buf fd */
> + __u32 plane_id;
> +};
As mentioned in the other reply already, I'm not sure what plane_type is
for. Otherwise this looks ok-ish, but hard to tell without more detailed
spec.
-Daniel
> +
> +#define VFIO_DEVICE_QUERY_GFX_PLANE _IO(VFIO_TYPE, VFIO_BASE + 14)
> +
> +
> /* -------- API for Type1 VFIO IOMMU -------- */
>
> /**
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2017-07-11 9:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-05 22:29 Tina Zhang
2017-07-06 14:01 ` Kirti Wankhede
2017-07-11 6:14 ` Gerd Hoffmann
2017-07-11 9:12 ` Daniel Vetter
2017-07-12 2:31 ` Zhang, Tina
2017-07-12 7:40 ` Daniel Vetter
2017-07-12 12:45 ` Kirti Wankhede
2017-07-14 1:30 ` Zhang, Tina
2017-07-14 10:12 ` Kirti Wankhede
2017-07-14 12:05 ` Gerd Hoffmann
2017-07-14 12:15 ` Kirti Wankhede
2017-07-17 11:03 ` Gerd Hoffmann
2017-07-19 0:16 ` Zhang, Tina
2017-07-19 6:25 ` Gerd Hoffmann
2017-07-19 11:52 ` Kirti Wankhede
2017-07-14 10:01 ` Gerd Hoffmann
2017-07-14 10:15 ` Kirti Wankhede
2017-07-14 12:01 ` Gerd Hoffmann
2017-07-12 3:17 ` Zhenyu Wang
2017-07-12 2:20 ` Zhang, Tina
2017-07-11 6:07 ` Gerd Hoffmann
2017-07-12 2:43 ` Zhang, Tina
2017-07-11 9:15 ` Daniel Vetter [this message]
2017-07-12 3:12 ` Zhang, Tina
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=20170711091559.2grfq3cb2kemmmvi@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--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=kraxel@redhat.com \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tina.zhang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®