Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1651811 > unrolled thread

[PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g

Started byXiaoguang Chen <xiaoguang.chen@intel.com>
First post2017-05-27 10:50 +0200
Last post2017-05-31 11:10 +0200
Articles 20 on this page of 25 — 7 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g Xiaoguang Chen <xiaoguang.chen@intel.com> - 2017-05-27 10:50 +0200
    [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g Xiaoguang Chen <xiaoguang.chen@intel.com> - 2017-05-27 10:50 +0200
      Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g Zhenyu Wang <zhenyuw@linux.intel.com> - 2017-05-31 07:00 +0200
        RE: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-31 08:30 +0200
          Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g Zhenyu Wang <zhenyuw@linux.intel.com> - 2017-05-31 08:40 +0200
            RE: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-31 08:50 +0200
    [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g Xiaoguang Chen <xiaoguang.chen@intel.com> - 2017-05-27 10:50 +0200
      Re: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g Gerd Hoffmann <kraxel@redhat.com> - 2017-05-31 14:10 +0200
        RE: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-06-01 05:10 +0200
      Re: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g Chris Wilson <chris@chris-wilson.co.uk> - 2017-06-01 11:20 +0200
    [PATCH v6 1/6] drm/i915/gvt: Extend the GVT-g architecture to support vfio device region Xiaoguang Chen <xiaoguang.chen@intel.com> - 2017-05-27 10:50 +0200
    [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations Xiaoguang Chen <xiaoguang.chen@intel.com> - 2017-05-27 10:50 +0200
      Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations Gerd Hoffmann <kraxel@redhat.com> - 2017-05-29 09:30 +0200
        RE: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-31 08:20 +0200
          Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations Kirti Wankhede <kwankhede@nvidia.com> - 2017-05-31 19:30 +0200
            RE: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-06-01 05:10 +0200
              Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf  operations Alex Williamson <alex.williamson@redhat.com> - 2017-06-01 18:40 +0200
                Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations Kirti Wankhede <kwankhede@nvidia.com> - 2017-06-01 20:50 +0200
                  Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations Gerd Hoffmann <kraxel@redhat.com> - 2017-06-02 10:40 +0200
                    Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations Kirti Wankhede <kwankhede@nvidia.com> - 2017-06-05 10:30 +0200
                      Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations Gerd Hoffmann <kraxel@redhat.com> - 2017-06-06 10:00 +0200
    Re: [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g Gerd Hoffmann <kraxel@redhat.com> - 2017-05-30 12:30 +0200
      RE: [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-31 04:30 +0200
        Re: [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g Gerd Hoffmann <kraxel@redhat.com> - 2017-05-31 11:00 +0200
          RE: [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g "Chen, Xiaoguang" <xiaoguang.chen@intel.com> - 2017-05-31 11:10 +0200

Page 1 of 2  [1] 2  Next page →


#1651811 — [PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g

FromXiaoguang Chen <xiaoguang.chen@intel.com>
Date2017-05-27 10:50 +0200
Subject[PATCH v6 0/6] drm/i915/gvt: Dma-buf support for GVT-g
Message-ID<tLFA5-QN-3@gated-at.bofh.it>
v5->v6:
1) align the dma-buf life cycle with the vfio device.
2) add the dma-buf releated operations in a separate patch.
3) i915 releated changes.

v4->v5:
1) fix bug while checking whether the gem obj is gvt's dma-buf when user
change caching mode or domains. Add a helper function to do it.
2) add definition for the query plane and create dma-buf.

v3->v4:
1) fix bug while checking whether the gem obj is gvt's dma-buf when set
caching mode or doamins.

v2->v3:
1) add a field gvt_plane_info in the drm_i915_gem_obj structure to save
the decoded plane information to avoid look up while need the plane info.
2) declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object
to represent the gem obj for gvt's dma-buf. The tiling mode, caching mode
and domains can not be changed for this kind of gem object.
3) change dma-buf related information to be more generic. So other vendor
can use the same interface.

v1->v2:
1) create a management fd for dma-buf operations.
2) alloc gem object's backing storage in gem obj's get_pages() callback.

This patch set adds the dma-buf support for intel GVT-g.
dma-buf is a uniform mechanism to share DMA buffers across different
devices and sub-systems.
dma-buf for intel GVT-g is mainly used to share the vgpu's framebuffer
to other users or sub-systems so they can use the dma-buf to show the
desktop of a vm which uses intel vgpu.

The main idea is we create a gem object and set vgpu's framebuffer as
the backing storage of this gem object. And associate this gem obj
to a dma-buf object then export this dma-buf at the meantime
generate a file descriptor for this dma-buf. Finally deliver this file
descriptor to user space. And user can use this dma-buf fd to do render
or other operations.
User need to create a fd(for intel GVT-g dma-buf support it is a:dma-buf
management fd) then user can use this fd to query the plane information
or create a dma-buf. The life cycle of this fd is managed by GVT-g user
do not need to care about that.

We have an example program on how to use the dma-buf. You can download
the program to have a try. Good luck :)
git repo: https://github.com/01org/igvtg-qemu branch:kvmgt_dmabuf_example

Xiaoguang Chen (6):
  drm/i915/gvt: Extend the GVT-g architecture to support vfio device
    region
  drm/i915/gvt: OpRegion support for GVT-g
  drm/i915/gvt: Frame buffer decoder support for GVT-g
  vfio: Define vfio based vgpu's dma-buf operations
  drm/i915/gvt: Dmabuf support for GVT-g
  drm/i915/gvt: Adding interface so user space can get the dma-buf

 drivers/gpu/drm/i915/gvt/Makefile      |   3 +-
 drivers/gpu/drm/i915/gvt/display.c     |   2 +-
 drivers/gpu/drm/i915/gvt/display.h     |   2 +
 drivers/gpu/drm/i915/gvt/dmabuf.c      | 281 +++++++++++++++++++
 drivers/gpu/drm/i915/gvt/dmabuf.h      |  42 +++
 drivers/gpu/drm/i915/gvt/fb_decoder.c  | 479 +++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/gvt/fb_decoder.h  | 166 ++++++++++++
 drivers/gpu/drm/i915/gvt/gvt.c         |   2 +
 drivers/gpu/drm/i915/gvt/gvt.h         |   7 +
 drivers/gpu/drm/i915/gvt/kvmgt.c       | 262 +++++++++++++++++-
 drivers/gpu/drm/i915/gvt/opregion.c    |   8 +-
 drivers/gpu/drm/i915/gvt/vgpu.c        |   1 +
 drivers/gpu/drm/i915/i915_gem.c        |  26 +-
 drivers/gpu/drm/i915/i915_gem_object.h |   9 +
 include/uapi/linux/vfio.h              |  50 ++++
 15 files changed, 1333 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
 create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
 create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h

-- 
2.7.4

[toc] | [next] | [standalone]


#1651813 — [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

FromXiaoguang Chen <xiaoguang.chen@intel.com>
Date2017-05-27 10:50 +0200
Subject[PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g
Message-ID<tLFA6-QN-15@gated-at.bofh.it>
In reply to#1651811
OpRegion is needed to support display related operation for
intel vgpu.

A vfio device region is added to intel vgpu to deliver the
host OpRegion information to user space so user space can
construct the OpRegion for vgpu.

Signed-off-by: Bing Niu <bing.niu@intel.com>
Signed-off-by: Xiaoguang Chen <xiaoguang.chen@intel.com>
---
 drivers/gpu/drm/i915/gvt/kvmgt.c    | 97 +++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/gvt/opregion.c |  8 ++-
 2 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3c6a02b..389f072 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,6 +53,8 @@ static const struct intel_gvt_ops *intel_gvt_ops;
 #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
 #define VFIO_PCI_OFFSET_MASK    (((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
 
+#define OPREGION_SIGNATURE "IntelGraphicsMem"
+
 struct vfio_region;
 struct intel_vgpu_regops {
 	size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
@@ -436,6 +438,92 @@ static void kvmgt_protect_table_del(struct kvmgt_guest_info *info,
 	}
 }
 
+static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char *buf,
+		size_t count, loff_t *ppos, bool iswrite)
+{
+	unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
+			VFIO_PCI_NUM_REGIONS;
+	void *base = vgpu->vdev.region[i].data;
+	loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
+
+	if (pos >= vgpu->vdev.region[i].size || iswrite) {
+		gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
+		return -EINVAL;
+	}
+	count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
+	memcpy(buf, base + pos, count);
+
+	return count;
+}
+
+static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
+		struct vfio_region *region)
+{
+	memunmap(region->data);
+}
+
+static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
+	.rw = intel_vgpu_reg_rw_opregion,
+	.release = intel_vgpu_reg_release_opregion,
+};
+
+static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
+		unsigned int type, unsigned int subtype,
+		const struct intel_vgpu_regops *ops,
+		size_t size, u32 flags, void *data)
+{
+	struct vfio_region *region;
+
+	region = krealloc(vgpu->vdev.region,
+			(vgpu->vdev.num_regions + 1) * sizeof(*region),
+			GFP_KERNEL);
+	if (!region)
+		return -ENOMEM;
+
+	vgpu->vdev.region = region;
+	vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
+	vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
+	vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
+	vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
+	vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
+	vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
+	vgpu->vdev.num_regions++;
+
+	return 0;
+}
+
+static int intel_vgpu_reg_init_opregion(struct intel_vgpu *vgpu)
+{
+	unsigned int addr;
+	void *base;
+	int ret;
+
+	addr = vgpu->gvt->opregion.opregion_pa;
+	if (!addr || !(~addr))
+		return -ENODEV;
+
+	base = memremap(addr, OPREGION_SIZE, MEMREMAP_WB);
+	if (!base)
+		return -ENOMEM;
+
+	if (memcmp(base, OPREGION_SIGNATURE, 16)) {
+		memunmap(base);
+		return -EINVAL;
+	}
+
+	ret = intel_vgpu_register_reg(vgpu,
+			PCI_VENDOR_ID_INTEL | VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
+			VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION,
+			&intel_vgpu_regops_opregion, OPREGION_SIZE,
+			VFIO_REGION_INFO_FLAG_READ, base);
+	if (ret) {
+		memunmap(base);
+		return ret;
+	}
+
+	return ret;
+}
+
 static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
 {
 	struct intel_vgpu *vgpu = NULL;
@@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
 	vgpu->vdev.mdev = mdev;
 	mdev_set_drvdata(mdev, vgpu);
 
+	ret = intel_vgpu_reg_init_opregion(vgpu);
+	if (ret) {
+		gvt_vgpu_err("create OpRegion failed\n");
+		goto out;
+	}
+
+	gvt_dbg_core("create OpRegion succeeded for mdev:%s\n",
+			dev_name(mdev_dev(mdev)));
+
 	gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
 		     dev_name(mdev_dev(mdev)));
 	ret = 0;
diff --git a/drivers/gpu/drm/i915/gvt/opregion.c b/drivers/gpu/drm/i915/gvt/opregion.c
index 3117991..5c7496d 100644
--- a/drivers/gpu/drm/i915/gvt/opregion.c
+++ b/drivers/gpu/drm/i915/gvt/opregion.c
@@ -114,6 +114,7 @@ void intel_vgpu_clean_opregion(struct intel_vgpu *vgpu)
 int intel_vgpu_init_opregion(struct intel_vgpu *vgpu, u32 gpa)
 {
 	int ret;
+	unsigned long pfn;
 
 	gvt_dbg_core("vgpu%d: init vgpu opregion\n", vgpu->id);
 
@@ -127,7 +128,12 @@ int intel_vgpu_init_opregion(struct intel_vgpu *vgpu, u32 gpa)
 		ret = map_vgpu_opregion(vgpu, true);
 		if (ret)
 			return ret;
-	}
+	} else {
+		pfn = intel_gvt_hypervisor_gfn_to_mfn(vgpu, gpa >> PAGE_SHIFT);
+		vgpu_opregion(vgpu)->va = memremap(pfn << PAGE_SHIFT,
+						INTEL_GVT_OPREGION_SIZE,
+						MEMREMAP_WB);
+		}
 
 	return 0;
 }
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]


#1653832 — Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

FromZhenyu Wang <zhenyuw@linux.intel.com>
Date2017-05-31 07:00 +0200
SubjectRe: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g
Message-ID<tN3TH-6e-3@gated-at.bofh.it>
In reply to#1651813

[Multipart message — attachments visible in raw view] — view raw

On 2017.05.27 16:38:48 +0800, Xiaoguang Chen wrote:
> OpRegion is needed to support display related operation for
> intel vgpu.
> 
> A vfio device region is added to intel vgpu to deliver the
> host OpRegion information to user space so user space can
> construct the OpRegion for vgpu.
> 
> Signed-off-by: Bing Niu <bing.niu@intel.com>
> Signed-off-by: Xiaoguang Chen <xiaoguang.chen@intel.com>
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c    | 97 +++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/gvt/opregion.c |  8 ++-
>  2 files changed, 104 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 3c6a02b..389f072 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -53,6 +53,8 @@ static const struct intel_gvt_ops *intel_gvt_ops;
>  #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
>  #define VFIO_PCI_OFFSET_MASK    (((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
>  
> +#define OPREGION_SIGNATURE "IntelGraphicsMem"
> +
>  struct vfio_region;
>  struct intel_vgpu_regops {
>  	size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
> @@ -436,6 +438,92 @@ static void kvmgt_protect_table_del(struct kvmgt_guest_info *info,
>  	}
>  }
>  
> +static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char *buf,
> +		size_t count, loff_t *ppos, bool iswrite)
> +{
> +	unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
> +			VFIO_PCI_NUM_REGIONS;
> +	void *base = vgpu->vdev.region[i].data;
> +	loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
> +
> +	if (pos >= vgpu->vdev.region[i].size || iswrite) {
> +		gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
> +		return -EINVAL;
> +	}
> +	count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
> +	memcpy(buf, base + pos, count);
> +
> +	return count;
> +}
> +
> +static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
> +		struct vfio_region *region)
> +{
> +	memunmap(region->data);
> +}
> +
> +static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
> +	.rw = intel_vgpu_reg_rw_opregion,
> +	.release = intel_vgpu_reg_release_opregion,
> +};
> +
> +static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
> +		unsigned int type, unsigned int subtype,
> +		const struct intel_vgpu_regops *ops,
> +		size_t size, u32 flags, void *data)
> +{
> +	struct vfio_region *region;
> +
> +	region = krealloc(vgpu->vdev.region,
> +			(vgpu->vdev.num_regions + 1) * sizeof(*region),
> +			GFP_KERNEL);
> +	if (!region)
> +		return -ENOMEM;
> +
> +	vgpu->vdev.region = region;
> +	vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
> +	vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
> +	vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
> +	vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
> +	vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
> +	vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
> +	vgpu->vdev.num_regions++;
> +
> +	return 0;
> +}
> +
> +static int intel_vgpu_reg_init_opregion(struct intel_vgpu *vgpu)
> +{
> +	unsigned int addr;
> +	void *base;
> +	int ret;
> +
> +	addr = vgpu->gvt->opregion.opregion_pa;
> +	if (!addr || !(~addr))
> +		return -ENODEV;
> +
> +	base = memremap(addr, OPREGION_SIZE, MEMREMAP_WB);
> +	if (!base)
> +		return -ENOMEM;
> +
> +	if (memcmp(base, OPREGION_SIGNATURE, 16)) {
> +		memunmap(base);
> +		return -EINVAL;
> +	}
> +
> +	ret = intel_vgpu_register_reg(vgpu,
> +			PCI_VENDOR_ID_INTEL | VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
> +			VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION,
> +			&intel_vgpu_regops_opregion, OPREGION_SIZE,
> +			VFIO_REGION_INFO_FLAG_READ, base);
> +	if (ret) {
> +		memunmap(base);
> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
>  static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
>  {
>  	struct intel_vgpu *vgpu = NULL;
> @@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
>  	vgpu->vdev.mdev = mdev;
>  	mdev_set_drvdata(mdev, vgpu);
>  
> +	ret = intel_vgpu_reg_init_opregion(vgpu);
> +	if (ret) {
> +		gvt_vgpu_err("create OpRegion failed\n");
> +		goto out;
> +	}

Still need to handle error path for created vgpu.

> +
> +	gvt_dbg_core("create OpRegion succeeded for mdev:%s\n",
> +			dev_name(mdev_dev(mdev)));
> +
>  	gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
>  		     dev_name(mdev_dev(mdev)));
>  	ret = 0;
> diff --git a/drivers/gpu/drm/i915/gvt/opregion.c b/drivers/gpu/drm/i915/gvt/opregion.c
> index 3117991..5c7496d 100644
> --- a/drivers/gpu/drm/i915/gvt/opregion.c
> +++ b/drivers/gpu/drm/i915/gvt/opregion.c
> @@ -114,6 +114,7 @@ void intel_vgpu_clean_opregion(struct intel_vgpu *vgpu)
>  int intel_vgpu_init_opregion(struct intel_vgpu *vgpu, u32 gpa)
>  {
>  	int ret;
> +	unsigned long pfn;
>  
>  	gvt_dbg_core("vgpu%d: init vgpu opregion\n", vgpu->id);
>  
> @@ -127,7 +128,12 @@ int intel_vgpu_init_opregion(struct intel_vgpu *vgpu, u32 gpa)
>  		ret = map_vgpu_opregion(vgpu, true);
>  		if (ret)
>  			return ret;
> -	}
> +	} else {
> +		pfn = intel_gvt_hypervisor_gfn_to_mfn(vgpu, gpa >> PAGE_SHIFT);
> +		vgpu_opregion(vgpu)->va = memremap(pfn << PAGE_SHIFT,
> +						INTEL_GVT_OPREGION_SIZE,
> +						MEMREMAP_WB);
> +		}

better to use switch for explicit KVM case, and no return check?

>  
>  	return 0;
>  }
> -- 
> 2.7.4
> 

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[toc] | [prev] | [next] | [standalone]


#1653868 — RE: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

From"Chen, Xiaoguang" <xiaoguang.chen@intel.com>
Date2017-05-31 08:30 +0200
SubjectRE: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g
Message-ID<tN5iO-1a0-11@gated-at.bofh.it>
In reply to#1653832
Hi 

>-----Original Message-----
>From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On
>Behalf Of Zhenyu Wang
>Sent: Wednesday, May 31, 2017 12:47 PM
>To: Chen, Xiaoguang <xiaoguang.chen@intel.com>
>Cc: Tian, Kevin <kevin.tian@intel.com>; intel-gfx@lists.freedesktop.org; linux-
>kernel@vger.kernel.org; zhenyuw@linux.intel.com; chris@chris-wilson.co.uk;
>alex.williamson@redhat.com; kraxel@redhat.com; Niu, Bing
><bing.niu@intel.com>; intel-gvt-dev@lists.freedesktop.org; Wang, Zhi A
><zhi.a.wang@intel.com>; Lv, Zhiyuan <zhiyuan.lv@intel.com>
>Subject: Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g
>
>On 2017.05.27 16:38:48 +0800, Xiaoguang Chen wrote:
>> OpRegion is needed to support display related operation for intel
>> vgpu.
>>
>> A vfio device region is added to intel vgpu to deliver the host
>> OpRegion information to user space so user space can construct the
>> OpRegion for vgpu.
>>
>> Signed-off-by: Bing Niu <bing.niu@intel.com>
>> Signed-off-by: Xiaoguang Chen <xiaoguang.chen@intel.com>
>> ---
>>  drivers/gpu/drm/i915/gvt/kvmgt.c    | 97
>+++++++++++++++++++++++++++++++++++++
>>  drivers/gpu/drm/i915/gvt/opregion.c |  8 ++-
>>  2 files changed, 104 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> index 3c6a02b..389f072 100644
>> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> @@ -53,6 +53,8 @@ static const struct intel_gvt_ops *intel_gvt_ops;
>> #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) <<
>VFIO_PCI_OFFSET_SHIFT)
>>  #define VFIO_PCI_OFFSET_MASK    (((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
>>
>> +#define OPREGION_SIGNATURE "IntelGraphicsMem"
>> +
>>  struct vfio_region;
>>  struct intel_vgpu_regops {
>>  	size_t (*rw)(struct intel_vgpu *vgpu, char *buf, @@ -436,6 +438,92
>> @@ static void kvmgt_protect_table_del(struct kvmgt_guest_info *info,
>>  	}
>>  }
>>
>> +static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char *buf,
>> +		size_t count, loff_t *ppos, bool iswrite) {
>> +	unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
>> +			VFIO_PCI_NUM_REGIONS;
>> +	void *base = vgpu->vdev.region[i].data;
>> +	loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
>> +
>> +	if (pos >= vgpu->vdev.region[i].size || iswrite) {
>> +		gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
>> +		return -EINVAL;
>> +	}
>> +	count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
>> +	memcpy(buf, base + pos, count);
>> +
>> +	return count;
>> +}
>> +
>> +static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
>> +		struct vfio_region *region)
>> +{
>> +	memunmap(region->data);
>> +}
>> +
>> +static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
>> +	.rw = intel_vgpu_reg_rw_opregion,
>> +	.release = intel_vgpu_reg_release_opregion, };
>> +
>> +static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
>> +		unsigned int type, unsigned int subtype,
>> +		const struct intel_vgpu_regops *ops,
>> +		size_t size, u32 flags, void *data) {
>> +	struct vfio_region *region;
>> +
>> +	region = krealloc(vgpu->vdev.region,
>> +			(vgpu->vdev.num_regions + 1) * sizeof(*region),
>> +			GFP_KERNEL);
>> +	if (!region)
>> +		return -ENOMEM;
>> +
>> +	vgpu->vdev.region = region;
>> +	vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
>> +	vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
>> +	vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
>> +	vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
>> +	vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
>> +	vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
>> +	vgpu->vdev.num_regions++;
>> +
>> +	return 0;
>> +}
>> +
>> +static int intel_vgpu_reg_init_opregion(struct intel_vgpu *vgpu) {
>> +	unsigned int addr;
>> +	void *base;
>> +	int ret;
>> +
>> +	addr = vgpu->gvt->opregion.opregion_pa;
>> +	if (!addr || !(~addr))
>> +		return -ENODEV;
>> +
>> +	base = memremap(addr, OPREGION_SIZE, MEMREMAP_WB);
>> +	if (!base)
>> +		return -ENOMEM;
>> +
>> +	if (memcmp(base, OPREGION_SIGNATURE, 16)) {
>> +		memunmap(base);
>> +		return -EINVAL;
>> +	}
>> +
>> +	ret = intel_vgpu_register_reg(vgpu,
>> +			PCI_VENDOR_ID_INTEL |
>VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
>> +			VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION,
>> +			&intel_vgpu_regops_opregion, OPREGION_SIZE,
>> +			VFIO_REGION_INFO_FLAG_READ, base);
>> +	if (ret) {
>> +		memunmap(base);
>> +		return ret;
>> +	}
>> +
>> +	return ret;
>> +}
>> +
>>  static int intel_vgpu_create(struct kobject *kobj, struct mdev_device
>> *mdev)  {
>>  	struct intel_vgpu *vgpu = NULL;
>> @@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject *kobj,
>struct mdev_device *mdev)
>>  	vgpu->vdev.mdev = mdev;
>>  	mdev_set_drvdata(mdev, vgpu);
>>
>> +	ret = intel_vgpu_reg_init_opregion(vgpu);
>> +	if (ret) {
>> +		gvt_vgpu_err("create OpRegion failed\n");
>> +		goto out;
>> +	}
>
>Still need to handle error path for created vgpu.
Just checked the code, if initialize the opregion failed we should first release vfio/mdev releated work(maybe call intel_vgpu_release function)  and then destroy the vgpu. Will update in the next version.

>
>> +
>> +	gvt_dbg_core("create OpRegion succeeded for mdev:%s\n",
>> +			dev_name(mdev_dev(mdev)));
>> +
>>  	gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
>>  		     dev_name(mdev_dev(mdev)));
>>  	ret = 0;
>> diff --git a/drivers/gpu/drm/i915/gvt/opregion.c
>> b/drivers/gpu/drm/i915/gvt/opregion.c
>> index 3117991..5c7496d 100644
>> --- a/drivers/gpu/drm/i915/gvt/opregion.c
>> +++ b/drivers/gpu/drm/i915/gvt/opregion.c
>> @@ -114,6 +114,7 @@ void intel_vgpu_clean_opregion(struct intel_vgpu
>> *vgpu)  int intel_vgpu_init_opregion(struct intel_vgpu *vgpu, u32 gpa)
>> {
>>  	int ret;
>> +	unsigned long pfn;
>>
>>  	gvt_dbg_core("vgpu%d: init vgpu opregion\n", vgpu->id);
>>
>> @@ -127,7 +128,12 @@ int intel_vgpu_init_opregion(struct intel_vgpu *vgpu,
>u32 gpa)
>>  		ret = map_vgpu_opregion(vgpu, true);
>>  		if (ret)
>>  			return ret;
>> -	}
>> +	} else {
>> +		pfn = intel_gvt_hypervisor_gfn_to_mfn(vgpu, gpa >>
>PAGE_SHIFT);
>> +		vgpu_opregion(vgpu)->va = memremap(pfn << PAGE_SHIFT,
>> +						INTEL_GVT_OPREGION_SIZE,
>> +						MEMREMAP_WB);
>> +		}
>
>better to use switch for explicit KVM case, and no return check?
Will update and add NULL check.

Thanks for review.
>
>>
>>  	return 0;
>>  }
>> --
>> 2.7.4
>>
>
>--
>Open Source Technology Center, Intel ltd.
>
>$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[toc] | [prev] | [next] | [standalone]


#1653873 — Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

FromZhenyu Wang <zhenyuw@linux.intel.com>
Date2017-05-31 08:40 +0200
SubjectRe: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g
Message-ID<tN5st-1db-5@gated-at.bofh.it>
In reply to#1653868

[Multipart message — attachments visible in raw view] — view raw

On 2017.05.31 06:22:28 +0000, Chen, Xiaoguang wrote:
> >> @@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject *kobj,
> >struct mdev_device *mdev)
> >>  	vgpu->vdev.mdev = mdev;
> >>  	mdev_set_drvdata(mdev, vgpu);
> >>
> >> +	ret = intel_vgpu_reg_init_opregion(vgpu);
> >> +	if (ret) {
> >> +		gvt_vgpu_err("create OpRegion failed\n");
> >> +		goto out;
> >> +	}
> >
> >Still need to handle error path for created vgpu.
> Just checked the code, if initialize the opregion failed we should first release vfio/mdev releated work(maybe call intel_vgpu_release function)  and then destroy the vgpu. Will update in the next version.
> 

Better to init opregion inside of create vgpu and do proper error
handling there too.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[toc] | [prev] | [next] | [standalone]


#1653878 — RE: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

From"Chen, Xiaoguang" <xiaoguang.chen@intel.com>
Date2017-05-31 08:50 +0200
SubjectRE: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g
Message-ID<tN5C9-1gO-1@gated-at.bofh.it>
In reply to#1653873

>-----Original Message-----
>From: Zhenyu Wang [mailto:zhenyuw@linux.intel.com]
>Sent: Wednesday, May 31, 2017 2:30 PM
>To: Chen, Xiaoguang <xiaoguang.chen@intel.com>
>Cc: Tian, Kevin <kevin.tian@intel.com>; intel-gfx@lists.freedesktop.org; linux-
>kernel@vger.kernel.org; chris@chris-wilson.co.uk; alex.williamson@redhat.com;
>kraxel@redhat.com; Niu, Bing <bing.niu@intel.com>; intel-gvt-
>dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>; Lv, Zhiyuan
><zhiyuan.lv@intel.com>
>Subject: Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g
>
>On 2017.05.31 06:22:28 +0000, Chen, Xiaoguang wrote:
>> >> @@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject
>> >> *kobj,
>> >struct mdev_device *mdev)
>> >>  	vgpu->vdev.mdev = mdev;
>> >>  	mdev_set_drvdata(mdev, vgpu);
>> >>
>> >> +	ret = intel_vgpu_reg_init_opregion(vgpu);
>> >> +	if (ret) {
>> >> +		gvt_vgpu_err("create OpRegion failed\n");
>> >> +		goto out;
>> >> +	}
>> >
>> >Still need to handle error path for created vgpu.
>> Just checked the code, if initialize the opregion failed we should first release
>vfio/mdev releated work(maybe call intel_vgpu_release function)  and then
>destroy the vgpu. Will update in the next version.
>>
>
>Better to init opregion inside of create vgpu and do proper error handling there
>too.
Then we must add a new entry in intel_gvt_mpt interface something like "create_opregion".

>
>--
>Open Source Technology Center, Intel ltd.
>
>$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[toc] | [prev] | [next] | [standalone]


#1651814 — [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g

FromXiaoguang Chen <xiaoguang.chen@intel.com>
Date2017-05-27 10:50 +0200
Subject[PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g
Message-ID<tLFA6-QN-9@gated-at.bofh.it>
In reply to#1651811
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@intel.com>
---
 drivers/gpu/drm/i915/gvt/Makefile      |   2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c      | 269 +++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/gvt/dmabuf.h      |  37 +++++
 drivers/gpu/drm/i915/gvt/gvt.h         |   1 +
 drivers/gpu/drm/i915/i915_gem.c        |  26 +++-
 drivers/gpu/drm/i915/i915_gem_object.h |   9 ++
 6 files changed, 342 insertions(+), 2 deletions(-)
 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..c831e91
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -0,0 +1,269 @@
+/*
+ * 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@intel.com>
+ *
+ * Contributors:
+ *    Xiaoguang Chen <xiaoguang.chen@intel.com>
+ */
+
+#include <linux/dma-buf.h>
+#include <drm/drmP.h>
+#include <linux/vfio.h>
+
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define GEN8_DECODE_PTE(pte) (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;
+	struct intel_vgpu_fb_info *fb_info;
+
+	fb_info = (struct intel_vgpu_fb_info *)obj->gvt_info;
+	if (WARN_ON(!fb_info))
+		return ERR_PTR(-ENODEV);
+
+	st = kmalloc(sizeof(*st), GFP_KERNEL);
+	if (!st) {
+		ret = -ENOMEM;
+		return ERR_PTR(ret);
+	}
+
+	ret = sg_alloc_table(st, fb_info->fb_size, GFP_KERNEL);
+	if (ret) {
+		kfree(st);
+		return ERR_PTR(ret);
+	}
+	gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
+		(fb_info->fb_addr >> PAGE_SHIFT);
+	for_each_sg(st->sgl, sg, fb_info->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;
+	}
+
+	return st;
+}
+
+static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
+		struct sg_table *pages)
+{
+	sg_free_table(pages);
+	kfree(pages);
+}
+
+static const struct drm_i915_gem_object_ops intel_vgpu_gem_ops = {
+	.flags = I915_GEM_OBJECT_IS_PROXY,
+	.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 vfio_vgpu_plane_info *info)
+{
+	struct drm_i915_private *dev_priv = to_i915(dev);
+	struct drm_i915_gem_object *obj;
+
+	obj = i915_gem_object_alloc(dev_priv);
+	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;
+	/* Change tiling mode from user space is not supported to a GVT-g's
+	 * dma-buf gem object.
+	 * We increase the obj's framebuffer_references to disable this kind
+	 * of operation.
+	 */
+	obj->framebuffer_references++;
+	if (IS_SKYLAKE(dev_priv)) {
+		unsigned int tiling_mode = 0;
+		unsigned int stride = 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;
+			stride = info->stride;
+			break;
+		case PLANE_CTL_TILED_Y:
+			tiling_mode = I915_TILING_Y;
+			stride = info->stride;
+			break;
+		default:
+			gvt_dbg_core("not supported tiling mode\n");
+		}
+		obj->tiling_and_stride = tiling_mode | stride;
+	} else {
+		obj->tiling_and_stride = info->drm_format_mod ?
+					I915_TILING_X : 0;
+	}
+
+	return obj;
+}
+
+static int intel_vgpu_get_plane_info(struct drm_device *dev,
+		struct intel_vgpu *vgpu, struct vfio_vgpu_plane_info *info)
+{
+	struct drm_i915_private *dev_priv = to_i915(dev);
+	struct intel_vgpu_primary_plane_format *p;
+	struct intel_vgpu_cursor_plane_format *c;
+	struct intel_vgpu_pipe_format *pipe;
+	int plane_id = info->plane_id;
+
+	pipe = intel_vgpu_decode_plane(dev, vgpu);
+	if (pipe == NULL)
+		return -ENODEV;
+
+	if (plane_id == PLANE_PRIMARY) {
+		p = &pipe->primary;
+		if (p != NULL) {
+			info->start = p->base;
+			info->width = p->width;
+			info->height = p->height;
+			info->stride = p->stride;
+			info->drm_format = p->drm_format;
+			info->drm_format_mod = p->tiled;
+			info->size = (((p->stride * p->height * p->bpp) / 8) +
+					(PAGE_SIZE - 1)) >> PAGE_SHIFT;
+		} else {
+			gvt_vgpu_err("invalid primary plane\n");
+			return -EINVAL;
+		}
+	} else if (plane_id == PLANE_CURSOR) {
+		c = &pipe->cursor;
+		if (c != NULL) {
+			info->start = c->base;
+			info->width = c->width;
+			info->height = c->height;
+			info->stride = c->width * (c->bpp / 8);
+			info->drm_format = c->drm_format;
+			info->drm_format_mod = 0;
+			info->x_pos = c->x_pos;
+			info->y_pos = c->y_pos;
+			info->size = (((info->stride * c->height * c->bpp) / 8)
+					+ (PAGE_SIZE - 1)) >> PAGE_SHIFT;
+		} else {
+			gvt_vgpu_err("invalid cursor plane\n");
+			return -EINVAL;
+		}
+	} else {
+		gvt_vgpu_err("invalid plane id:%d\n", plane_id);
+		return -EINVAL;
+	}
+
+	if (info->size == 0) {
+		gvt_vgpu_err("fb size is zero\n");
+		return -EINVAL;
+	}
+
+	if (info->start & (PAGE_SIZE - 1)) {
+		gvt_vgpu_err("Not aligned fb address:0x%x\n", info->start);
+		return -EFAULT;
+	}
+	if (((info->start >> PAGE_SHIFT) + info->size) >
+		ggtt_total_entries(&dev_priv->ggtt)) {
+		gvt_vgpu_err("Invalid GTT offset or size\n");
+		return -EFAULT;
+	}
+
+	if (!intel_gvt_ggtt_validate_range(vgpu, info->start, info->size)) {
+		gvt_vgpu_err("invalid gma addr\n");
+		return -EFAULT;
+	}
+
+	return 0;
+}
+
+int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args)
+{
+	struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
+	struct vfio_vgpu_plane_info *info = args;
+
+	return intel_vgpu_get_plane_info(dev, vgpu, info);
+}
+
+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 vfio_vgpu_dmabuf_info *gvt_dmabuf = args;
+	struct intel_vgpu_fb_info *fb_info;
+	int ret;
+
+	ret = intel_vgpu_get_plane_info(dev, vgpu, &gvt_dmabuf->plane_info);
+	if (ret != 0)
+		return ret;
+
+	obj = intel_vgpu_create_gem(dev, &gvt_dmabuf->plane_info);
+	if (obj == NULL) {
+		gvt_vgpu_err("create gvt gem obj failed:%d\n", vgpu->id);
+		return -ENOMEM;
+	}
+	fb_info = kmalloc(sizeof(*fb_info), GFP_KERNEL);
+	if (!fb_info) {
+		i915_gem_object_put(obj);
+		gvt_vgpu_err("allocate intel vgpu fb info failed\n");
+		return -ENOMEM;
+	}
+	fb_info->fb_addr = gvt_dmabuf->plane_info.start;
+	fb_info->fb_size = gvt_dmabuf->plane_info.size;
+	fb_info->vgpu = vgpu;
+	obj->gvt_info = fb_info;
+
+	dmabuf = i915_gem_prime_export(dev, &obj->base, DRM_CLOEXEC | DRM_RDWR);
+
+	if (IS_ERR(dmabuf)) {
+		kfree(fb_info);
+		i915_gem_object_free(obj);
+		gvt_vgpu_err("export dma-buf failed\n");
+		return PTR_ERR(dmabuf);
+	}
+
+	ret = dma_buf_fd(dmabuf, DRM_CLOEXEC | DRM_RDWR);
+	if (ret < 0) {
+		kfree(fb_info);
+		i915_gem_object_free(obj);
+		gvt_vgpu_err("create dma-buf fd failed ret:%d\n", ret);
+		return ret;
+	}
+	gvt_dmabuf->fd = ret;
+
+	return 0;
+}
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h b/drivers/gpu/drm/i915/gvt/dmabuf.h
new file mode 100644
index 0000000..8be9979
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright(c) 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.
+ *
+ */
+
+#ifndef _GVT_DMABUF_H_
+#define _GVT_DMABUF_H_
+
+struct intel_vgpu_fb_info {
+	struct intel_vgpu *vgpu;
+	uint32_t fb_addr;
+	uint32_t fb_size;
+};
+
+int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args);
+int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu, void *args);
+
+#endif
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..14be3b0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1609,6 +1609,12 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 	if (!obj)
 		return -ENOENT;
 
+	/* proxy gem object does not support setting domain */
+	if (i915_gem_object_is_proxy(obj)) {
+		i915_gem_object_put(obj);
+		return -EPERM;
+	}
+
 	/* Try to flush the object off the GPU without holding the lock.
 	 * We will repeat the flush holding the lock in the normal manner
 	 * to catch cases where we are gazumped.
@@ -1677,6 +1683,12 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
 	if (!obj)
 		return -ENOENT;
 
+	/* proxy gem obj does not support this operation */
+	if (i915_gem_object_is_proxy(obj)) {
+		i915_gem_object_put(obj);
+		return -EPERM;
+	}
+
 	/* Pinned buffers may be scanout, so flush the cache */
 	i915_gem_object_flush_if_display(obj);
 	i915_gem_object_put(obj);
@@ -1727,7 +1739,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 	 */
 	if (!obj->base.filp) {
 		i915_gem_object_put(obj);
-		return -EINVAL;
+		return -EPERM;
 	}
 
 	addr = vm_mmap(obj->base.filp, 0, args->size,
@@ -3717,6 +3729,12 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
 	if (!obj)
 		return -ENOENT;
 
+	/* proxy gem obj does not support setting caching mode */
+	if (i915_gem_object_is_proxy(obj)) {
+		i915_gem_object_put(obj);
+		return -EPERM;
+	}
+
 	if (obj->cache_level == level)
 		goto out;
 
@@ -4168,6 +4186,12 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
 	if (!obj)
 		return -ENOENT;
 
+	/* proxy gem obj does not support changing backding storage */
+	if (i915_gem_object_is_proxy(obj)) {
+		i915_gem_object_put(obj);
+		return -EPERM;
+	}
+
 	err = mutex_lock_interruptible(&obj->mm.lock);
 	if (err)
 		goto out;
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h
index 174cf92..be18a43 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -39,6 +39,7 @@ struct drm_i915_gem_object_ops {
 	unsigned int flags;
 #define I915_GEM_OBJECT_HAS_STRUCT_PAGE 0x1
 #define I915_GEM_OBJECT_IS_SHRINKABLE   0x2
+#define I915_GEM_OBJECT_IS_PROXY	0x4
 
 	/* Interface between the GEM object and its backing storage.
 	 * get_pages() is called once prior to the use of the associated set
@@ -184,6 +185,8 @@ struct drm_i915_gem_object {
 		} userptr;
 
 		unsigned long scratch;
+
+		void *gvt_info;
 	};
 
 	/** for phys allocated objects */
@@ -286,6 +289,12 @@ i915_gem_object_is_shrinkable(const struct drm_i915_gem_object *obj)
 }
 
 static inline bool
+i915_gem_object_is_proxy(const struct drm_i915_gem_object *obj)
+{
+	return obj->ops->flags & I915_GEM_OBJECT_IS_PROXY;
+}
+
+static inline bool
 i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
 {
 	return obj->active_count;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]


#1654173 — Re: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g

FromGerd Hoffmann <kraxel@redhat.com>
Date2017-05-31 14:10 +0200
SubjectRe: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g
Message-ID<tNaBR-4zj-37@gated-at.bofh.it>
In reply to#1651814
On Sat, 2017-05-27 at 16:38 +0800, Xiaoguang Chen wrote:
> +       if (plane_id == PLANE_PRIMARY) {

Should be DRM_PLANE_TYPE_PRIMARY (likewise for the cursor).

[toc] | [prev] | [next] | [standalone]


#1654777 — RE: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g

From"Chen, Xiaoguang" <xiaoguang.chen@intel.com>
Date2017-06-01 05:10 +0200
SubjectRE: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g
Message-ID<tNoEO-5s8-19@gated-at.bofh.it>
In reply to#1654173
Hi Gerd,

>-----Original Message-----
>From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On
>Behalf Of Gerd Hoffmann
>Sent: Wednesday, May 31, 2017 8:05 PM
>To: Chen, Xiaoguang <xiaoguang.chen@intel.com>;
>alex.williamson@redhat.com; chris@chris-wilson.co.uk; intel-
>gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
>zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-
>dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>; Tian, Kevin
><kevin.tian@intel.com>
>Subject: Re: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g
>
>On Sat, 2017-05-27 at 16:38 +0800, Xiaoguang Chen wrote:
>> +       if (plane_id == PLANE_PRIMARY) {
>
>Should be DRM_PLANE_TYPE_PRIMARY (likewise for the cursor).
OK. I will change in the next version.

>_______________________________________________
>intel-gvt-dev mailing list
>intel-gvt-dev@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

[toc] | [prev] | [next] | [standalone]


#1654957 — Re: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g

FromChris Wilson <chris@chris-wilson.co.uk>
Date2017-06-01 11:20 +0200
SubjectRe: [PATCH v6 5/6] drm/i915/gvt: Dmabuf support for GVT-g
Message-ID<tNuqR-EJ-11@gated-at.bofh.it>
In reply to#1651814
On Sat, May 27, 2017 at 04:38:51PM +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@intel.com>
> ---
>  drivers/gpu/drm/i915/gvt/Makefile      |   2 +-
>  drivers/gpu/drm/i915/gvt/dmabuf.c      | 269 +++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/gvt/dmabuf.h      |  37 +++++
>  drivers/gpu/drm/i915/gvt/gvt.h         |   1 +
>  drivers/gpu/drm/i915/i915_gem.c        |  26 +++-
>  drivers/gpu/drm/i915/i915_gem_object.h |   9 ++
>  6 files changed, 342 insertions(+), 2 deletions(-)
>  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..c831e91
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -0,0 +1,269 @@
> +/*
> + * 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@intel.com>
> + *
> + * Contributors:
> + *    Xiaoguang Chen <xiaoguang.chen@intel.com>
> + */
> +
> +#include <linux/dma-buf.h>
> +#include <drm/drmP.h>
> +#include <linux/vfio.h>
> +
> +#include "i915_drv.h"
> +#include "gvt.h"
> +
> +#define GEN8_DECODE_PTE(pte) (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;
> +	struct intel_vgpu_fb_info *fb_info;
> +
> +	fb_info = (struct intel_vgpu_fb_info *)obj->gvt_info;
> +	if (WARN_ON(!fb_info))
> +		return ERR_PTR(-ENODEV);
> +
> +	st = kmalloc(sizeof(*st), GFP_KERNEL);
> +	if (!st) {
> +		ret = -ENOMEM;
> +		return ERR_PTR(ret);

Tidier.

> +	}
> +
> +	ret = sg_alloc_table(st, fb_info->fb_size, GFP_KERNEL);
> +	if (ret) {
> +		kfree(st);
> +		return ERR_PTR(ret);
> +	}
> +	gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
> +		(fb_info->fb_addr >> PAGE_SHIFT);
> +	for_each_sg(st->sgl, sg, fb_info->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;
> +	}
> +
> +	return st;
> +}
> +
> +static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
> +		struct sg_table *pages)
> +{
> +	sg_free_table(pages);
> +	kfree(pages);
> +}
> +
> +static const struct drm_i915_gem_object_ops intel_vgpu_gem_ops = {
> +	.flags = I915_GEM_OBJECT_IS_PROXY,
> +	.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 vfio_vgpu_plane_info *info)
> +{
> +	struct drm_i915_private *dev_priv = to_i915(dev);
> +	struct drm_i915_gem_object *obj;
> +
> +	obj = i915_gem_object_alloc(dev_priv);
> +	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;
> +	/* Change tiling mode from user space is not supported to a GVT-g's
> +	 * dma-buf gem object.
> +	 * We increase the obj's framebuffer_references to disable this kind
> +	 * of operation.
> +	 */
> +	obj->framebuffer_references++;

If it is only for that, don't. Just use the is_proxy: return -EPERM. So
that you don't make the mistake of leaving the counter dangling and the
error code is consistent.

What you probably should consider though is setting obj->pin_display.
That will fix up coherency along a few more paths.

> +	if (IS_SKYLAKE(dev_priv)) {
> +		unsigned int tiling_mode = 0;
> +		unsigned int stride = 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;
> +			stride = info->stride;
> +			break;
> +		case PLANE_CTL_TILED_Y:
> +			tiling_mode = I915_TILING_Y;
> +			stride = info->stride;
> +			break;
> +		default:
> +			gvt_dbg_core("not supported tiling mode\n");
> +		}
> +		obj->tiling_and_stride = tiling_mode | stride;
> +	} else {
> +		obj->tiling_and_stride = info->drm_format_mod ?
> +					I915_TILING_X : 0;
> +	}
> +
> +	return obj;
> +}

> +
> +int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args)
> +{
> +	struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
> +	struct vfio_vgpu_plane_info *info = args;
> +
> +	return intel_vgpu_get_plane_info(dev, vgpu, info);
> +}
> +
> +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 vfio_vgpu_dmabuf_info *gvt_dmabuf = args;
> +	struct intel_vgpu_fb_info *fb_info;
> +	int ret;
> +
> +	ret = intel_vgpu_get_plane_info(dev, vgpu, &gvt_dmabuf->plane_info);
> +	if (ret != 0)
> +		return ret;
> +
> +	obj = intel_vgpu_create_gem(dev, &gvt_dmabuf->plane_info);
> +	if (obj == NULL) {
> +		gvt_vgpu_err("create gvt gem obj failed:%d\n", vgpu->id);
> +		return -ENOMEM;
> +	}
> +	fb_info = kmalloc(sizeof(*fb_info), GFP_KERNEL);
> +	if (!fb_info) {
> +		i915_gem_object_put(obj);
> +		gvt_vgpu_err("allocate intel vgpu fb info failed\n");
> +		return -ENOMEM;
> +	}
> +	fb_info->fb_addr = gvt_dmabuf->plane_info.start;
> +	fb_info->fb_size = gvt_dmabuf->plane_info.size;
> +	fb_info->vgpu = vgpu;
> +	obj->gvt_info = fb_info;
> +
> +	dmabuf = i915_gem_prime_export(dev, &obj->base, DRM_CLOEXEC | DRM_RDWR);
> +
> +	if (IS_ERR(dmabuf)) {
> +		kfree(fb_info);
> +		i915_gem_object_free(obj);
> +		gvt_vgpu_err("export dma-buf failed\n");

Develop a habit for using onion unwind for errors.

> +		return PTR_ERR(dmabuf);
> +	}
> +
> +	ret = dma_buf_fd(dmabuf, DRM_CLOEXEC | DRM_RDWR);
> +	if (ret < 0) {
> +		kfree(fb_info);
> +		i915_gem_object_free(obj);
> +		gvt_vgpu_err("create dma-buf fd failed ret:%d\n", ret);
> +		return ret;
> +	}
> +	gvt_dmabuf->fd = ret;
> +
> +	return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0c1cbe9..14be3b0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1609,6 +1609,12 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
>  	if (!obj)
>  		return -ENOENT;
>  
> +	/* proxy gem object does not support setting domain */
> +	if (i915_gem_object_is_proxy(obj)) {
> +		i915_gem_object_put(obj);
> +		return -EPERM;

Hook into the onion.

> +	}
> +
>  	/* Try to flush the object off the GPU without holding the lock.
>  	 * We will repeat the flush holding the lock in the normal manner
>  	 * to catch cases where we are gazumped.
> @@ -1677,6 +1683,12 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
>  	if (!obj)
>  		return -ENOENT;
>  
> +	/* proxy gem obj does not support this operation */
> +	if (i915_gem_object_is_proxy(obj)) {
> +		i915_gem_object_put(obj);
> +		return -EPERM;
> +	}
> +
>  	/* Pinned buffers may be scanout, so flush the cache */
>  	i915_gem_object_flush_if_display(obj);
>  	i915_gem_object_put(obj);
> @@ -1727,7 +1739,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
>  	 */
>  	if (!obj->base.filp) {
>  		i915_gem_object_put(obj);
> -		return -EINVAL;
> +		return -EPERM;
>  	}
>  
>  	addr = vm_mmap(obj->base.filp, 0, args->size,
> @@ -3717,6 +3729,12 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void *data,
>  	if (!obj)
>  		return -ENOENT;
>  
> +	/* proxy gem obj does not support setting caching mode */
> +	if (i915_gem_object_is_proxy(obj)) {
> +		i915_gem_object_put(obj);
> +		return -EPERM;

Use the onion.
> +	}
> +
>  	if (obj->cache_level == level)
>  		goto out;
>  
> @@ -4168,6 +4186,12 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
>  	if (!obj)
>  		return -ENOENT;
>  
> +	/* proxy gem obj does not support changing backding storage */
> +	if (i915_gem_object_is_proxy(obj)) {
> +		i915_gem_object_put(obj);

More onion.

> +		return -EPERM;
> +	}
> +
>  	err = mutex_lock_interruptible(&obj->mm.lock);
>  	if (err)
>  		goto out;

-- 
Chris Wilson, Intel Open Source Technology Centre

[toc] | [prev] | [next] | [standalone]


#1651816 — [PATCH v6 1/6] drm/i915/gvt: Extend the GVT-g architecture to support vfio device region

FromXiaoguang Chen <xiaoguang.chen@intel.com>
Date2017-05-27 10:50 +0200
Subject[PATCH v6 1/6] drm/i915/gvt: Extend the GVT-g architecture to support vfio device region
Message-ID<tLFA6-QN-17@gated-at.bofh.it>
In reply to#1651811
Signed-off-by: Xiaoguang Chen <xiaoguang.chen@intel.com>
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 1ae0b40..3c6a02b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,11 +53,21 @@ static const struct intel_gvt_ops *intel_gvt_ops;
 #define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
 #define VFIO_PCI_OFFSET_MASK    (((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
 
+struct vfio_region;
+struct intel_vgpu_regops {
+	size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
+			size_t count, loff_t *ppos, bool iswrite);
+	void (*release)(struct intel_vgpu *vgpu,
+			struct vfio_region *region);
+};
+
 struct vfio_region {
 	u32				type;
 	u32				subtype;
 	size_t				size;
 	u32				flags;
+	const struct intel_vgpu_regops	*ops;
+	void				*data;
 };
 
 struct kvmgt_pgfn {
@@ -642,7 +652,7 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev, char *buf,
 	int ret = -EINVAL;
 
 
-	if (index >= VFIO_PCI_NUM_REGIONS) {
+	if (index >= VFIO_PCI_NUM_REGIONS + vgpu->vdev.num_regions) {
 		gvt_vgpu_err("invalid index: %u\n", index);
 		return -EINVAL;
 	}
@@ -676,8 +686,11 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev, char *buf,
 	case VFIO_PCI_BAR5_REGION_INDEX:
 	case VFIO_PCI_VGA_REGION_INDEX:
 	case VFIO_PCI_ROM_REGION_INDEX:
+		break;
 	default:
-		gvt_vgpu_err("unsupported region: %u\n", index);
+		index -= VFIO_PCI_NUM_REGIONS;
+		return vgpu->vdev.region[index].ops->rw(vgpu, buf, count,
+				ppos, is_write);
 	}
 
 	return ret == 0 ? count : ret;
@@ -940,7 +953,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, unsigned int cmd,
 
 		info.flags = VFIO_DEVICE_FLAGS_PCI;
 		info.flags |= VFIO_DEVICE_FLAGS_RESET;
-		info.num_regions = VFIO_PCI_NUM_REGIONS;
+		info.num_regions = VFIO_PCI_NUM_REGIONS +
+				vgpu->vdev.num_regions;
 		info.num_irqs = VFIO_PCI_NUM_IRQS;
 
 		return copy_to_user((void __user *)arg, &info, minsz) ?
@@ -1061,6 +1075,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, unsigned int cmd,
 		}
 
 		if (caps.size) {
+			info.flags |= VFIO_REGION_INFO_FLAG_CAPS;
 			if (info.argsz < sizeof(info) + caps.size) {
 				info.argsz = sizeof(info) + caps.size;
 				info.cap_offset = 0;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]


#1651817 — [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

FromXiaoguang Chen <xiaoguang.chen@intel.com>
Date2017-05-27 10:50 +0200
Subject[PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tLFA6-QN-19@gated-at.bofh.it>
In reply to#1651811
Here we defined a new ioctl to create a fd for a vfio device based on
the input type. Now only one type is supported that is a dma-buf
management fd.
Two ioctls are defined for the dma-buf management fd: query the vfio
vgpu's plane information and create a dma-buf for a plane.

Signed-off-by: Xiaoguang Chen <xiaoguang.chen@intel.com>
---
 include/uapi/linux/vfio.h | 50 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index ae46105..308e7a2 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -502,6 +502,56 @@ struct vfio_pci_hot_reset {
 
 #define VFIO_DEVICE_PCI_HOT_RESET	_IO(VFIO_TYPE, VFIO_BASE + 13)
 
+/**
+ * VFIO_DEVICE_GET_FD - _IO(VFIO_TYPE, VFIO_BASE + 14, __u32)
+ *
+ * Create a fd for a vfio device based on the input type
+ * Vendor driver should handle this ioctl to create a fd and manage the
+ * life cycle of this fd.
+ *
+ * Return: a fd if vendor support that type, -errno if not supported
+ */
+
+#define VFIO_DEVICE_GET_FD	_IO(VFIO_TYPE, VFIO_BASE + 14)
+
+#define VFIO_DEVICE_DMABUF_MGR_FD	0 /* Supported fd types */
+
+/*
+ * VFIO_DEVICE_QUERY_PLANE - _IO(VFIO_TYPE, VFIO_BASE + 15, struct plane_info)
+ * Query plane information for a plane
+ */
+struct vfio_vgpu_plane_info {
+	__u32 argsz;
+	__u32 flags;
+	__u32 plane_id;
+	__u32 drm_format;
+	__u32 width;
+	__u32 height;
+	__u32 stride;
+	__u32 start;
+	__u32 x_pos;
+	__u32 y_pos;
+	__u64 drm_format_mod;
+	__u32 size;
+	__u32 pad;
+};
+
+#define VFIO_DEVICE_QUERY_PLANE _IO(VFIO_TYPE, VFIO_BASE + 15)
+
+/*
+ * VFIO_DEVICE_CREATE_DMABUF - _IO(VFIO, VFIO_BASE + 16, struct dmabuf_info)
+ *
+ * Create a dma-buf for a plane
+ */
+struct vfio_vgpu_dmabuf_info {
+	__u32 argsz;
+	__u32 flags;
+	struct vfio_vgpu_plane_info plane_info;
+	__s32 fd;
+	__u32 pad;
+};
+#define VFIO_DEVICE_CREATE_DMABUF _IO(VFIO_TYPE, VFIO_BASE + 16)
+
 /* -------- API for Type1 VFIO IOMMU -------- */
 
 /**
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]


#1652253 — Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

FromGerd Hoffmann <kraxel@redhat.com>
Date2017-05-29 09:30 +0200
SubjectRe: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tMnhL-4ZZ-7@gated-at.bofh.it>
In reply to#1651817
> +struct vfio_vgpu_dmabuf_info {
> +	__u32 argsz;
> +	__u32 flags;
> +	struct vfio_vgpu_plane_info plane_info;
> +	__s32 fd;
> +	__u32 pad;
> +};

Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...

I think we should have something like this:

struct vfio_vgpu_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 padding;
};

struct vfio_vgpu_query_plane {
	__u32 argsz;
	__u32 flags;
	struct vfio_vgpu_plane_info plane_info;
        __u32 plane_id;
        __u32 padding;
};

struct vfio_vgpu_create_dmabuf {
	__u32 argsz;
	__u32 flags;
	struct vfio_vgpu_plane_info plane_info;
        __u32 plane_id;
        __s32 fd;
};

[toc] | [prev] | [next] | [standalone]


#1653852 — RE: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

From"Chen, Xiaoguang" <xiaoguang.chen@intel.com>
Date2017-05-31 08:20 +0200
SubjectRE: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tN597-16T-5@gated-at.bofh.it>
In reply to#1652253
Hi,

>-----Original Message-----
>From: Gerd Hoffmann [mailto:kraxel@redhat.com]
>Sent: Monday, May 29, 2017 3:20 PM
>To: Chen, Xiaoguang <xiaoguang.chen@intel.com>;
>alex.williamson@redhat.com; chris@chris-wilson.co.uk; intel-
>gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
>zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-
>dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>; Tian, Kevin
><kevin.tian@intel.com>
>Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
>
>> +struct vfio_vgpu_dmabuf_info {
>> +	__u32 argsz;
>> +	__u32 flags;
>> +	struct vfio_vgpu_plane_info plane_info;
>> +	__s32 fd;
>> +	__u32 pad;
>> +};
>
>Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
>
>I think we should have something like this:
>
>struct vfio_vgpu_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 padding;
>};
>
>struct vfio_vgpu_query_plane {
>	__u32 argsz;
>	__u32 flags;
>	struct vfio_vgpu_plane_info plane_info;
>        __u32 plane_id;
>        __u32 padding;
>};
>
>struct vfio_vgpu_create_dmabuf {
>	__u32 argsz;
>	__u32 flags;
>	struct vfio_vgpu_plane_info plane_info;
>        __u32 plane_id;
>        __s32 fd;
>};
Good suggestion will apply in the next version.
Thanks for review :)

Chenxg.

[toc] | [prev] | [next] | [standalone]


#1654478 — Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

FromKirti Wankhede <kwankhede@nvidia.com>
Date2017-05-31 19:30 +0200
SubjectRe: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tNfBv-7MH-1@gated-at.bofh.it>
In reply to#1653852

On 5/31/2017 11:48 AM, Chen, Xiaoguang wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Gerd Hoffmann [mailto:kraxel@redhat.com]
>> Sent: Monday, May 29, 2017 3:20 PM
>> To: Chen, Xiaoguang <xiaoguang.chen@intel.com>;
>> alex.williamson@redhat.com; chris@chris-wilson.co.uk; intel-
>> gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
>> zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-
>> dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>; Tian, Kevin
>> <kevin.tian@intel.com>
>> Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
>>
>>> +struct vfio_vgpu_dmabuf_info {
>>> +	__u32 argsz;
>>> +	__u32 flags;
>>> +	struct vfio_vgpu_plane_info plane_info;
>>> +	__s32 fd;
>>> +	__u32 pad;
>>> +};
>>
>> Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
>>
>> I think we should have something like this:
>>
>> struct vfio_vgpu_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 padding;
>> };
>>
>> struct vfio_vgpu_query_plane {
>> 	__u32 argsz;
>> 	__u32 flags;
>> 	struct vfio_vgpu_plane_info plane_info;
>>        __u32 plane_id;
>>        __u32 padding;
>> };
>>
>> struct vfio_vgpu_create_dmabuf {
>> 	__u32 argsz;
>> 	__u32 flags;
>> 	struct vfio_vgpu_plane_info plane_info;
>>        __u32 plane_id;
>>        __s32 fd;
>> };
> Good suggestion will apply in the next version.
> Thanks for review :)
> 

Can you define what are the expected values of 'flags' would be?

Thanks,
Kirti

> Chenxg.
> 

[toc] | [prev] | [next] | [standalone]


#1654773 — RE: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

From"Chen, Xiaoguang" <xiaoguang.chen@intel.com>
Date2017-06-01 05:10 +0200
SubjectRE: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tNoEO-5s8-9@gated-at.bofh.it>
In reply to#1654478
Hi Kirti,

>-----Original Message-----
>From: Kirti Wankhede [mailto:kwankhede@nvidia.com]
>Sent: Thursday, June 01, 2017 1:23 AM
>To: Chen, Xiaoguang <xiaoguang.chen@intel.com>; Gerd Hoffmann
><kraxel@redhat.com>; alex.williamson@redhat.com; chris@chris-wilson.co.uk;
>intel-gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
>zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-
>dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>; Tian, Kevin
><kevin.tian@intel.com>
>Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
>
>
>
>On 5/31/2017 11:48 AM, Chen, Xiaoguang wrote:
>> Hi,
>>
>>> -----Original Message-----
>>> From: Gerd Hoffmann [mailto:kraxel@redhat.com]
>>> Sent: Monday, May 29, 2017 3:20 PM
>>> To: Chen, Xiaoguang <xiaoguang.chen@intel.com>;
>>> alex.williamson@redhat.com; chris@chris-wilson.co.uk; intel-
>>> gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
>>> zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>;
>>> intel-gvt- dev@lists.freedesktop.org; Wang, Zhi A
>>> <zhi.a.wang@intel.com>; Tian, Kevin <kevin.tian@intel.com>
>>> Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf
>>> operations
>>>
>>>> +struct vfio_vgpu_dmabuf_info {
>>>> +	__u32 argsz;
>>>> +	__u32 flags;
>>>> +	struct vfio_vgpu_plane_info plane_info;
>>>> +	__s32 fd;
>>>> +	__u32 pad;
>>>> +};
>>>
>>> Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
>>>
>>> I think we should have something like this:
>>>
>>> struct vfio_vgpu_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 padding;
>>> };
>>>
>>> struct vfio_vgpu_query_plane {
>>> 	__u32 argsz;
>>> 	__u32 flags;
>>> 	struct vfio_vgpu_plane_info plane_info;
>>>        __u32 plane_id;
>>>        __u32 padding;
>>> };
>>>
>>> struct vfio_vgpu_create_dmabuf {
>>> 	__u32 argsz;
>>> 	__u32 flags;
>>> 	struct vfio_vgpu_plane_info plane_info;
>>>        __u32 plane_id;
>>>        __s32 fd;
>>> };
>> Good suggestion will apply in the next version.
>> Thanks for review :)
>>
>
>Can you define what are the expected values of 'flags' would be?
Flags is not used in this case.  It is defined to follow the rules of vfio ioctls.

>
>Thanks,
>Kirti
>
>> Chenxg.
>>

[toc] | [prev] | [next] | [standalone]


#1655465 — Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

FromAlex Williamson <alex.williamson@redhat.com>
Date2017-06-01 18:40 +0200
SubjectRe: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tNBiI-4Yy-67@gated-at.bofh.it>
In reply to#1654773
On Thu, 1 Jun 2017 03:01:28 +0000
"Chen, Xiaoguang" <xiaoguang.chen@intel.com> wrote:

> Hi Kirti,
> 
> >-----Original Message-----
> >From: Kirti Wankhede [mailto:kwankhede@nvidia.com]
> >Sent: Thursday, June 01, 2017 1:23 AM
> >To: Chen, Xiaoguang <xiaoguang.chen@intel.com>; Gerd Hoffmann
> ><kraxel@redhat.com>; alex.williamson@redhat.com; chris@chris-wilson.co.uk;
> >intel-gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
> >zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-
> >dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>; Tian, Kevin
> ><kevin.tian@intel.com>
> >Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
> >
> >
> >
> >On 5/31/2017 11:48 AM, Chen, Xiaoguang wrote:  
> >> Hi,
> >>  
> >>> -----Original Message-----
> >>> From: Gerd Hoffmann [mailto:kraxel@redhat.com]
> >>> Sent: Monday, May 29, 2017 3:20 PM
> >>> To: Chen, Xiaoguang <xiaoguang.chen@intel.com>;
> >>> alex.williamson@redhat.com; chris@chris-wilson.co.uk; intel-
> >>> gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
> >>> zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>;
> >>> intel-gvt- dev@lists.freedesktop.org; Wang, Zhi A
> >>> <zhi.a.wang@intel.com>; Tian, Kevin <kevin.tian@intel.com>
> >>> Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf
> >>> operations
> >>>  
> >>>> +struct vfio_vgpu_dmabuf_info {
> >>>> +	__u32 argsz;
> >>>> +	__u32 flags;
> >>>> +	struct vfio_vgpu_plane_info plane_info;
> >>>> +	__s32 fd;
> >>>> +	__u32 pad;
> >>>> +};  
> >>>
> >>> Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
> >>>
> >>> I think we should have something like this:
> >>>
> >>> struct vfio_vgpu_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 padding;
> >>> };
> >>>
> >>> struct vfio_vgpu_query_plane {
> >>> 	__u32 argsz;
> >>> 	__u32 flags;
> >>> 	struct vfio_vgpu_plane_info plane_info;
> >>>        __u32 plane_id;
> >>>        __u32 padding;
> >>> };
> >>>
> >>> struct vfio_vgpu_create_dmabuf {
> >>> 	__u32 argsz;
> >>> 	__u32 flags;
> >>> 	struct vfio_vgpu_plane_info plane_info;
> >>>        __u32 plane_id;
> >>>        __s32 fd;
> >>> };  
> >> Good suggestion will apply in the next version.
> >> Thanks for review :)
> >>  
> >
> >Can you define what are the expected values of 'flags' would be?  
> Flags is not used in this case.  It is defined to follow the rules of vfio ioctls.

An important note about flags, the vendor driver must validate it.  If
they don't and the user passes an arbitrary value there, then we have a
backwards compatibility issue with ever attempting to use the flags
field.  The user passing in a flag unknown to the vendor driver should
return an -EINVAL response.  In this case, we haven't defined any
flags, so the vendor driver needs to force the user to pass zero.
Thanks,

Alex

[toc] | [prev] | [next] | [standalone]


#1655670 — Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

FromKirti Wankhede <kwankhede@nvidia.com>
Date2017-06-01 20:50 +0200
SubjectRe: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tNDku-6hn-25@gated-at.bofh.it>
In reply to#1655465

On 6/1/2017 10:08 PM, Alex Williamson wrote:
> On Thu, 1 Jun 2017 03:01:28 +0000
> "Chen, Xiaoguang" <xiaoguang.chen@intel.com> wrote:
> 
>> Hi Kirti,
>>
>>> -----Original Message-----
>>> From: Kirti Wankhede [mailto:kwankhede@nvidia.com]
>>> Sent: Thursday, June 01, 2017 1:23 AM
>>> To: Chen, Xiaoguang <xiaoguang.chen@intel.com>; Gerd Hoffmann
>>> <kraxel@redhat.com>; alex.williamson@redhat.com; chris@chris-wilson.co.uk;
>>> intel-gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
>>> zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-
>>> dev@lists.freedesktop.org; Wang, Zhi A <zhi.a.wang@intel.com>; Tian, Kevin
>>> <kevin.tian@intel.com>
>>> Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
>>>
>>>
>>>
>>> On 5/31/2017 11:48 AM, Chen, Xiaoguang wrote:  
>>>> Hi,
>>>>  
>>>>> -----Original Message-----
>>>>> From: Gerd Hoffmann [mailto:kraxel@redhat.com]
>>>>> Sent: Monday, May 29, 2017 3:20 PM
>>>>> To: Chen, Xiaoguang <xiaoguang.chen@intel.com>;
>>>>> alex.williamson@redhat.com; chris@chris-wilson.co.uk; intel-
>>>>> gfx@lists.freedesktop.org; linux-kernel@vger.kernel.org;
>>>>> zhenyuw@linux.intel.com; Lv, Zhiyuan <zhiyuan.lv@intel.com>;
>>>>> intel-gvt- dev@lists.freedesktop.org; Wang, Zhi A
>>>>> <zhi.a.wang@intel.com>; Tian, Kevin <kevin.tian@intel.com>
>>>>> Subject: Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf
>>>>> operations
>>>>>  
>>>>>> +struct vfio_vgpu_dmabuf_info {
>>>>>> +	__u32 argsz;
>>>>>> +	__u32 flags;
>>>>>> +	struct vfio_vgpu_plane_info plane_info;
>>>>>> +	__s32 fd;
>>>>>> +	__u32 pad;
>>>>>> +};  
>>>>>
>>>>> Hmm, now you have argsz and flags twice in vfio_vgpu_dmabuf_info ...
>>>>>
>>>>> I think we should have something like this:
>>>>>
>>>>> struct vfio_vgpu_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 padding;
>>>>> };
>>>>>
>>>>> struct vfio_vgpu_query_plane {
>>>>> 	__u32 argsz;
>>>>> 	__u32 flags;
>>>>> 	struct vfio_vgpu_plane_info plane_info;
>>>>>        __u32 plane_id;
>>>>>        __u32 padding;
>>>>> };
>>>>>
>>>>> struct vfio_vgpu_create_dmabuf {
>>>>> 	__u32 argsz;
>>>>> 	__u32 flags;
>>>>> 	struct vfio_vgpu_plane_info plane_info;
>>>>>        __u32 plane_id;
>>>>>        __s32 fd;
>>>>> };  
>>>> Good suggestion will apply in the next version.
>>>> Thanks for review :)
>>>>  
>>>
>>> Can you define what are the expected values of 'flags' would be?  
>> Flags is not used in this case.  It is defined to follow the rules of vfio ioctls.
> 
> An important note about flags, the vendor driver must validate it.  If
> they don't and the user passes an arbitrary value there, then we have a
> backwards compatibility issue with ever attempting to use the flags
> field.  The user passing in a flag unknown to the vendor driver should
> return an -EINVAL response.  In this case, we haven't defined any
> flags, so the vendor driver needs to force the user to pass zero.

There are two ways QEMU can get surface for console:
1. adding a region using region capability
2. dmabuf

In both the above case surface parameters need to be queried from vendor
driver are same. The structure would be :

struct vfio_vgpu_surface_info {
        __u64 start;
        __u32 width;
        __u32 height;
        __u32 stride;
        __u32 size;
        __u32 x_pos;
        __u32 y_pos;
        __u32 padding;
        /* Only used when VFIO_VGPU_SURFACE_DMABUF_* flags set */
        __u64 drm_format_mod;
        __u32 drm_format;
};

We can use one ioctl to query surface information from vendor driver,
structure would look like:

struct vfio_vgpu_get_surface_info{
	__u32 argsz;
	__u32 flags;
#define VFIO_VGPU_SURFACE_DMABUF_CREATE	(1 << 0) /* Create dmabuf */
#define VFIO_VGPU_SURFACE_DMABUF_QUERY	(1 << 1) /* Query surface info
for dmabuf */
#define VFIO_VGPU_SURFACE_REGION_QUERY	(1 << 2) /* Query surface info
for REGION type  */
	struct vfio_vgpu_surface_info surface;
        __u32 plane_id;
        __s32 fd;
};

#define VFIO_DEVICE_SURFACE_INFO _IO(VFIO_TYPE, VFIO_BASE + 15)

Vendor driver should return -EINVAL, if that type of query is not
supported.

I would like to design this interface to support both type, region cap
and dmabuf.

Thanks,
Kirti

[toc] | [prev] | [next] | [standalone]


#1656015 — Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

FromGerd Hoffmann <kraxel@redhat.com>
Date2017-06-02 10:40 +0200
SubjectRe: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tNQhH-718-13@gated-at.bofh.it>
In reply to#1655670
> struct vfio_vgpu_surface_info {
>         __u64 start;
>         __u32 width;
>         __u32 height;
>         __u32 stride;
>         __u32 size;
>         __u32 x_pos;
>         __u32 y_pos;
>         __u32 padding;
>         /* Only used when VFIO_VGPU_SURFACE_DMABUF_* flags set */
>         __u64 drm_format_mod;
>         __u32 drm_format;

Why for dmabufs only?  Shouldn't the region specify the format too? 
Even in case you are using a fixed one (say DRM_FORMAT_XRGB8888) you
can explicitly say so in drm_format (and set drm_format_mod to zero).

cheers,
  Gerd

[toc] | [prev] | [next] | [standalone]


#1657383 — Re: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

FromKirti Wankhede <kwankhede@nvidia.com>
Date2017-06-05 10:30 +0200
SubjectRe: [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations
Message-ID<tOVyI-rf-49@gated-at.bofh.it>
In reply to#1656015

On 6/2/2017 2:08 PM, Gerd Hoffmann wrote:
> 
>> struct vfio_vgpu_surface_info {
>>         __u64 start;
>>         __u32 width;
>>         __u32 height;
>>         __u32 stride;
>>         __u32 size;
>>         __u32 x_pos;
>>         __u32 y_pos;
>>         __u32 padding;
>>         /* Only used when VFIO_VGPU_SURFACE_DMABUF_* flags set */
>>         __u64 drm_format_mod;
>>         __u32 drm_format;
> 
> Why for dmabufs only?  Shouldn't the region specify the format too? 
> Even in case you are using a fixed one (say DRM_FORMAT_XRGB8888) you
> can explicitly say so in drm_format (and set drm_format_mod to zero).
> 

Definitions for PIXMAN formats and DRM formats are different. I think
we need a flag to specify the format of surface that vendor driver is
going to provide, PIXMAN or DRM.
If surface is provided through region in PIXMAN format, existing
functions in QEMU can be used to get format from bpp value,
qemu_default_pixman_format(). Similarly, display surface can be updated
by QEMU using qemu_create_displaysurface_from() from mmaped region.

Thanks,
Kirti

> cheers,
>   Gerd
> 

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel


csiph-web