Message-ID: <20170525132825.GO10827@nuc-i3427.alporthouse.com>
Date:   Thu, 25 May 2017 14:28:25 +0100
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Xiaoguang Chen <xiaoguang.chen@...el.com>
Cc:     alex.williamson@...hat.com, kraxel@...hat.com,
        intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        zhenyuw@...ux.intel.com, zhiyuan.lv@...el.com,
        intel-gvt-dev@...ts.freedesktop.org, zhi.a.wang@...el.com,
        kevin.tian@...el.com
Subject: Re: [Intel-gfx] [PATCH v5 4/5] drm/i915/gvt: Dmabuf support for GVT-g

On Tue, May 23, 2017 at 06:32:00PM +0800, Xiaoguang Chen wrote:
> dmabuf for GVT-g can be exported to users who can use the dmabuf to show
> the desktop of vm which use intel vgpu.
> 
> Currently we provide query and create new dmabuf operations.
> 
> Users of dmabuf can cache some created dmabufs and related information
> such as the framebuffer's address, size, tiling mode, width, height etc.
> When refresh the screen first query the currnet vgpu's frambuffer and
> compare with the cached ones(address, size, tiling, width, height etc)
> if found one then reuse the found dmabuf to gain performance improvment.
> 
> If there is no dmabuf created yet or not found in the cached dmabufs then
> need to create a new dmabuf. To create a dmabuf first a gem object will
> be created and the backing storage of this gem object is the vgpu's
> framebuffer(primary/cursor).
> Set caching mode, change tiling mode and set domains of this gem object
> is not supported.
> Then associate this gem object to a dmabuf and export this dmabuf.
> A file descriptor will be generated for this dmabuf and this file
> descriptor can be sent to user space to do display.
> 
> Signed-off-by: Xiaoguang Chen <xiaoguang.chen@...el.com>
> ---
>  drivers/gpu/drm/i915/gvt/Makefile      |   2 +-
>  drivers/gpu/drm/i915/gvt/dmabuf.c      | 276 +++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/gvt/dmabuf.h      |  53 +++++++
>  drivers/gpu/drm/i915/gvt/gvt.h         |   1 +
>  drivers/gpu/drm/i915/i915_gem.c        |   8 +
>  drivers/gpu/drm/i915/i915_gem_object.h |   9 ++
>  6 files changed, 348 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
> 
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile
> index 192ca26..e480f7d 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -2,7 +2,7 @@ GVT_DIR := gvt
>  GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
>  	interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
>  	execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
> -	fb_decoder.o
> +	fb_decoder.o dmabuf.o
>  
>  ccflags-y				+= -I$(src) -I$(src)/$(GVT_DIR) -Wall
>  i915-y					+= $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c
> new file mode 100644
> index 0000000..415453b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -0,0 +1,276 @@
> +/*
> + * Copyright 2017 Intel Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + *    Zhiyuan Lv <zhiyuan.lv@...el.com>
> + *
> + * Contributors:
> + *    Xiaoguang Chen <xiaoguang.chen@...el.com>
> + */
> +
> +#include <linux/dma-buf.h>
> +#include <drm/drmP.h>
> +
> +#include "i915_drv.h"
> +#include "gvt.h"
> +
> +#define GEN8_DECODE_PTE(pte) \
> +	((dma_addr_t)(((((u64)pte) >> 12) & 0x7ffffffULL) << 12))

pte & GENMASK_ULL(63, 12)

> +
> +static struct sg_table *intel_vgpu_gem_get_pages(
> +		struct drm_i915_gem_object *obj)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> +	struct sg_table *st;
> +	struct scatterlist *sg;
> +	int i, ret;
> +	gen8_pte_t __iomem *gtt_entries;
> +	unsigned int fb_gma = 0, fb_size = 0;
> +	struct intel_vgpu_plane_info *plane_info;
> +
> +	plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
> +	if (WARN_ON(!plane_info))
> +		return ERR_PTR(-EINVAL);

This is an internal bug, don't EINVAL.

> +	fb_gma = plane_info->start;
> +	fb_size = plane_info->size;
> +
> +	st = kmalloc(sizeof(*st), GFP_KERNEL);
> +	if (!st) {
> +		ret = -ENOMEM;
> +		return ERR_PTR(ret);
> +	}
> +
> +	ret = sg_alloc_table(st, fb_size, GFP_KERNEL);
> +	if (ret) {
> +		kfree(st);
> +		return ERR_PTR(ret);
> +	}
> +	gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
> +		(fb_gma >> PAGE_SHIFT);
> +	for_each_sg(st->sgl, sg, fb_size, i) {
> +		sg->offset = 0;
> +		sg->length = PAGE_SIZE;
> +		sg_dma_address(sg) =
> +			GEN8_DECODE_PTE(readq(&gtt_entries[i]));
> +		sg_dma_len(sg) = PAGE_SIZE;

This assumes that the entries are PAGE_SIZE. This will not remain true.
Also sg coalescing?

> +	}
> +
> +	return st;
> +}
> +
> +static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
> +		struct sg_table *pages)
> +{
> +	struct intel_vgpu_plane_info *plane_info;
> +
> +	plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
> +	if (WARN_ON(!plane_info))
> +		return;

Is there any value in this check?

> +	sg_free_table(pages);
> +	kfree(pages);
> +}
> +
> +static const struct drm_i915_gem_object_ops intel_vgpu_gem_ops = {
> +	.flags = I915_GEM_OBJECT_IS_GVT_DMABUF,

I'm going to suggest to call this bit I915_GEM_OBJECT_IS_PROXY to
generalise it beyond this special case. But I'm still debating how much
I approve of this change to the uABI.

> +	.get_pages = intel_vgpu_gem_get_pages,
> +	.put_pages = intel_vgpu_gem_put_pages,
> +};
> +
> +static struct drm_i915_gem_object *intel_vgpu_create_gem(struct drm_device *dev,
> +		struct intel_vgpu_plane_info *info)
> +{
> +	struct drm_i915_private *pri = dev->dev_private;

to_i915(dev);

Please tell me that pri isn't common shorthand in gvt/! Commonly called
dev_priv, but I'm crusading for i915.

> +	struct drm_i915_gem_object *obj;
> +
> +	obj = i915_gem_object_alloc(pri);
> +	if (obj == NULL)
> +		return NULL;
> +
> +	drm_gem_private_object_init(dev, &obj->base,
> +		info->size << PAGE_SHIFT);
> +	i915_gem_object_init(obj, &intel_vgpu_gem_ops);
> +
> +	obj->base.read_domains = I915_GEM_DOMAIN_GTT;
> +	obj->base.write_domain = 0;


> +	obj->framebuffer_references++;

Missing comment. (And not amused with the magic, if it's only purpose is
to prevent set_tiling.)

> +	obj->gvt_plane_info = info;
> +
> +	if (IS_SKYLAKE(pri)) {
> +		unsigned int tiling_mode = 0;
> +
> +		switch (info->drm_format_mod << 10) {
> +		case PLANE_CTL_TILED_LINEAR:
> +			tiling_mode = I915_TILING_NONE;
> +			break;
> +		case PLANE_CTL_TILED_X:
> +			tiling_mode = I915_TILING_X;
> +			break;
> +		case PLANE_CTL_TILED_Y:
> +			tiling_mode = I915_TILING_Y;
> +			break;
> +		default:
> +			gvt_dbg_core("not supported tiling mode\n");
> +		}
> +		obj->tiling_and_stride = tiling_mode | info->stride;

Stride should be zero if I915_TILING_NONE;

> +	} else {
> +		obj->tiling_and_stride = info->drm_format_mod ?
> +					I915_TILING_X : 0;
> +	}
> +
> +	return obj;
> +}
> +
> +static struct intel_vgpu_plane_info *intel_vgpu_get_plane_info(
> +		struct drm_device *dev,
> +		struct intel_vgpu *vgpu, uint32_t plane_id)
> +{
> +	struct drm_i915_private *dev_priv = dev->dev_private;

dev_priv here! Still use to_i915() though.

> +	struct intel_vgpu_primary_plane_format *p;
> +	struct intel_vgpu_cursor_plane_format *c;
> +	struct intel_vgpu_plane_info *info;
> +	struct intel_vgpu_pipe_format *pipe;
> +
> +	info = kmalloc(sizeof(*info), GFP_KERNEL);
> +	if (!info)
> +		return NULL;
> +
> +	pipe = intel_vgpu_decode_plane(dev, vgpu);
> +	if (pipe == NULL)
> +		return NULL;

Onion unwind to kill the leaks as others have mentioned.

> +int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args)
> +{
> +	struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
> +	struct intel_vgpu_plane_info *info = args;
> +
> +	info = intel_vgpu_get_plane_info(dev, vgpu, info->plane_id);
> +	if (info == NULL)
> +		return -EINVAL;
> +
> +	return 0;
> +}
> +
> +int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu, void *args)
> +{
> +	struct dma_buf *dmabuf;
> +	struct drm_i915_gem_object *obj;
> +	struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
> +	struct intel_vgpu_dmabuf *gvt_dmabuf = args;
> +	struct intel_vgpu_plane_info *info;
> +	int ret;
> +
> +	info = intel_vgpu_get_plane_info(dev, vgpu,
> +					gvt_dmabuf->plane_info.plane_id);
> +	if (info == NULL)
> +		return -EINVAL;
> +
> +	obj = intel_vgpu_create_gem(dev, info);
> +	if (obj == NULL) {
> +		gvt_vgpu_err("create gvt gem obj failed:%d\n", vgpu->id);
> +		return -EINVAL;

Of all the errors that can cause this, do you think the user is at fault?

> +	}
> +
> +	dmabuf = i915_gem_prime_export(dev, &obj->base, DRM_CLOEXEC | DRM_RDWR);
> +
> +	if (IS_ERR(dmabuf)) {
> +		gvt_vgpu_err("export dma-buf failed\n");
> +		return -EINVAL;

Again, was this a user error? You even have the right error to hand!

> +	}
> +
> +	ret = dma_buf_fd(dmabuf, DRM_CLOEXEC | DRM_RDWR);
> +	if (ret < 0) {
> +		gvt_vgpu_err("create dma-buf fd failed ret:%d\n", ret);
> +		return -EINVAL;

Sitll a user error? Not ret?

> +	}
> +	gvt_dmabuf->fd = ret;
> +	gvt_dmabuf->plane_info = *info;
> +
> +	return 0;
> +}

> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index c42266c..763a8c5 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -47,6 +47,7 @@
>  #include "render.h"
>  #include "cmd_parser.h"
>  #include "fb_decoder.h"
> +#include "dmabuf.h"
>  
>  #define GVT_MAX_VGPU 8
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0c1cbe9..54f7a0f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1609,6 +1609,10 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
>  	if (!obj)
>  		return -ENOENT;
>  
> +	/* The obj is a gvt dma-buf object and set domain is not supported */
> +	if (i915_gem_object_is_gvt_dmabuf(obj))
> +		return -EPERM;

Leaks the obj.

Ok, I'm slightly warming to this.

Newly broken ioctls:
	i915_gem_set_caching_ioctl
	i915_gem_set_domain_ioctl
	i915_gem_sw_finish_ioctl
	i915_gem_set_tiling_ioctl
	i915_gem_madvise_ioctl

These should all be -EPERM.

Existing broken ioctls:
	i915_gem_mmap_ioctl

Sadly this used -EINVAL. Might sneak a change in to use -EPERM for
constistency.

Misbehaving ioctls:
	i915_gem_busy_ioctl
	i915_gem_throttle_ioctl
	i915_gem_wait_ioctl

These only work on the proxy bo and do not reflect the real object.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Powered by blists - more mailing lists