[Intel-gfx] [RFC PATCH v2 2/2] drm/i915: Move GVT device model into separate module

[Zhenyu Wang]

This makes GVT device model into a stand alone module named as
"i915_gvt", which depends on i915 but load after i915 that do
all left GVT host initialization setup.

Currently i915_gvt module would still load "kvmgt" module to
initialize for VFIO/mdev device, but this might be changed in future.
As will make hypervisor module load to initialize GVT host instead.

One problem by this split is that GVT requires HW initial MMIO state
as base initial state for each vGPU after create, which should be
taken in very early stage of i915 load to reflect HW state. Just
reading all MMIO won't work, as it could cause unknown side effect e.g
HW hang. So current choice is to read back MMIO that GVT actually
track. But instead of reference any GVT files, this one just copied
register list. So GVT will use initial dump instead when load.

Cc: Joonas Lahtinen 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/Kconfig|2 +-
 drivers/gpu/drm/i915/Makefile   |4 +-
 drivers/gpu/drm/i915/gvt/Makefile   |8 +-
 drivers/gpu/drm/i915/gvt/firmware.c |2 +-
 drivers/gpu/drm/i915/gvt/gvt.c  |   52 +-
 drivers/gpu/drm/i915/gvt/gvt.h  |3 +
 drivers/gpu/drm/i915/i915_drv.c |   43 +-
 drivers/gpu/drm/i915/i915_drv.h |   10 +-
 drivers/gpu/drm/i915/i915_params.c  |5 -
 drivers/gpu/drm/i915/i915_params.h  |3 +-
 drivers/gpu/drm/i915/intel_gvt.c| 1519 +--
 drivers/gpu/drm/i915/intel_gvt.h|   29 +-
 12 files changed, 1547 insertions(+), 133 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 33a458b7f1fc..a05261cabf53 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -96,7 +96,7 @@ config DRM_I915_USERPTR
  If in doubt, say "Y".
 
 config DRM_I915_GVT
-bool "Enable Intel GVT-g graphics virtualization host support"
+tristate "Enable Intel GVT-g graphics virtualization host support"
 depends on DRM_I915
 depends on 64BIT
 default n
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ff878c994e2..3c23d0a5552a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -186,12 +186,12 @@ i915-y += i915_perf.o \
  i915_oa_cnl.o \
  i915_oa_icl.o
 
-ifeq ($(CONFIG_DRM_I915_GVT),y)
+ifneq ($(CONFIG_DRM_I915_GVT),n)
 i915-y += intel_gvt.o
-include $(src)/gvt/Makefile
 endif
 
 # LPE Audio for VLV and CHT
 i915-y += intel_lpe_audio.o
 
 obj-$(CONFIG_DRM_I915) += i915.o
+obj-$(CONFIG_DRM_I915_GVT) += gvt/
diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index b016dc753db9..f41cfc7625b4 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,10 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
-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 mmio_context.o cmd_parser.o 
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
 
-ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
-i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
-obj-$(CONFIG_DRM_I915_GVT_KVMGT)   += $(GVT_DIR)/kvmgt.o
+ccflags-y  += -I$(src) -I$(src)/../
+i915_gvt-y := $(GVT_SOURCE)
+obj-$(CONFIG_DRM_I915_GVT_KVMGT)   += kvmgt.o
+obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 4ac18b447247..7a3441fb9f70 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -70,7 +70,7 @@ static int mmio_snapshot_handler(struct intel_gvt *gvt, u32 
offset, void *data)
 {
struct drm_i915_private *dev_priv = gvt->dev_priv;
 
-   *(u32 *)(data + offset) = I915_READ_NOTRACE(_MMIO(offset));
+   *(u32 *)(data + offset) = dev_priv->hw_init_mmio[offset >> 2];
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 733a2a0d0c30..bde20d86acf5 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -30,10 +30,11 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
-
+#include 
 #include "i915_drv.h"
 #include "gvt.h"
 #include 
@@ -216,8 +217,8 @@ int intel_gvt_init_host(void)
} else {
 #if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
/* not in Xen. Try KVMGT */
-   intel_gvt_host.mpt = try_then_request_module(
-   symbol_get(kvmgt_mpt), "kvmgt");
+   request_module("kvmgt");
+   intel_gvt_host.mpt = _mpt;
intel_gvt_host.hypervisor_type = INTEL_GVT_HYPERVISOR_KV

[Intel-gfx] [RFC PATCH v2 0/2] GVT device model split

[Zhenyu Wang]

Refresh previous attempt to split GVT module.

This trys to move GVT device model in stand alone module. New module
named as "i915_gvt" is created. The purpose is to enable GVT function
once user loads i915_gvt module.

This needs to export several i915 functions currently used by GVT as
in first patch. As GVT requires HW initial MMIO state for vGPU as base
initial state after create, which needs to be got from early stage of
i915 load, this trys to read all GVT tracked registers when i915 init,
and provide for i915_gvt module when host init.

I think we would refactor "kvmgt" module init first. "kvmgt" should
register into GVT as hypervisor interface provider, instead of making
GVT to load it for now. But that still won't split GVT from i915. So
this work takes further to split GVT device model from i915.

Thanks

Zhenyu Wang (2):
  drm/i915: Export current required functions for GVT
  drm/i915: Move GVT device model into separate module

 drivers/gpu/drm/i915/Kconfig  |2 +-
 drivers/gpu/drm/i915/Makefile |4 +-
 drivers/gpu/drm/i915/gvt/Makefile |8 +-
 drivers/gpu/drm/i915/gvt/firmware.c   |2 +-
 drivers/gpu/drm/i915/gvt/gvt.c|   52 +-
 drivers/gpu/drm/i915/gvt/gvt.h|3 +
 drivers/gpu/drm/i915/i915_drv.c   |   43 +-
 drivers/gpu/drm/i915/i915_drv.h   |   10 +-
 drivers/gpu/drm/i915/i915_gem.c   |   11 +
 drivers/gpu/drm/i915/i915_gem_context.c   |2 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c|1 +
 drivers/gpu/drm/i915/i915_gem_fence_reg.c |2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c   |1 +
 drivers/gpu/drm/i915/i915_params.c|5 -
 drivers/gpu/drm/i915/i915_params.h|3 +-
 drivers/gpu/drm/i915/i915_request.c   |3 +
 drivers/gpu/drm/i915/i915_vma.c   |2 +
 drivers/gpu/drm/i915/intel_gvt.c  | 1519 -
 drivers/gpu/drm/i915/intel_gvt.h  |   29 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c   |1 +
 drivers/gpu/drm/i915/intel_runtime_pm.c   |2 +
 drivers/gpu/drm/i915/intel_uncore.c   |3 +
 22 files changed, 1575 insertions(+), 133 deletions(-)

-- 
2.19.1

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

[Intel-gfx] [RFC PATCH v2 1/2] drm/i915: Export current required functions for GVT

[Zhenyu Wang]

This trys to export all required i915 functions for GVT.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_gem.c   | 11 +++
 drivers/gpu/drm/i915/i915_gem_context.c   |  2 ++
 drivers/gpu/drm/i915/i915_gem_dmabuf.c|  1 +
 drivers/gpu/drm/i915/i915_gem_fence_reg.c |  2 ++
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  1 +
 drivers/gpu/drm/i915/i915_request.c   |  3 +++
 drivers/gpu/drm/i915/i915_vma.c   |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  1 +
 drivers/gpu/drm/i915/intel_runtime_pm.c   |  2 ++
 drivers/gpu/drm/i915/intel_uncore.c   |  3 +++
 10 files changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c55b1f75c980..9af6e9810f85 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -701,6 +701,7 @@ void *i915_gem_object_alloc(struct drm_i915_private 
*dev_priv)
 {
return kmem_cache_zalloc(dev_priv->objects, GFP_KERNEL);
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_alloc);
 
 void i915_gem_object_free(struct drm_i915_gem_object *obj)
 {
@@ -1029,6 +1030,7 @@ int i915_gem_obj_prepare_shmem_write(struct 
drm_i915_gem_object *obj,
i915_gem_object_unpin_pages(obj);
return ret;
 }
+EXPORT_SYMBOL_GPL(i915_gem_obj_prepare_shmem_write);
 
 static void
 shmem_clflush_swizzled_range(char *addr, unsigned long length,
@@ -2764,6 +2766,7 @@ void __i915_gem_object_set_pages(struct 
drm_i915_gem_object *obj,
list_add(>mm.link, >mm.unbound_list);
spin_unlock(>mm.obj_lock);
 }
+EXPORT_SYMBOL_GPL(__i915_gem_object_set_pages);
 
 static int i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
 {
@@ -2930,6 +2933,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
ptr = ERR_PTR(ret);
goto out_unlock;
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_pin_map);
 
 static int
 i915_gem_object_pwrite_gtt(struct drm_i915_gem_object *obj,
@@ -4041,6 +4045,7 @@ i915_gem_object_set_to_gtt_domain(struct 
drm_i915_gem_object *obj, bool write)
i915_gem_object_unpin_pages(obj);
return 0;
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_set_to_gtt_domain);
 
 /**
  * Changes the cache-level of an object across all VMA.
@@ -4406,6 +4411,7 @@ i915_gem_object_set_to_cpu_domain(struct 
drm_i915_gem_object *obj, bool write)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_set_to_cpu_domain);
 
 /* Throttle our rendering by waiting until the ring has completed our requests
  * emitted over 20 msec ago.
@@ -4535,6 +4541,7 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
 
return vma;
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_ggtt_pin);
 
 static __always_inline unsigned int __busy_read_flag(unsigned int id)
 {
@@ -4758,6 +4765,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
 
i915_gem_info_add_obj(to_i915(obj->base.dev), obj->base.size);
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_init);
 
 static const struct drm_i915_gem_object_ops i915_gem_object_ops = {
.flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
@@ -4864,6 +4872,7 @@ i915_gem_object_create(struct drm_i915_private *dev_priv, 
u64 size)
i915_gem_object_free(obj);
return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_create);
 
 static bool discard_backing_storage(struct drm_i915_gem_object *obj)
 {
@@ -5061,6 +5070,7 @@ void __i915_gem_object_release_unless_active(struct 
drm_i915_gem_object *obj)
else
i915_gem_object_put(obj);
 }
+EXPORT_SYMBOL_GPL(__i915_gem_object_release_unless_active);
 
 void i915_gem_sanitize(struct drm_i915_private *i915)
 {
@@ -6168,6 +6178,7 @@ i915_gem_object_get_page(struct drm_i915_gem_object *obj, 
unsigned int n)
sg = i915_gem_object_get_sg(obj, n, );
return nth_page(sg_page(sg), offset);
 }
+EXPORT_SYMBOL_GPL(i915_gem_object_get_page);
 
 /* Like i915_gem_object_get_page(), but mark the returned page dirty */
 struct page *
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index b97963db0287..212b8d176d25 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -274,6 +274,7 @@ void i915_gem_context_release(struct kref *ref)
if (llist_add(>free_link, >contexts.free_list))
queue_work(i915->wq, >contexts.free_work);
 }
+EXPORT_SYMBOL_GPL(i915_gem_context_release);
 
 static void context_close(struct i915_gem_context *ctx)
 {
@@ -473,6 +474,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
mutex_unlock(>struct_mutex);
return ctx;
 }
+EXPORT_SYMBOL_GPL(i915_gem_context_create_gvt);
 
 static void
 destroy_kernel_context(struct i915_gem_context **ctxp)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 82e2ca17a441..ac98b094220c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dm

[Intel-gfx] [PULL] gvt-fixes for 4.20-rc5

[Zhenyu Wang]

Hi,

Here's regular gvt fixes for 4.20-rc5. One to correct MOCS registers
load on engine list, one for rpm lock warning fix, and another for
use-after-free fix for partial ggtt list destroy. Details below.

Thanks
--
The following changes since commit 5e7154ff5e8e21dc9acac4f8dba7533552365374:

  drm/i915/gvt: Handle values of EDP_PSR_IMR and EDP_PSR_IIR (2018-10-31 
17:09:46 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-11-26

for you to fetch changes up to 7513edbc096a006f967eaf39088091442e623b83:

  drm/i915/gvt: Avoid use-after-free iterating the gtt list (2018-11-21 
17:31:56 +0800)


gvt-fixes-2018-11-26

- Fix engine check for correct MOCS regs load (Xinyun)
- Fix rpm locking for vGPU ggtt init (Henry)
- Fix use-after-free when destroy partial ggtt entries (Chris)


Chris Wilson (1):
  drm/i915/gvt: Avoid use-after-free iterating the gtt list

Hang Yuan (1):
  drm/i915/gvt: ensure gpu is powered before do i915_gem_gtt_insert

Xinyun Liu (1):
  drm/i915/gvt: not to touch undefined MOCS registers

 drivers/gpu/drm/i915/gvt/aperture_gm.c  | 2 ++
 drivers/gpu/drm/i915/gvt/gtt.c  | 7 ---
 drivers/gpu/drm/i915/gvt/mmio_context.c | 2 ++
 3 files changed, 8 insertions(+), 3 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Use after free in intel_vgpu_destroy_ggtt_mm()

[Zhenyu Wang]

On 2018.11.23 10:22:19 +0300, Dan Carpenter wrote:
> We need to use the _safe() version of this macro so that we don't
> dereference "pos" when it is freed.
>

Thanks, Dan.

I've already merged one same fix from Chris for this found by smatch.

> Fixes: bc0686ff5fad ("drm/i915/gvt: support inconsecutive partial gtt entry 
> write")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 58e166effa45..3f416341ae5f 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -2447,9 +2447,9 @@ static void intel_vgpu_destroy_all_ppgtt_mm(struct 
> intel_vgpu *vgpu)
>  
>  static void intel_vgpu_destroy_ggtt_mm(struct intel_vgpu *vgpu)
>  {
> - struct intel_gvt_partial_pte *pos;
> + struct intel_gvt_partial_pte *pos, *n;
>  
> - list_for_each_entry(pos,
> + list_for_each_entry_safe(pos, n,
>   >gtt.ggtt_mm->ggtt_mm.partial_pte_list, list) {
>   gvt_dbg_mm("partial PTE update on hold 0x%lx : 0x%llx\n",
>   pos->offset, pos->data);
> -- 
> 2.11.0
> 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Avoid use-after-free iterating the gtt list

[Zhenyu Wang]

On 2018.11.21 09:20:19 +, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-11-21 02:29:21)
> > On 2018.11.20 20:24:38 +, Chris Wilson wrote:
> > > Found by smatch:
> > > 
> > > drivers/gpu/drm/i915/gvt/gtt.c:2452 intel_vgpu_destroy_ggtt_mm() error: 
> > > dereferencing freed memory 'pos'
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Zhenyu Wang 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/gtt.c | 7 ---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c 
> > > b/drivers/gpu/drm/i915/gvt/gtt.c
> > > index 58e166effa45..c7103dd2d8d5 100644
> > > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > > @@ -2447,10 +2447,11 @@ static void 
> > > intel_vgpu_destroy_all_ppgtt_mm(struct intel_vgpu *vgpu)
> > >  
> > >  static void intel_vgpu_destroy_ggtt_mm(struct intel_vgpu *vgpu)
> > >  {
> > > - struct intel_gvt_partial_pte *pos;
> > > + struct intel_gvt_partial_pte *pos, *next;
> > >  
> > > - list_for_each_entry(pos,
> > > - >gtt.ggtt_mm->ggtt_mm.partial_pte_list, list) 
> > > {
> > > + list_for_each_entry_safe(pos, next,
> > > +  
> > > >gtt.ggtt_mm->ggtt_mm.partial_pte_list,
> > > +  list) {
> > >   gvt_dbg_mm("partial PTE update on hold 0x%lx : 0x%llx\n",
> > >   pos->offset, pos->data);
> > >   kfree(pos);
> > 
> > Reviewed-by: Zhenyu Wang 
> 
> I presume you will take it via the gvt tree? Saves a backmerge for you.

Sure, will take it.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Avoid use-after-free iterating the gtt list

[Zhenyu Wang]

On 2018.11.20 20:24:38 +, Chris Wilson wrote:
> Found by smatch:
> 
> drivers/gpu/drm/i915/gvt/gtt.c:2452 intel_vgpu_destroy_ggtt_mm() error: 
> dereferencing freed memory 'pos'
> 
> Signed-off-by: Chris Wilson 
> Cc: Zhenyu Wang 
> ---
>  drivers/gpu/drm/i915/gvt/gtt.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 58e166effa45..c7103dd2d8d5 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -2447,10 +2447,11 @@ static void intel_vgpu_destroy_all_ppgtt_mm(struct 
> intel_vgpu *vgpu)
>  
>  static void intel_vgpu_destroy_ggtt_mm(struct intel_vgpu *vgpu)
>  {
> - struct intel_gvt_partial_pte *pos;
> + struct intel_gvt_partial_pte *pos, *next;
>  
> - list_for_each_entry(pos,
> - >gtt.ggtt_mm->ggtt_mm.partial_pte_list, list) {
> + list_for_each_entry_safe(pos, next,
> +  >gtt.ggtt_mm->ggtt_mm.partial_pte_list,
> +  list) {
>   gvt_dbg_mm("partial PTE update on hold 0x%lx : 0x%llx\n",
>   pos->offset, pos->data);
>   kfree(pos);

Reviewed-by: Zhenyu Wang 

Thanks! I should really run check against each one when apply..

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make pipe/transcoder offsets not depend on enum values

[Zhenyu Wang]

On 2018.11.19 20:54:30 +0200, Imre Deak wrote:
> On Mon, Nov 19, 2018 at 05:29:26PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 19, 2018 at 04:41:07PM +0200, Imre Deak wrote:
> > > Depending on the transcoder enum values to translate from transcoder
> > > to pipe/transcoder register addresses can easily break if we add a new
> > > transcoder. So remove the dependency by using named initializers.
> > > 
> > > Suggested-by: Ville Syrjälä 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/i915_pci.c | 52 
> > > ++---
> > >  1 file changed, 38 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index 983ae7fd8217..1b81d7cb209e 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -33,16 +33,30 @@
> > >  #define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1)
> > >  
> > >  #define GEN_DEFAULT_PIPEOFFSETS \
> > > - .pipe_offsets = { PIPE_A_OFFSET, PIPE_B_OFFSET, \
> > > -   PIPE_C_OFFSET, PIPE_EDP_OFFSET }, \
> > > - .trans_offsets = { TRANSCODER_A_OFFSET, TRANSCODER_B_OFFSET, \
> > > -TRANSCODER_C_OFFSET, TRANSCODER_EDP_OFFSET }
> > > + .pipe_offsets = { \
> > > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > > + [TRANSCODER_B] = PIPE_B_OFFSET, \
> > > + [TRANSCODER_C] = PIPE_C_OFFSET, \
> > > + [TRANSCODER_EDP] = PIPE_EDP_OFFSET, \
> > 
> > Hmm. We do define this as int pipe_offsets[I915_MAX_TRANSCODERS], and
> > PIPECONF/TRANSCONF is per-transcoder so I suppose using TRANSCODER_foo
> > here make sense.
> > 
> > Couple of things that came to mind while thinking about this:
> > - pipe_offsets[] & co. could probably be u32 since we don't
> >   need negative values
> 
> Ok, can follow up with that.
> 
> > - _PIPE_EDP could be removed, which would maybe shrink a few
> >   arrays based on I915_MAX_PIPES
> 
> Agreed. Looks like all the users are in gvt:
> 
> - PIPECONF(_PIPE_EDP) should use PIPECONF(TRANSCODER_EDP) instead. The
>   current code would also break if we added a new transcoder.

yeah, agreed.

> - AFAICS
>   PIPEDSL(_PIPE_EDP)
>   PIPESTAT(_PIPE_EDP)
>   PIPE_FRMCOUNT_G4X(_PIPE_EDP)
>   PIPE_FLIPCOUNT_G4X(_PIPE_EDP)
>   are bogus, since these registers don't exist.
>

Thanks for pointing this out, looks they were added in very beginning,
will remove those after double check.

thanks

> Adding gvt folks for these.
> 
> > 
> > Patch is
> > Reviewed-by: Ville Syrjälä 
> > 
> > > + }, \
> > > + .trans_offsets = { \
> > > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > > + [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> > > + [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
> > > + [TRANSCODER_EDP] = TRANSCODER_EDP_OFFSET, \
> > > + }
> > >  
> > >  #define GEN_CHV_PIPEOFFSETS \
> > > - .pipe_offsets = { PIPE_A_OFFSET, PIPE_B_OFFSET, \
> > > -   CHV_PIPE_C_OFFSET }, \
> > > - .trans_offsets = { TRANSCODER_A_OFFSET, TRANSCODER_B_OFFSET, \
> > > -CHV_TRANSCODER_C_OFFSET }
> > > + .pipe_offsets = { \
> > > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > > + [TRANSCODER_B] = PIPE_B_OFFSET, \
> > > + [TRANSCODER_C] = CHV_PIPE_C_OFFSET, \
> > > + }, \
> > > + .trans_offsets = { \
> > > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > > + [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> > > + [TRANSCODER_C] = CHV_TRANSCODER_C_OFFSET, \
> > > + }
> > >  
> > >  #define CURSOR_OFFSETS \
> > >   .cursor_offsets = { CURSOR_A_OFFSET, CURSOR_B_OFFSET, 
> > > CHV_CURSOR_C_OFFSET }
> > > @@ -592,12 +606,22 @@ static const struct intel_device_info 
> > > intel_cannonlake_info = {
> > >  
> > >  #define GEN11_FEATURES \
> > >   GEN10_FEATURES, \
> > > - .pipe_offsets = { PIPE_A_OFFSET, PIPE_B_OFFSET, \
> > > -   PIPE_C_OFFSET, PIPE_EDP_OFFSET, \
> > > -   PIPE_DSI0_OFFSET, PIPE_DSI1_OFFSET }, \
> > > - .trans_offsets = { TRANSCODER_A_OFFSET, TRANSCODER_B_OFFSET, \
> > > -TRANSCODER_C_OFFSET, TRANSCODER_EDP_OFFSET, \
> > > -TRANSCODER_DSI0_OFFSET, TRANSCODER_DSI1_OFFSET}, \
> > > + .pipe_offsets = { \
> > > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > > + [TRANSCODER_B] = PIPE_B_OFFSET, \
> > > + [TRANSCODER_C] = PIPE_C_OFFSET, \
> > > + [TRANSCODER_EDP] = PIPE_EDP_OFFSET, \
> > > + [TRANSCODER_DSI_0] = PIPE_DSI0_OFFSET, \
> > > + [TRANSCODER_DSI_1] = PIPE_DSI1_OFFSET, \
> > > + }, \
> > > + .trans_offsets = { \
> > > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > > + [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> > > + [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
> > > + [TRANSCODER_EDP] = TRANSCODER_EDP_OFFSET, \
> > > + [TRANSCODER_DSI_0] = TRANSCODER_DSI0_OFFSET, \
> > > + [TRANSCODER_DSI_1] = 

Re: [Intel-gfx] [PATCH] drm/i915: Hide enable_gvt modparam when not compiled in

[Zhenyu Wang]

On 2018.11.16 16:44:47 +0200, Joonas Lahtinen wrote:
> Hide the enable_gvt modparam in the default scenario where
> support has not been compiled in.
> 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Chris Wilson 
> Signed-off-by: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_params.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 8d71886b5f03..2e0356561839 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -167,8 +167,10 @@ i915_param_named_unsafe(inject_load_failure, uint, 0400,
>  i915_param_named(enable_dpcd_backlight, bool, 0600,
>   "Enable support for DPCD backlight control (default:false)");
>  
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT)
>  i915_param_named(enable_gvt, bool, 0400,
>   "Enable support for Intel GVT-g graphics virtualization host 
> support(default:false)");
> +#endif
>  
>  static __always_inline void _print_param(struct drm_printer *p,
>const char *name,

I'm thinking we'd better to remove gvt parameter but depends on kernel
config only in considering of current state and be easier to try, or
better to be handled by gvt module split which will remove this
anyway, so

Acked-by: Zhenyu Wang 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/8] drm/i915: get ready of memory for pvmmio

[Zhenyu Wang]

On 2018.11.13 16:35:14 +0800, Xiaolin Zhang wrote:
> To enable pvmmio feature, we need to prepare one 4K shared page
> which will be accessed by both guest and backend i915 driver used for
> data exchagne.
> 
> the layout of shared_page also defined as well in this patch.
> 
> guest i915 will allocate one page memory and then pass this page's physical
> address to backend i915 driver through PVINFO register so that backend i915
> driver can access this shared page without hypeviser trap cost
> for shared data exchagne via hyperviser read_gpa functionality.
> 
> v0: RFC
> v1: addressed RFC comment to move both shared_page_lock and shared_page
> to i915_virtual_gpu structure
> v2: packed i915_virtual_gpu structure
> v3: added SHARED_PAGE_SETUP g2v notification for pv shared_page setup
> 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: He Min 
> Cc: Jiang Fei 
> Cc: Gong Zhipeng 
> Cc: Yuan Hang 
> Cc: Zhiyuan Lv 
> Signed-off-by: Xiaolin Zhang 
> ---
>  drivers/gpu/drm/i915/i915_drv.c|  2 ++
>  drivers/gpu/drm/i915/i915_drv.h|  4 +++-
>  drivers/gpu/drm/i915/i915_pvinfo.h | 29 -
>  drivers/gpu/drm/i915/i915_vgpu.c   | 23 +++
>  4 files changed, 56 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index baac35f..557ab67 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -987,6 +987,8 @@ static void i915_mmio_cleanup(struct drm_i915_private 
> *dev_priv)
>  
>   intel_teardown_mchbar(dev_priv);
>   pci_iounmap(pdev, dev_priv->regs);
> + if (intel_vgpu_active(dev_priv) && dev_priv->vgpu.shared_page)
> + free_page((unsigned long)dev_priv->vgpu.shared_page);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7b2d7cb..d7a972f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1345,7 +1345,9 @@ struct i915_virtual_gpu {
>   bool active;
>   u32 caps;
>   u32 pv_caps;
> -};
> + spinlock_t shared_page_lock;
> + struct gvt_shared_page *shared_page;
> +} __packed;
>  
>  /* used in computing the new watermarks state */
>  struct intel_wm_config {
> diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
> b/drivers/gpu/drm/i915/i915_pvinfo.h
> index 78a4b9c..aa5eebc 100644
> --- a/drivers/gpu/drm/i915/i915_pvinfo.h
> +++ b/drivers/gpu/drm/i915/i915_pvinfo.h
> @@ -24,6 +24,8 @@
>  #ifndef _I915_PVINFO_H_
>  #define _I915_PVINFO_H_
>  
> +#include "i915_gem.h"
> +
>  /* The MMIO offset of the shared info between guest and host emulator */
>  #define VGT_PVINFO_PAGE  0x78000
>  #define VGT_PVINFO_SIZE  0x1000
> @@ -46,9 +48,29 @@ enum vgt_g2v_type {
>   VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,
>   VGT_G2V_EXECLIST_CONTEXT_CREATE,
>   VGT_G2V_EXECLIST_CONTEXT_DESTROY,
> + VGT_G2V_SHARED_PAGE_SETUP,
>   VGT_G2V_MAX,
>  };
>  
> +struct pv_ppgtt_update {
> + u64 pdp;
> + u64 start;
> + u64 length;
> + u32 cache_level;
> +};
> +
> +/*
> + * shared page(4KB) between gvt and VM, could be allocated by guest driver
> + * or a fixed location in PCI bar 0 region
> + */
> +struct gvt_shared_page {
> + u32 reg_addr;
> + u32 elsp_data[I915_NUM_ENGINES * 4];

You can't rely on I915_NUM_ENGINES, which may be changed so that would
cause incompatibility in shared page definition.

> + u32 ring_id;
> + u32 disable_irq;
> + struct pv_ppgtt_update pv_ppgtt;
> +};
> +
>  /*
>   * VGT capabilities type
>   */
> @@ -121,7 +143,12 @@ struct vgt_if {
>  
>   u32 pvmmio_caps;
>  
> - u32  rsv7[0x200 - 25];/* pad to one page */
> + struct {
> + u32 lo;
> + u32 hi;
> + } shared_page_gpa;
> +
> + u32  rsv7[0x200 - 27];/* pad to one page */
>  } __packed;
>  
>  #define vgtif_reg(x) \
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 219c7c0..63f70bf 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -63,6 +63,7 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
>   u64 magic;
>   u16 version_major;
>   u32 gvt_caps;
> + u64 gpa;
>  
>   BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>  
> @@ -95,6 +96,28 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
>   if (!dev_priv->vgpu.pv_caps)
>   return;
>  
> + dev_priv->vgp

[Intel-gfx] [PULL] gvt-fixes for 4.20-rc2

[Zhenyu Wang]

Hi,

Here's re-generated -fixes pull for 4.20. Mostly on fixing
possible guest arbitrary update of GGTT entries, with one mask
fix for chicken register, and with one to fix eDP warning in guest.

Thanks.
--
The following changes since commit 7759ca3aac79648d01c9edcb3b00503c02bec2f5:

  drm/i915/gvt: clear ggtt entries when destroy vgpu (2018-09-18 10:39:44 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-11-07

for you to fetch changes up to 5e7154ff5e8e21dc9acac4f8dba7533552365374:

  drm/i915/gvt: Handle values of EDP_PSR_IMR and EDP_PSR_IIR (2018-10-31 
17:09:46 +0800)


gvt-fixes-2018-11-07

- Fix invalidate of old ggtt entry (Hang)
- Fix partial ggtt entry update in any order (Hang)
- Fix one mask setting for chicken reg (Xinyun)
- Fix eDP warning in guest (Longhe)


Hang Yuan (2):
  drm/i915/gvt: invalidate old ggtt page when update ggtt entry
  drm/i915/gvt: support inconsecutive partial gtt entry write

Longhe Zheng (1):
  drm/i915/gvt: Handle values of EDP_PSR_IMR and EDP_PSR_IIR

Xinyun Liu (1):
  drm/i915/gvt: correct mask setting for CSFE_CHICKEN1

 drivers/gpu/drm/i915/gvt/gtt.c  | 115 
 drivers/gpu/drm/i915/gvt/gtt.h  |   9 ++-
 drivers/gpu/drm/i915/gvt/handlers.c |   8 +--
 drivers/gpu/drm/i915/gvt/mmio_context.c |   2 +-
 4 files changed, 70 insertions(+), 64 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gtt: Revert "Disable read-only support under GVT"

[Zhenyu Wang]

On 2018.10.30 15:08:01 +0800, intel-gfx-boun...@lists.freedesktop.org wrote:
> From: Hang Yuan 
> 
> This reverts commit c9e666880de5a1fed04dc412b046916d542b72dd.
> 
> Checked GVT codes that guest PPGTT PTE flag bits are propagated
> to shadow PTE. Read/write bit is not changed. Further tested by
> i915 self-test case "igt_ctx_readonly". No error or GPU hang was
> detected. So enable read-only support under GVT.
> 
> Signed-off-by: Hang Yuan 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 19b2d99..bdf9f9f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1602,12 +1602,8 @@ static struct i915_hw_ppgtt *gen8_ppgtt_create(struct 
> drm_i915_private *i915)
>   1ULL << 48 :
>   1ULL << 32;
>  
> - /*
> -  * From bdw, there is support for read-only pages in the PPGTT.
> -  *
> -  * XXX GVT is not honouring the lack of RW in the PTE bits.
> -  */
> - ppgtt->vm.has_read_only = !intel_vgpu_active(i915);
> + /* From bdw, there is support for read-only pages in the PPGTT. */
> + ppgtt->vm.has_read_only = true;
>  
>   i915_address_space_init(>vm, i915);
>  

In consider we have that shadow logic from initial of gvt support,
this is ok.

Acked-by: Zhenyu Wang 

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next-fixes for 4.20

[Zhenyu Wang]

On 2018.10.25 16:07:14 +0300, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2018-10-23 06:46:59)
> > 
> > Hi,
> > 
> > Here's gvt-next-fixes for 4.20 with three changes. Mostly
> > to fix possible arbitrary update on guest GGTT entry and
> > with proper invalidate of old entry. Another one for one
> > chicken reg mask fix.
> > 
> > thanks
> 
> Hi,
> 
> DIM seems to be (rightfully) complaining about one commit:
> 
> 3e740f0ec37acecaa364c19d2d2826df83c8bf20 is lacking committer of sign-off
> 
> Probably better if you re-submit the PR for -fixes (rebased for
> v4.20-rc1).
> 

Looks -fixes is still 4.19? So I still regenerate against -next-fixes,
let me know if that's ok for you.

Thanks
--

The following changes since commit 835fe6d75d14c1513910ed7f5665127fee12acc8:

  firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake. (2018-10-18 
10:36:10 +0300)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-10-26

for you to fetch changes up to 348589205265049eda2e365371eec18d56809699:

  drm/i915/gvt: correct mask setting for CSFE_CHICKEN1 (2018-10-26 10:57:48 
+0800)


gvt-next-fixes-2018-10-26

- Fix invalidate of old ggtt entry (Hang)
- Fix partial ggtt entry update in any order (Hang)
- Fix one mask setting for chicken reg (Xinyun)


Hang Yuan (2):
  drm/i915/gvt: invalidate old ggtt page when update ggtt entry
  drm/i915/gvt: support inconsecutive partial gtt entry write

Xinyun Liu (1):
  drm/i915/gvt: correct mask setting for CSFE_CHICKEN1

 drivers/gpu/drm/i915/gvt/gtt.c  | 115 
 drivers/gpu/drm/i915/gvt/gtt.h  |   9 ++-
 drivers/gpu/drm/i915/gvt/mmio_context.c |   2 +-
 3 files changed, 66 insertions(+), 60 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next-fixes for 4.20

[Zhenyu Wang]

On 2018.10.25 11:28:28 -0700, Rodrigo Vivi wrote:
> On Thu, Oct 25, 2018 at 04:07:14PM +0300, Joonas Lahtinen wrote:
> > Quoting Zhenyu Wang (2018-10-23 06:46:59)
> > > 
> > > Hi,
> > > 
> > > Here's gvt-next-fixes for 4.20 with three changes. Mostly
> > > to fix possible arbitrary update on guest GGTT entry and
> > > with proper invalidate of old entry. Another one for one
> > > chicken reg mask fix.
> > > 
> > > thanks
> > 
> > Hi,
> > 
> > DIM seems to be (rightfully) complaining about one commit:
> > 
> > 3e740f0ec37acecaa364c19d2d2826df83c8bf20 is lacking committer of sign-off
> 
> This is something I'm asking gvt for a while already:
> Please make review mandatory on your side.
>

yes, we are appling review process more strictly on gvt side,
that one should be reviewed by Zhi when I was offline, but he
seems forget to add r-b and I forgot to sign-off...Sorry for that,
will regenerate.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next-fixes for 4.20

[Zhenyu Wang]

Hi,

Here's gvt-next-fixes for 4.20 with three changes. Mostly
to fix possible arbitrary update on guest GGTT entry and
with proper invalidate of old entry. Another one for one
chicken reg mask fix.

thanks
--
The following changes since commit 835fe6d75d14c1513910ed7f5665127fee12acc8:

  firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake. (2018-10-18 
10:36:10 +0300)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-10-23

for you to fetch changes up to 3e740f0ec37acecaa364c19d2d2826df83c8bf20:

  drm/i915/gvt: correct mask setting for CSFE_CHICKEN1 (2018-10-19 11:32:41 
+0800)


gvt-next-fixes-2018-10-23

- Fix invalidate of old ggtt entry (Hang)
- Fix partial ggtt entry update in any order (Hang)
- Fix one mask setting for chicken reg (Xinyun)


Hang Yuan (2):
  drm/i915/gvt: invalidate old ggtt page when update ggtt entry
  drm/i915/gvt: support inconsecutive partial gtt entry write

Xinyun Liu (1):
  drm/i915/gvt: correct mask setting for CSFE_CHICKEN1

 drivers/gpu/drm/i915/gvt/gtt.c  | 115 
 drivers/gpu/drm/i915/gvt/gtt.h  |   9 ++-
 drivers/gpu/drm/i915/gvt/mmio_context.c |   2 +-
 3 files changed, 66 insertions(+), 60 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add ppgtt to GVT GEM context

[Zhenyu Wang]

On 2018.10.18 13:40:31 +0800, Xiong Zhang wrote:
> Currently the guest couldn't boot up under GVT-g environment as the
> following call trace exists:
> [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 
> 0100
> [  272.504834] Call Trace:
> [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> 
> GVT GEM context is created by i915_gem_context_create_gvt() which
> doesn't allocate ppgtt. So GVT GEM context structure doesn't have
> a valid i915_hw_ppgtt.
> 
> This patch create ppgtt table at GVT GEM context creation, then assign
> shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
> be used on GPU. So GVT GEM context has valid ppgtt address. But note
> that this ppgtt only contain valid ppgtt root table address, the table
> entry in this ppgtt structure are invalid.
> 
> Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for 
> execlists")
> 
> Signed-off-by: Xiong Zhang 
> Reviewed-by: Zhenyu Wang 

Any more comment for this? We need it for current gvt broken on drm-tip,
and it requires to change i915 for gvt ppgtt allocation, so I assume it's
better to be merged by i915 directly, or do you like a gvt pull instead?

Thanks.

> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c| 29 +
>  drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index ea34003..b7e0529 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -334,6 +334,29 @@ static void release_shadow_wa_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
>  }
>  
> +static int set_context_ppgtt_from_shadow(struct intel_vgpu_workload 
> *workload,
> +  struct i915_gem_context *ctx)
> +{
> + struct intel_vgpu_mm *mm = workload->shadow_mm;
> + struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
> + int i = 0;
> +
> + if (mm->type != INTEL_GVT_MM_PPGTT ||
> + !mm->ppgtt_mm.shadowed)
> + return -1;
> +
> + if (mm->ppgtt_mm.root_entry_type == GTT_TYPE_PPGTT_ROOT_L4_ENTRY)
> + px_dma(>pml4) = mm->ppgtt_mm.shadow_pdps[0];
> + else {
> + for (i = 0; i < GVT_RING_CTX_NR_PDPS; i++) {
> + px_dma(ppgtt->pdp.page_directory[i]) =
> + mm->ppgtt_mm.shadow_pdps[i];
> + }
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * intel_gvt_scan_and_shadow_workload - audit the workload by scanning and
>   * shadow it as well, include ringbuffer,wa_ctx and ctx.
> @@ -358,6 +381,12 @@ int intel_gvt_scan_and_shadow_workload(struct 
> intel_vgpu_workload *workload)
>   if (workload->req)
>   return 0;
>  
> + ret = set_context_ppgtt_from_shadow(workload, shadow_ctx);
> + if (ret < 0) {
> + gvt_vgpu_err("workload shadow ppgtt isn't ready\n");
> + return ret;
> + }
> +
>   /* pin shadow context by gvt even the shadow context will be pinned
>* when i915 alloc request. That is because gvt will update the guest
>* context from shadow context when workload is completed, and at that
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 8cbe580..b97963d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -457,7 +457,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
>   if (ret)
>   return ERR_PTR(ret);
>  
> - ctx = __create_hw_context(to_i915(dev), NULL);
> + ctx = i915_gem_create_context(to_i915(dev), NULL);
>   if (IS_ERR(ctx))
>   goto out;
>  
> -- 
> 2.7.4
> 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add ppgtt to GVT GEM context

[Zhenyu Wang]

On 2018.10.15 12:50:50 +0800, Xiong Zhang wrote:
> Currently the guest couldn't boot up under GVT-g environment as the
> following call trace exists:
> [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 
> 0100
> [  272.504834] Call Trace:
> [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> 
> GVT GEM context is created by i915_gem_context_create_gvt() which
> doesn't allocate ppgtt. So GVT GEM context structure doesn't have
> a valid i915_hw_ppgtt.
> 
> This patch create ppgtt table at GVT GEM context creation, then assign
> shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
> be used on GPU. So GVT GEM context has valid ppgtt address. But note
> that this ppgtt only contain valid ppgtt root table address, the table
> entry in this ppgtt structure are invalid.
> 
> Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for 
> execlists")
> 
> Signed-off-by: Xiong Zhang 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c| 29 +
>  drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index ea34003..b7e0529 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -334,6 +334,29 @@ static void release_shadow_wa_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
>  }
>

We may better add comment for this one as currently it might
not be real root pointer for gvt context, so won't confuse people
later. Others looks fine to me. Thanks!

Reviewed-by: Zhenyu Wang 

> +static int set_context_ppgtt_from_shadow(struct intel_vgpu_workload 
> *workload,
> +  struct i915_gem_context *ctx)
> +{
> + struct intel_vgpu_mm *mm = workload->shadow_mm;
> + struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
> + int i = 0;
> +
> + if (mm->type != INTEL_GVT_MM_PPGTT ||
> + !mm->ppgtt_mm.shadowed)
> + return -1;
> +
> + if (mm->ppgtt_mm.root_entry_type == GTT_TYPE_PPGTT_ROOT_L4_ENTRY)
> + px_dma(>pml4) = mm->ppgtt_mm.shadow_pdps[0];
> + else {
> + for (i = 0; i < GVT_RING_CTX_NR_PDPS; i++) {
> + px_dma(ppgtt->pdp.page_directory[i]) =
> + mm->ppgtt_mm.shadow_pdps[i];
> + }
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * intel_gvt_scan_and_shadow_workload - audit the workload by scanning and
>   * shadow it as well, include ringbuffer,wa_ctx and ctx.
> @@ -358,6 +381,12 @@ int intel_gvt_scan_and_shadow_workload(struct 
> intel_vgpu_workload *workload)
>   if (workload->req)
>   return 0;
>  
> + ret = set_context_ppgtt_from_shadow(workload, shadow_ctx);
> + if (ret < 0) {
> + gvt_vgpu_err("workload shadow ppgtt isn't ready\n");
> + return ret;
> + }
> +
>   /* pin shadow context by gvt even the shadow context will be pinned
>* when i915 alloc request. That is because gvt will update the guest
>* context from shadow context when workload is completed, and at that
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 8cbe580..b97963d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -457,7 +457,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
>   if (ret)
>   return ERR_PTR(ret);
>  
> - ctx = __create_hw_context(to_i915(dev), NULL);
> + ctx = i915_gem_create_context(to_i915(dev), NULL);
>   if (IS_ERR(ctx))
>   goto out;
>  
> -- 
> 2.7.4
> 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check ppgtt validity for GVT GEM context

[Zhenyu Wang]

On 2018.10.11 07:23:11 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-10-11 03:45:07)
> > On 2018.10.09 14:08:20 +0800, Xiong Zhang wrote:
> > > The guest couldn't boot up under GVT-g environment as the following call
> > > trace exists:
> > > [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 
> > > 0100
> > > [  272.504834] Call Trace:
> > > [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> > > [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> > > [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> > > [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> > > [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> > > [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> > > [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> > > [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> > > [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> > > 
> > > GVT GEM context is created by i915_gem_context_create_gvt() which doesn't
> > > allocate ppgtt. So GVT GEM context structure doesn't have a valid
> > > i915_hw_ppgtt.
> > > 
> > > GVT maintain a shadow ppgtt for each guest ppgtt, and attach this shadow
> > > ppgtt to gpu when the corresponding guest ppgtt will be scheduled onto 
> > > gpu.
> > > The structure of shadow ppgtt is different from i915_hw_ppgtt, a lot of 
> > > gvt
> > > refactor work should be done in order to use i915_hw_ppgtt structure.
> > > So let's fix the regression first.
> > > 
> > > Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for 
> > > execlists")
> > > 
> > > Signed-off-by: Xiong Zhang 
> > > ---
> > 
> > Chris, any comment? Without this, current gvt breaks on drm tip with kernel 
> > oops.
> > Could we fix the regression first then check gvt ctx stub ppgtt handling 
> > later?
> > Which would require more change on gvt side, not sure if need any more 
> > helper from
> > i915 ppgtt code with a clean fix..
> 
> We both thought this wasn't the approach we wanted to take. My position
> is that this leaves the registers ostensibly programmed to garbage.

yeah, I agree that's not ideal, my point is that would bring more changes e.g
gvt ctx create function need to be changed accordingly, etc. and I'm
disappointed why CI didn't catch this in first place, as Terrence has
contributed GVT guest boot test in igt, we need to add that for list patch
checking!

Current gvt nightly test is using this one to kick, we'll see if a quick
mitigation can be made.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check ppgtt validity for GVT GEM context

[Zhenyu Wang]

On 2018.10.09 14:08:20 +0800, Xiong Zhang wrote:
> The guest couldn't boot up under GVT-g environment as the following call
> trace exists:
> [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 
> 0100
> [  272.504834] Call Trace:
> [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> 
> GVT GEM context is created by i915_gem_context_create_gvt() which doesn't
> allocate ppgtt. So GVT GEM context structure doesn't have a valid
> i915_hw_ppgtt.
> 
> GVT maintain a shadow ppgtt for each guest ppgtt, and attach this shadow
> ppgtt to gpu when the corresponding guest ppgtt will be scheduled onto gpu.
> The structure of shadow ppgtt is different from i915_hw_ppgtt, a lot of gvt
> refactor work should be done in order to use i915_hw_ppgtt structure.
> So let's fix the regression first.
> 
> Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for 
> execlists")
> 
> Signed-off-by: Xiong Zhang 
> ---

Chris, any comment? Without this, current gvt breaks on drm tip with kernel 
oops.
Could we fix the regression first then check gvt ctx stub ppgtt handling later?
Which would require more change on gvt side, not sure if need any more helper 
from
i915 ppgtt code with a clean fix..

Thanks

>  drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ff0e2b3..d604d8a 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -385,7 +385,7 @@ static u64 execlists_update_context(struct i915_request 
> *rq)
>* PML4 is allocated during ppgtt init, so this is not needed
>* in 48-bit mode.
>*/
> - if (!i915_vm_is_48bit(>vm))
> + if (ppgtt && !i915_vm_is_48bit(>vm))
>   execlists_update_context_pdps(ppgtt, reg_state);
>  
>   return ce->lrc_desc;
> @@ -1210,7 +1210,6 @@ execlists_context_pin(struct intel_engine_cs *engine,
>   struct intel_context *ce = to_intel_context(ctx, engine);
>  
>   lockdep_assert_held(>i915->drm.struct_mutex);
> - GEM_BUG_ON(!ctx->ppgtt);
>  
>   if (likely(ce->pin_count++))
>   return ce;
> @@ -2538,7 +2537,7 @@ static void execlists_init_reg_state(u32 *regs,
>   CTX_REG(regs, CTX_PDP0_UDW, GEN8_RING_PDP_UDW(engine, 0), 0);
>   CTX_REG(regs, CTX_PDP0_LDW, GEN8_RING_PDP_LDW(engine, 0), 0);
>  
> - if (i915_vm_is_48bit(>ppgtt->vm)) {
> + if (ctx->ppgtt && i915_vm_is_48bit(>ppgtt->vm)) {
>   /* 64b PPGTT (48bit canonical)
>* PDP0_DESCRIPTOR contains the base address to PML4 and
>* other PDP Descriptors are ignored.
> -- 
> 2.7.4
> 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 02/10] drm/i915/gvt: get ready of memory for pvmmio

[Zhenyu Wang]

On 2018.09.27 12:37:47 -0400, Xiaolin Zhang wrote:
> To enable pvmmio feature, we need to prepare one 4K shared page
> which will be accessed by both guest and backend i915 driver.
> 
> guest i915 allocate one page memory and then the guest physical address is
> passed to backend i915 driver through PVINFO register so that backend i915
> driver can access this shared page without hypeviser trap cost for shared
> data exchagne via hyperviser read_gpa functionality.
> 
> Signed-off-by: Xiaolin Zhang 
> ---
>  drivers/gpu/drm/i915/i915_drv.c|  5 +
>  drivers/gpu/drm/i915/i915_drv.h|  3 +++
>  drivers/gpu/drm/i915/i915_pvinfo.h | 25 -
>  drivers/gpu/drm/i915/i915_vgpu.c   | 17 +
>  4 files changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ade9bca..815a4dd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -885,6 +885,7 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv)
>   return -ENODEV;
>  
>   spin_lock_init(_priv->irq_lock);
> + spin_lock_init(_priv->shared_page_lock);
>   spin_lock_init(_priv->gpu_error.lock);
>   mutex_init(_priv->backlight_lock);
>   spin_lock_init(_priv->uncore.lock);
> @@ -987,6 +988,8 @@ static void i915_mmio_cleanup(struct drm_i915_private 
> *dev_priv)
>  
>   intel_teardown_mchbar(dev_priv);
>   pci_iounmap(pdev, dev_priv->regs);
> + if (intel_vgpu_active(dev_priv) && dev_priv->shared_page)
> + free_pages((unsigned long)dev_priv->shared_page, 0);
>  }
>  
>  /**
> @@ -1029,6 +1032,8 @@ static int i915_driver_init_mmio(struct 
> drm_i915_private *dev_priv)
>   return 0;
>  
>  err_uncore:
> + if (intel_vgpu_active(dev_priv) && dev_priv->shared_page)
> + free_pages((unsigned long)dev_priv->shared_page, 0);
>   intel_uncore_fini(dev_priv);
>  err_bridge:
>   pci_dev_put(dev_priv->bridge_dev);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 174d618..76d7e9c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -56,6 +56,7 @@
>  
>  #include "i915_params.h"
>  #include "i915_reg.h"
> +#include "i915_pvinfo.h"
>  #include "i915_utils.h"
>  
>  #include "intel_bios.h"
> @@ -1623,6 +1624,8 @@ struct drm_i915_private {
>   resource_size_t stolen_usable_size; /* Total size minus reserved 
> ranges */
>  
>   void __iomem *regs;
> + struct gvt_shared_page *shared_page;
> + spinlock_t shared_page_lock;
>  
>   struct intel_uncore uncore;
>  
> diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
> b/drivers/gpu/drm/i915/i915_pvinfo.h
> index 697e998..ab839a7 100644
> --- a/drivers/gpu/drm/i915/i915_pvinfo.h
> +++ b/drivers/gpu/drm/i915/i915_pvinfo.h
> @@ -49,6 +49,25 @@ enum vgt_g2v_type {
>   VGT_G2V_MAX,
>  };
>  
> +struct pv_ppgtt_update {
> + u64 pdp;
> + u64 start;
> + u64 length;
> + u32 cache_level;
> +};
> +
> +/*
> + * shared page(4KB) between gvt and VM, could be allocated by guest driver
> + * or a fixed location in PCI bar 0 region
> + */
> +struct gvt_shared_page {
> + u32 elsp_data[4];
> + u32 reg_addr;
> + u32 disable_irq;
> + struct pv_ppgtt_update pv_ppgtt;
> + u32 rsvd2[0x400 - 13];
> +};

Could we define offset for shared page fields instead of a struct?
Which is wasting space I think.

> +
>  #define VGPU_PVMMIO(vgpu) vgpu_vreg_t(vgpu, vgtif_reg(enable_pvmmio))
>  
>  /*
> @@ -120,8 +139,12 @@ struct vgt_if {
>   u32 execlist_context_descriptor_lo;
>   u32 execlist_context_descriptor_hi;
>   u32 enable_pvmmio;
> + struct {
> + u32 lo;
> + u32 hi;
> + } shared_page_gpa;
>  
> - u32  rsv7[0x200 - 25];/* pad to one page */
> + u32  rsv7[0x200 - 27];/* pad to one page */
>  } __packed;
>  
>  #define vgtif_reg(x) \
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index d22c5ca..10ae94b 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -62,6 +62,7 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
>  {
>   u64 magic;
>   u16 version_major;
> + u64 shared_page_gpa;
>  
>   BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>  
> @@ -89,6 +90,22 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
>   dev_priv->vgpu.active = true;
>   DRM_INFO("Virtual GPU for Intel GVT-g detected with pvmmio 0x%x\n",
>   i915_modparams.enable_pvmmio);
> +
> + if (intel_vgpu_active(dev_priv) && i915_modparams.enable_pvmmio) {
> + dev_priv->shared_page =  (struct gvt_shared_page *)
> + __get_free_pages(GFP_KERNEL | __GFP_ZERO, 0);
> + if (!dev_priv->shared_page) {
> + DRM_ERROR("out of memory for shared page 

Re: [Intel-gfx] [RFC 01/10] drm/i915/gvt: add module parameter enable_pvmmio

[Zhenyu Wang]

On 2018.09.28 14:09:45 +0800, Zhang, Xiaolin wrote:
> On 09/27/2018 07:03 PM, Joonas Lahtinen wrote:
> > Quoting Xiaolin Zhang (2018-09-27 19:37:46)
> >> This int type module parameter is used to control the different
> >> level pvmmio feature for MMIO emulation in GVT.
> >>
> >> This parameter is default zero, no pvmmio feature enabled.
> >>
> >> Its permission type is 0400 which means user could only change its
> >> value through the cmdline, this is to prevent the dynamic modification
> >> during runtime which would break the pvmmio internal logic.
> >>
> >> Signed-off-by: Xiaolin Zhang 
> > This shouldn't really be a module parameter. We should detect the
> > capability from the vGPU device and use it always when possible.
> >
> > Regards, Joonas
> >
> for pv optimization, we should touch both guest driver and GVTg.  this
> parameter is used for
> 
> guest pv capability because GVTg with pv capability will support both pv
> and non pv capability guest.
> 

That's the purpose of 'vgt_caps' in PVINFO to do capability check between
host/guest. You need a new cap bit definition for PVMMIO and maybe another
field for different PVMMIO level capability check. New parameter is not useful 
here.

Thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Remove i915.enable_ppgtt override

[Zhenyu Wang]

On 2018.10.08 13:58:25 +, Wang, Zhi A wrote:
> Thanks for pointing this. My bad.
> 
> I take a look on the code and it looks like the GVT-g context is now quite 
> similar with the kernel context except the force single submission and ring 
> buffer size. (When we upstream the code, there was no kernel context at that 
> time. :/) Now there is already one API for single submission. If we can 
> introduce another one to configure the ring buffer size. Then maybe we can 
> remove the *create_gvt() in i915_gem_context.c and used kernel context 
> instead.
> 
> Feel free to drop comments. :)
>

For ppgtt, you'd better change to use i915 ppgtt interface to handle
shadow pages, then gvt context would be much like normal one.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Remove i915.enable_ppgtt override

[Zhenyu Wang]

On 2018.09.26 11:02:15 +0300, Joonas Lahtinen wrote:
> Quoting He, Min (2018-09-26 04:06:25)
> > No. We changed to full 48bit ppgtt long time ago. :)
> 
> So would that mean the change is OK to do?

Looks that one unfortunately caused gvt regression, gvt context has
no i915 managed i915_hw_ppgtt but only shadowed one, so need to check
if ppgtt is valid before access.

> 
> Acked-by from you, Zhi, would be good to have for documentation purposes
> in that case :)
> 
> Regards, Joonas
> 
> > 
> > > -Original Message-
> > > From: Wang, Zhi A
> > > Sent: Wednesday, September 26, 2018 2:01 AM
> > > To: Joonas Lahtinen ; Chris Wilson
> > > ; intel-gfx@lists.freedesktop.org; Zhenyu Wang
> > > 
> > > Cc: Auld, Matthew ; He, Min 
> > > Subject: Re: [PATCH v4] drm/i915: Remove i915.enable_ppgtt override
> > > 
> > > Hi Min:
> > > 
> > > I remembered the IOTG guest kernel is using aliasing-ppgtt in the last
> > > technical sharing (probably I didn't remember it correctly). Can you
> > > confirm?
> > > 
> > > Also, thanks Joonas for the reminding. :)
> > > 
> > > thanks,
> > > Zhi.
> > > 
> > > On 09/25/18 09:22, Joonas Lahtinen wrote:
> > > > + Zhi and Zhenyu
> > > >
> > > > For me the patch looks ok.
> > > >
> > > > It refuses to load GVT on systems where 48-bit is not supported, for not
> > > > worsening the system security when virtualization is enabled (as anybody
> > > > would probably expect virtualization to improve that). Please see code.
> > > >
> > > > Do we have such systems in the wild? Should we instruct the user to
> > > > updating the hypervisor to specific kernel version when they hit the
> > > > error?
> > > >
> > > > Regards, Joonas
> > > >
> > > > Quoting Chris Wilson (2018-09-25 14:48:20)
> > > >> Now that we are confident in providing full-ppgtt where supported,
> > > >> remove the ability to override the context isolation.
> > > >>
> > > >> v2: Remove faked aliasing-ppgtt for testing as it no longer is 
> > > >> accepted.
> > > >> v3: s/USES/HAS/ to match usage and reject attempts to load the module
> > > on
> > > >> old GVT-g setups that do not provide support for full-ppgtt.
> > > >>
> > > >> Signed-off-by: Chris Wilson 
> > > >> Cc: Joonas Lahtinen 
> > > >> Cc: Matthew Auld 
> > > >> ---
> > > >>   drivers/gpu/drm/i915/i915_drv.c   | 22 +++--
> > > >>   drivers/gpu/drm/i915/i915_drv.h   | 14 +--
> > > >>   drivers/gpu/drm/i915/i915_gem_context.c   |  2 +-
> > > >>   drivers/gpu/drm/i915/i915_gem_gtt.c   | 88 
> > > >> ++-
> > > >>   drivers/gpu/drm/i915/i915_gpu_error.c |  4 +-
> > > >>   drivers/gpu/drm/i915/i915_params.c|  4 -
> > > >>   drivers/gpu/drm/i915/i915_params.h|  1 -
> > > >>   drivers/gpu/drm/i915/i915_pci.c   | 17 ++--
> > > >>   drivers/gpu/drm/i915/intel_device_info.c  |  6 ++
> > > >>   drivers/gpu/drm/i915/intel_device_info.h  | 11 ++-
> > > >>   drivers/gpu/drm/i915/intel_lrc.c  | 13 ++-
> > > >>   drivers/gpu/drm/i915/selftests/huge_pages.c   | 12 +--
> > > >>   .../gpu/drm/i915/selftests/i915_gem_context.c | 59 +
> > > >>   .../gpu/drm/i915/selftests/i915_gem_evict.c   |  2 +-
> > > >>   drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  4 +-
> > > >>   15 files changed, 62 insertions(+), 197 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > >> index 44e2c0f5ec50..3efbbc71c3b4 100644
> > > >> --- a/drivers/gpu/drm/i915/i915_drv.c
> > > >> +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > >> @@ -345,7 +345,7 @@ static int i915_getparam_ioctl(struct drm_device
> > > *dev, void *data,
> > > >>  value = HAS_WT(dev_priv);
> > > >>  break;
> > > >>  case I915_PARAM_HAS_ALIASING_PPGTT:
> > > >> -   value = USES_PPGTT(dev_priv);
> > > >> +   value = INTEL_PPGTT(dev_priv);
> > > >> 

[Intel-gfx] [PULL] gvt-fixes for 4.19-rc5

[Zhenyu Wang]

Hi,

Here's more gvt fixes for 4.19. Two more BXT fixes from Colin,
one srcu locking fix and one fix for GGTT clear when destroy vGPU.

p.s, I'll start my vacation from tomorrow. Wang Zhi will cover for gvt pull.

Thanks
--
The following changes since commit 792fab2c0d45758ad3d187bd252570d2bb627fa9:

  drm/i915/gvt: Fix the incorrect length of child_device_config issue 
(2018-09-06 11:17:38 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-09-18

for you to fetch changes up to 7759ca3aac79648d01c9edcb3b00503c02bec2f5:

  drm/i915/gvt: clear ggtt entries when destroy vgpu (2018-09-18 10:39:44 +0800)


gvt-fixes-2018-09-18

- Fix initial DPIO PHY register state for BXT (Colin)
- BXT untracked GEN9_CLKGATE_DIS_4 warning fix (Colin)
- Fix srcu lock for GFN valid check (Weinan)
- Should clear GGTT entry value after vGPU destroy (Zhipeng)


Colin Xu (2):
  drm/i915/gvt: Init PHY related registers for BXT
  drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handler

Weinan Li (1):
  drm/i915/gvt: request srcu_read_lock before checking if one gfn is valid

Zhipeng Gong (1):
  drm/i915/gvt: clear ggtt entries when destroy vgpu

 drivers/gpu/drm/i915/gvt/handlers.c |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c|  7 ++-
 drivers/gpu/drm/i915/gvt/mmio.c | 28 
 drivers/gpu/drm/i915/gvt/vgpu.c |  1 +
 4 files changed, 36 insertions(+), 1 deletion(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC PATCH] drm/i915: split GVT as separated module

[Zhenyu Wang]

Joonas requested if we could move GVT into separated module.
Then obvious requirement is to export i915 functions that GVT
currently use. So this one blindly trys to export all of them
for people to review. Some of them are already only for GVT now.
But more others might need more thinking on what may better fit.

With separated module, this also changes how GVT module loads with
i915. Initial attempt was to request loading GVT module when i915
init, but as for dependence issue that couldn't work. Then I think we
should just enable GVT when user request to load it.  So removed GVT
init from i915, also 'enable_gvt' parameter and call GVT init function
when module load. But for GVT init, we still need struct
drm_i915_private for target device, so this just hacks it to
export..Maybe we can add some interface to get that from i915?

Another problem for separated module is that GVT wants a clean
initial MMIO snapshot for vGPU default state. Now in upstream we
will take that snapshot during GVT init. For separated module, we
might need i915 to dump it for GVT then GVT could get it when init.
This part of change for i915 and GVT is not included in this patch yet.

Cc: Joonas Lahtinen 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/Kconfig  |   2 +-
 drivers/gpu/drm/i915/Makefile |   3 -
 drivers/gpu/drm/i915/gvt/Makefile |   3 +-
 drivers/gpu/drm/i915/gvt/gvt.c|  40 +-
 drivers/gpu/drm/i915/gvt/gvt.h|   3 +
 drivers/gpu/drm/i915/i915_drv.c   |  17 +--
 drivers/gpu/drm/i915/i915_drv.h   |   6 +-
 drivers/gpu/drm/i915/i915_gem.c   |  11 ++
 drivers/gpu/drm/i915/i915_gem_context.c   |   2 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c|   1 +
 drivers/gpu/drm/i915/i915_gem_fence_reg.c |   2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c   |   1 +
 drivers/gpu/drm/i915/i915_params.c|   3 -
 drivers/gpu/drm/i915/i915_params.h|   3 +-
 drivers/gpu/drm/i915/i915_request.c   |   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   2 +
 drivers/gpu/drm/i915/intel_gvt.c  | 143 --
 drivers/gpu/drm/i915/intel_gvt.h  |  50 
 drivers/gpu/drm/i915/intel_ringbuffer.c   |   1 +
 drivers/gpu/drm/i915/intel_runtime_pm.c   |   2 +
 drivers/gpu/drm/i915/intel_uncore.c   |   3 +
 21 files changed, 82 insertions(+), 219 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/intel_gvt.c
 delete mode 100644 drivers/gpu/drm/i915/intel_gvt.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 33a458b7f1fc..a05261cabf53 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -96,7 +96,7 @@ config DRM_I915_USERPTR
  If in doubt, say "Y".
 
 config DRM_I915_GVT
-bool "Enable Intel GVT-g graphics virtualization host support"
+tristate "Enable Intel GVT-g graphics virtualization host support"
 depends on DRM_I915
 depends on 64BIT
 default n
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5794f102f9b8..b3acd431c35e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -182,10 +182,7 @@ i915-y += i915_perf.o \
  i915_oa_cnl.o \
  i915_oa_icl.o
 
-ifeq ($(CONFIG_DRM_I915_GVT),y)
-i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
-endif
 
 # LPE Audio for VLV and CHT
 i915-y += intel_lpe_audio.o
diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index b016dc753db9..a2e1de745d63 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -6,5 +6,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
trace_points.o firmware.o \
fb_decoder.o dmabuf.o page_track.o
 
 ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
-i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
+i915_gvt-y := $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
+obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o
 obj-$(CONFIG_DRM_I915_GVT_KVMGT)   += $(GVT_DIR)/kvmgt.o
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 6ef5a7fc70df..2a6bbc89e20f 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -30,10 +30,11 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
-
+#include 
 #include "i915_drv.h"
 #include "gvt.h"
 #include 
@@ -228,7 +229,6 @@ int intel_gvt_init_host(void)
 
gvt_dbg_core("Running with hypervisor %s in host mode\n",
supported_hypervisors[intel_gvt_host.hypervisor_type]);
-
intel_gvt_host.initialized = true;
return 0;
 }
@@ -467,6 +467,42 @@ int intel_gvt_init_device(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
+static int __init i915_gvt_init(void)
+{
+   if (!try_module_get(i915_priv_export-&

[Intel-gfx] [PULL] gvt-fixes for 4.19-rc4

[Zhenyu Wang]

Hi,

Here's more gvt-fixes for 4.19. Most critical one is to fix
KVM's mm reference when we access guest memory, issue was raised
by Linus in 
https://lists.freedesktop.org/archives/intel-gvt-dev/2018-August/004130.html.
Another one with virtual opregion fix.

Thanks
--
The following changes since commit 54ff01fd0d44b9681615f77c15fe9ea6dfadb501:

  drm/i915/gvt: Give new born vGPU higher scheduling chance (2018-09-03 
14:28:23 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-09-10

for you to fetch changes up to 792fab2c0d45758ad3d187bd252570d2bb627fa9:

  drm/i915/gvt: Fix the incorrect length of child_device_config issue 
(2018-09-06 11:17:38 +0800)


gvt-fixes-2018-09-10

- KVM mm access reference fix (Zhenyu)
- Fix child device config length for virtual opregion (Weinan)


Weinan Li (1):
  drm/i915/gvt: Fix the incorrect length of child_device_config issue

Zhenyu Wang (1):
  drm/i915/gvt: Fix life cycle reference on KVM mm

 drivers/gpu/drm/i915/gvt/kvmgt.c| 10 --
 drivers/gpu/drm/i915/gvt/opregion.c | 20 +---
 2 files changed, 17 insertions(+), 13 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next for 4.20

[Zhenyu Wang]

On 2018.09.06 16:11:20 +0300, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2018-09-04 06:01:54)
> > 
> > Hi,
> > 
> > Here's initial gvt-next for 4.20 with two optimization for
> > guest context shadowing and command parser, and with W=1 build fixes.
> 
> Thanks, pulled this, but it had one merge conflict (in gvt/reg.h).
> Please make sure the resolution I put in into drm-intel-next is correct.
> 

yeah, forgot to mention conflict with recent PCH reg define
change. Merge change is correct.

Thanks!

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next for 4.20

[Zhenyu Wang]

Hi,

Here's initial gvt-next for 4.20 with two optimization for
guest context shadowing and command parser, and with W=1 build fixes.

Thanks
--
The following changes since commit 279ce5d117078ee8ea40c40199399889981fd808:

  drm/i915/gvt: declare gvt as i915's soft dependency (2018-07-10 11:13:11 
+0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-09-04

for you to fetch changes up to 69ca5af4ff9a3ff96e4595c2b7522c01a2641779:

  drm/i915/gvt: Move some MMIO definitions to reg.h (2018-08-07 10:40:11 +0800)


gvt-next-2018-09-04

- guest context shadow optimization for restore inhibit one (Yan)
- cmd parser optimization (Yan)
- W=1 warning fixes (Zhenyu)


Zhao Yan (2):
  drm/i915/gvt: add a fastpath for cmd parsing on MI_NOOP
  drm/i915/gvt: only copy the first page for restore inhibit context

Zhenyu Wang (3):
  drm/i915/gvt: make dma map/unmap kvmgt functions as static
  drm/i915/gvt: Fix function comment doc errors
  drm/i915/gvt: Move some MMIO definitions to reg.h

 drivers/gpu/drm/i915/gvt/cfg_space.c| 12 +++
 drivers/gpu/drm/i915/gvt/cmd_parser.c   | 11 +-
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  9 +
 drivers/gpu/drm/i915/gvt/gtt.c  |  9 +++--
 drivers/gpu/drm/i915/gvt/gvt.c  |  3 +-
 drivers/gpu/drm/i915/gvt/handlers.c |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c|  4 +--
 drivers/gpu/drm/i915/gvt/mmio.c |  3 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c | 13 ---
 drivers/gpu/drm/i915/gvt/mmio_context.h |  3 ++
 drivers/gpu/drm/i915/gvt/opregion.c |  1 -
 drivers/gpu/drm/i915/gvt/page_track.c   |  2 ++
 drivers/gpu/drm/i915/gvt/reg.h  |  9 +
 drivers/gpu/drm/i915/gvt/scheduler.c| 64 +
 15 files changed, 92 insertions(+), 53 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-fixes for 4.19

[Zhenyu Wang]

Hi,

Here's current gvt-fixes for 4.19 with more BXT fixes,
two guest warning fixes, dmabuf format mod fix and one
for recent multiple VM timeout failure.

Thanks
--
The following changes since commit 80ab316901bc4ae6dd0b5903dbe22766307eac9b:

  drm/i915/audio: Hook up component bindings even if displays are disabled 
(2018-08-29 14:11:53 -0700)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-09-04

for you to fetch changes up to 54ff01fd0d44b9681615f77c15fe9ea6dfadb501:

  drm/i915/gvt: Give new born vGPU higher scheduling chance (2018-09-03 
14:28:23 +0800)


gvt-fixes-2018-09-04

- two BXT virtual display emulation fixes (Colin)
- gen9 dbuf guest warning fix (Xiaolin)
- vgpu close pm warning fix (Hang)
- dmabuf format_mod fix (Zhenyu)
- multiple VM guest failure fix for scheduling (Zhenyu)


Colin Xu (2):
  drm/i915/gvt: Make correct handling to vreg BXT_PHY_CTL_FAMILY
  drm/i915/gvt: Handle GEN9_WM_CHICKEN3 with F_CMD_ACCESS.

Hang Yuan (1):
  drm/i915/gvt: move intel_runtime_pm_get out of spin_lock in stop_schedule

Xiaolin Zhang (1):
  drm/i915/gvt: emulate gen9 dbuf ctl register access

Zhenyu Wang (2):
  drm/i915/gvt: Fix drm_format_mod value for vGPU plane
  drm/i915/gvt: Give new born vGPU higher scheduling chance

 drivers/gpu/drm/i915/gvt/dmabuf.c   | 33 ++---
 drivers/gpu/drm/i915/gvt/fb_decoder.c   |  5 ++---
 drivers/gpu/drm/i915/gvt/fb_decoder.h   |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 33 +++--
 drivers/gpu/drm/i915/gvt/mmio_context.c |  2 --
 drivers/gpu/drm/i915/gvt/sched_policy.c | 37 ++---
 6 files changed, 86 insertions(+), 26 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Possible use_mm() mis-uses

[Zhenyu Wang]

On 2018.08.22 20:20:46 +0200, Paolo Bonzini wrote:
> On 22/08/2018 18:44, Linus Torvalds wrote:
> > An example of something that *isn't* right, is the i915 kvm interface,
> > which does
> > 
> > use_mm(kvm->mm);
> > 
> > on an mm that was initialized in virt/kvm/kvm_main.c using
> > 
> > mmgrab(current->mm);
> > kvm->mm = current->mm;
> > 
> > which is *not* right. Using "mmgrab()" does indeed guarantee the
> > lifetime of the 'struct mm_struct' itself, but it does *not* guarantee
> > the lifetime of the page tables. You need to use "mmget()" and
> > "mmput()", which get the reference to the actual process address
> > space!
> > 
> > Now, it is *possible* that the kvm use is correct too, because kvm
> > does register a mmu_notifier chain, and in theory you can avoid the
> > proper refcounting by just making sure the mmu "release" notifier
> > kills any existing uses, but I don't really see kvm doing that. Kvm
> > does register a release notifier, but that just flushes the shadow
> > page tables, it doesn't kill any use_mm() use by some i915 use case.
> 
> Yes, KVM is correct but the i915 bits are at least fishy.  It's probably
> as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init
> and kvmgt_guest_exit, or maybe mmget_not_zero.
> 

yeah, that's the clear way to fix this imo. We only depend on guest
life cycle to access guest memory properly. Here's proposed fix, will
verify and integrate it later.

Thanks!

From 5e5a8d0409aa150884adf5a4d0b956fd0b9906b3 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang 
Date: Thu, 23 Aug 2018 14:08:06 +0800
Subject: [PATCH] drm/i915/gvt: Fix life cycle reference on KVM mm

Handle guest mm access life cycle properly with mmget()/mmput()
through guest init()/exit(). As noted by Linus, use_mm() depends
on valid live page table but KVM's mmgrab() doesn't guarantee that.
As vGPU usage depends on guest VM life cycle, need to make sure to
use mmget()/mmput() to guarantee VM address access.

Cc: Linus Torvalds 
Cc: Paolo Bonzini 
Cc: Zhi Wang 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 71751be329e3..4a0988747d08 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1614,9 +1615,16 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
if (__kvmgt_vgpu_exist(vgpu, kvm))
return -EEXIST;
 
+   if (!mmget_not_zero(kvm->mm)) {
+   gvt_vgpu_err("Can't get KVM mm reference\n");
+   return -EINVAL;
+   }
+
info = vzalloc(sizeof(struct kvmgt_guest_info));
-   if (!info)
+   if (!info) {
+   mmput(kvm->mm);
return -ENOMEM;
+   }
 
vgpu->handle = (unsigned long)info;
info->vgpu = vgpu;
@@ -1647,6 +1655,8 @@ static bool kvmgt_guest_exit(struct kvmgt_guest_info 
*info)
debugfs_remove(info->debugfs_cache_entries);
 
kvm_page_track_unregister_notifier(info->kvm, >track_node);
+   if (info->kvm->mm)
+   mmput(info->kvm->mm);
kvm_put_kvm(info->kvm);
kvmgt_protect_table_destroy(info);
gvt_cache_destroy(info->vgpu);
-- 
2.18.0


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next-fixes

[Zhenyu Wang]

Hi,

This is initial gvt fixes for 4.19 with some accumulated fixes,
pls check details below.

Thanks
--
The following changes since commit 3237c0dbe21f8d2ca2feaa3891aff3619873cd30:

  drm/i915/kvmgt: Fix compilation error (2018-08-06 11:28:35 -0700)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-08-14

for you to fetch changes up to 7590ebb8b456464e48840a6d106a0c07de6d723a:

  drm/i915/gvt: fix memory leak in intel_vgpu_ioctl() (2018-08-14 15:27:12 
+0800)


gvt-next-fixes-2018-08-14

- Fix an error code in gvt_dma_map_page() (Dan)
- Fix off by one error in intel_vgpu_write_fence() (Dan)
- Fix potential Spectre v1 (Gustavo)
- Fix workload free in vgpu release (Henry)
- Fix cleanup sequence in intel_gvt_clean_device (Henry)
- dmabuf mutex init place fix (Henry)
- possible memory leak in intel_vgpu_ioctl() err path (Yi)
- return error on cmd access check failure (Yan)


Dan Carpenter (2):
  drm/i915/kvmgt: fix an error code in gvt_dma_map_page()
  drm/i915/gvt: Off by one in intel_vgpu_write_fence()

Gustavo A. R. Silva (1):
  drm/i915/kvmgt: Fix potential Spectre v1

Hang Yuan (3):
  drm/i915/gvt: free workload in vgpu release
  drm/i915/gvt: fix cleanup sequence in intel_gvt_clean_device
  drm/i915/gvt: initialize dmabuf mutex in vgpu_create

Yi Wang (1):
  drm/i915/gvt: fix memory leak in intel_vgpu_ioctl()

Zhao Yan (1):
  drm/i915/gvt: return error on cmd access

 drivers/gpu/drm/i915/gvt/aperture_gm.c |  2 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  2 +-
 drivers/gpu/drm/i915/gvt/gvt.c | 15 +++
 drivers/gpu/drm/i915/gvt/gvt.h |  4 +++-
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 26 ++
 drivers/gpu/drm/i915/gvt/scheduler.c   |  7 ---
 drivers/gpu/drm/i915/gvt/scheduler.h   |  3 +++
 drivers/gpu/drm/i915/gvt/vgpu.c| 23 +--
 8 files changed, 58 insertions(+), 24 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix memory leak in intel_vgpu_ioctl()

[Zhenyu Wang]

On 2018.08.03 08:41:19 +0800, Yi Wang wrote:
> The 'sparse' variable may leak when return in function
> intel_vgpu_ioctl(), and this patch fixes this.
> 
> Signed-off-by: Yi Wang 
> Reviewed-by: Jiang Biao 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index df4e4a0..6a6f199 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1200,6 +1200,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
>   return ret;
>   break;
>   default:
> + kfree(sparse);
>   return -EINVAL;
>   }
>   }
> @@ -1215,6 +1216,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
> sizeof(info), caps.buf,
> caps.size)) {
>   kfree(caps.buf);
> + kfree(sparse);
>   return -EFAULT;
>   }
>   info.cap_offset = sizeof(info);
> @@ -1223,6 +1225,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
>   kfree(caps.buf);
>   }
>  
> + kfree(sparse);

Unfortunately this would cause a double-free error in normal path, as we
tried to free sparse after use to add caps. So may be better to fix free
in error path and move normal free of sparse in final point, e.g

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 68df9aa88890..47b897b6ea93 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1257,11 +1257,13 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
>header, sizeof(*sparse) +
(sparse->nr_areas *
sizeof(*sparse->areas)));
-   kfree(sparse);
-   if (ret)
+   if (ret) {
+   kfree(sparse);
return ret;
+   }
break;
default:
+   kfree(sparse);
return -EINVAL;
}
}
@@ -1277,6 +1279,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
  sizeof(info), caps.buf,
  caps.size)) {
kfree(caps.buf);
+   kfree(sparse);
return -EFAULT;
}
info.cap_offset = sizeof(info);
@@ -1285,6 +1288,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
kfree(caps.buf);
}
 
+   kfree(sparse);
return copy_to_user((void __user *)arg, , minsz) ?
-EFAULT : 0;
} else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {



-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: fix an error code in gvt_dma_map_page()

[Zhenyu Wang]

On 2018.07.19 11:19:21 +0300, Dan Carpenter wrote:
> The dma_mapping_error() returns true on error but we want to return
> -ENOMEM here.
> 
> Fixes: 79e542f5af79 ("drm/i915/kvmgt: Support setting dma map for huge pages")
> Signed-off-by: Dan Carpenter 
>

Applied, thanks!

> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 4d2f53ae9f0f..32ec5748f176 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -187,14 +187,14 @@ static int gvt_dma_map_page(struct intel_vgpu *vgpu, 
> unsigned long gfn,
>  
>   /* Setup DMA mapping. */
>   *dma_addr = dma_map_page(dev, page, 0, size, PCI_DMA_BIDIRECTIONAL);
> - ret = dma_mapping_error(dev, *dma_addr);
> - if (ret) {
> + if (dma_mapping_error(dev, *dma_addr)) {
>   gvt_vgpu_err("DMA mapping failed for pfn 0x%lx, ret %d\n",
>page_to_pfn(page), ret);
>   gvt_unpin_guest_page(vgpu, gfn, size);
> + return -ENOMEM;
>   }
>  
> - return ret;
> + return 0;
>  }
>  
>  static void gvt_dma_unmap_page(struct intel_vgpu *vgpu, unsigned long gfn,
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: Fix potential Spectre v1

[Zhenyu Wang]

On 2018.08.02 22:40:19 -0500, Gustavo A. R. Silva wrote:
> info.index can be indirectly controlled by user-space, hence leading
> to a potential exploitation of the Spectre variant 1 vulnerability.
> 
> This issue was detected with the help of Smatch:
> 
> drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
> potential spectre issue 'vgpu->vdev.region' [r]
> 
> Fix this by sanitizing info.index before indirectly using it to index
> vgpu->vdev.region

Thanks for catching this! Applied.

> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 4d2f53a..b703f20 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -43,6 +43,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "i915_drv.h"
>  #include "gvt.h"
>  
> @@ -1139,7 +1141,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
>   } else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
>   struct vfio_region_info info;
>   struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
> - int i, ret;
> + unsigned int i;
> + int ret;
>   struct vfio_region_info_cap_sparse_mmap *sparse = NULL;
>   size_t size;
>   int nr_areas = 1;
> @@ -1224,6 +1227,10 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
>   if (info.index >= VFIO_PCI_NUM_REGIONS +
>   vgpu->vdev.num_regions)
>   return -EINVAL;
> + info.index =
> + array_index_nospec(info.index,
> + VFIO_PCI_NUM_REGIONS +
> + vgpu->vdev.num_regions);
>  
>   i = info.index - VFIO_PCI_NUM_REGIONS;
>  
> -- 
> 2.7.4
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: fix memory leak in intel_vgpu_ioctl()

[Zhenyu Wang]

On 2018.08.03 08:41:19 +0800, Yi Wang wrote:
> The 'sparse' variable may leak when return in function
> intel_vgpu_ioctl(), and this patch fixes this.
> 
> Signed-off-by: Yi Wang 
> Reviewed-by: Jiang Biao 
> ---

Looks fine to me, will queue this up.

Thanks for the patch!

>  drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index df4e4a0..6a6f199 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1200,6 +1200,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
>   return ret;
>   break;
>   default:
> + kfree(sparse);
>   return -EINVAL;
>   }
>   }
> @@ -1215,6 +1216,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
> sizeof(info), caps.buf,
> caps.size)) {
>   kfree(caps.buf);
> + kfree(sparse);
>   return -EFAULT;
>   }
>   info.cap_offset = sizeof(info);
> @@ -1223,6 +1225,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, 
> unsigned int cmd,
>   kfree(caps.buf);
>   }
>  
> + kfree(sparse);
>   return copy_to_user((void __user *)arg, , minsz) ?
>   -EFAULT : 0;
>   } else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
> -- 
> 1.8.3.1
> 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915/gvt: use its own define for gpio

[Zhenyu Wang]

On 2018.07.27 12:36:46 -0700, Lucas De Marchi wrote:
> The definition on i915_reg.h is going to change to depend on
> dev_priv->gpio_mmio_base being properly initialized. Define our own
> macros since init_generic_mmio_info() is called before than
> gpio_mmio_base being set.
>

Reviewed-by: Zhenyu Wang 

> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: Zhenyu Wang 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
>  drivers/gpu/drm/i915/gvt/reg.h  | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 7a58ca555197..0dc8692d7eb3 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -2118,7 +2118,7 @@ static int init_generic_mmio_info(struct intel_gvt *gvt)
>  
>   MMIO_F(PCH_GMBUS0, 4 * 4, 0, 0, 0, D_ALL, gmbus_mmio_read,
>   gmbus_mmio_write);
> - MMIO_F(PCH_GPIOA, 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL);
> + MMIO_F(PCH_GPIO_BASE, 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL);
>   MMIO_F(_MMIO(0xe4f00), 0x28, 0, 0, 0, D_ALL, NULL, NULL);
>  
>   MMIO_F(_MMIO(_PCH_DPB_AUX_CH_CTL), 6 * 4, 0, 0, 0, D_PRE_SKL, NULL,
> diff --git a/drivers/gpu/drm/i915/gvt/reg.h b/drivers/gpu/drm/i915/gvt/reg.h
> index fd5fd25d0a0f..c9d6cf6cc623 100644
> --- a/drivers/gpu/drm/i915/gvt/reg.h
> +++ b/drivers/gpu/drm/i915/gvt/reg.h
> @@ -77,6 +77,8 @@
>  #define _RING_CTL_BUF_SIZE(ctl) (((ctl) & RB_TAIL_SIZE_MASK) + \
>   I915_GTT_PAGE_SIZE)
>  
> +#define PCH_GPIO_BASE_MMIO(0xc5010)
> +
>  #define PCH_GMBUS0   _MMIO(0xc5100)
>  #define PCH_GMBUS1   _MMIO(0xc5104)
>  #define PCH_GMBUS2   _MMIO(0xc5108)
> -- 
> 2.17.1
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/3] drm/i915: make PCH_GMBUS* definitions private to gvt

[Zhenyu Wang]

On 2018.07.27 12:36:45 -0700, Lucas De Marchi wrote:
> This is the only place that they are being used - the others use the
> GMBUS* macros that rely on dev_priv being already properly initialized.
>

Reviewed-by: Zhenyu Wang 

thanks!

> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: Zhenyu Wang 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/gvt/reg.h  | 7 +++
>  drivers/gpu/drm/i915/i915_reg.h | 7 ---
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/reg.h b/drivers/gpu/drm/i915/gvt/reg.h
> index d4f7ce6dc1d7..fd5fd25d0a0f 100644
> --- a/drivers/gpu/drm/i915/gvt/reg.h
> +++ b/drivers/gpu/drm/i915/gvt/reg.h
> @@ -77,4 +77,11 @@
>  #define _RING_CTL_BUF_SIZE(ctl) (((ctl) & RB_TAIL_SIZE_MASK) + \
>   I915_GTT_PAGE_SIZE)
>  
> +#define PCH_GMBUS0   _MMIO(0xc5100)
> +#define PCH_GMBUS1   _MMIO(0xc5104)
> +#define PCH_GMBUS2   _MMIO(0xc5108)
> +#define PCH_GMBUS3   _MMIO(0xc510c)
> +#define PCH_GMBUS4   _MMIO(0xc5110)
> +#define PCH_GMBUS5   _MMIO(0xc5120)
> +
>  #endif
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5530c470f30d..07606677168c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7875,13 +7875,6 @@ enum {
>  #define PCH_GPIOE   _MMIO(0xc5020)
>  #define PCH_GPIOF   _MMIO(0xc5024)
>  
> -#define PCH_GMBUS0   _MMIO(0xc5100)
> -#define PCH_GMBUS1   _MMIO(0xc5104)
> -#define PCH_GMBUS2   _MMIO(0xc5108)
> -#define PCH_GMBUS3   _MMIO(0xc510c)
> -#define PCH_GMBUS4   _MMIO(0xc5110)
> -#define PCH_GMBUS5   _MMIO(0xc5120)
> -
>  #define _PCH_DPLL_A  0xc6014
>  #define _PCH_DPLL_B  0xc6018
>  #define PCH_DPLL(pll) _MMIO((pll) == 0 ? _PCH_DPLL_A : _PCH_DPLL_B)
> -- 
> 2.17.1
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: remove confusing GPIO vs PCH_GPIO

[Zhenyu Wang]

On 2018.07.19 17:20:15 +, De Marchi, Lucas wrote:
> CC'ing gvt maintainers (and fixing Jani's address in CC).
> 
> See below
> 
> On Wed, 2018-07-18 at 13:01 +0300, Ville Syrjälä wrote:
> > On Tue, Jul 17, 2018 at 03:16:53PM -0700, Lucas De Marchi wrote:
> > > On Fri, Jul 13, 2018 at 9:10 AM Ville Syrjälä
> > >  wrote:
> > > > 
> > > > On Fri, Jul 13, 2018 at 08:42:11AM -0700, Lucas De Marchi wrote:
> > > > > Instead of defining all registers twice, define just a PCH_GPIO_BASE
> > > > > that has the same address as PCH_GPIO_A and use that to calculate all
> > > > > the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing
> > > > > the same thing.
> > > > > 
> > > > > v2: Fix GMBUS registers to be relative to gpio base; create GPIO()
> > > > > macro to return a particular gpio address and move the enum out of
> > > > > i915_reg.h (suggested by Jani)
> > > > > 
> > > > > v3: Move base offset inside the GPIO() macro so the GMBUS defines
> > > > > don't
> > > > > actually need to be changed (suggested by Daniel/Ville)
> > > > > 
> > > > > Signed-off-by: Lucas De Marchi 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/gvt/handlers.c |  2 +-
> > > > >  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
> > > > >  drivers/gpu/drm/i915/i915_reg.h | 24 +---
> > > > >  drivers/gpu/drm/i915/intel_drv.h| 16 
> > > > >  drivers/gpu/drm/i915/intel_i2c.c| 12 
> > > > >  5 files changed, 28 insertions(+), 29 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> > > > > b/drivers/gpu/drm/i915/gvt/handlers.c
> > > > > index 7a58ca555197..ecff866bbbf1 100644
> > > > > --- a/drivers/gpu/drm/i915/gvt/handlers.c
> > > > > +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> > > > > @@ -2118,7 +2118,7 @@ static int init_generic_mmio_info(struct
> > > > > intel_gvt *gvt)
> > > > > 
> > > > >   MMIO_F(PCH_GMBUS0, 4 * 4, 0, 0, 0, D_ALL, gmbus_mmio_read,
> > > > >   gmbus_mmio_write);
> > > > > - MMIO_F(PCH_GPIOA, 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL);
> > > > > + MMIO_F(GPIO(GPIOA), 6 * 4, F_UNALIGN, 0, 0, D_ALL, NULL, NULL);
> > > > 
> > > > I have no idea of gpio_mmio_base is populated correctly at this point
> > > > for gvt, and I'm too lazy to find out.
> > > 
> > > humn, unfortunately it is not
> > > 
> > > i915_driver_load() -> i915_load_modeset_init() -> intel_setup_gmbus()
> > > -> dev_priv->gpio_mmio_base = ...
> > > i915_driver_load() -> i915_driver_init_hw() -> intel_gvt_init() ->
> > > intel_gvt_init_device() -> intel_gvt_setup_mmio_info() ->
> > > init_generic_mmio_info()
> > > 
> > > Is adding a single PCH_GPIO_BASE that doesn't depend on dev_priv being
> > > populated for use on gvt an option?
> > 
> > IIRC gvt already has some local register defines (possibly due to this
> > same reason?). Could add a few more I suppose. +cc the gvt folks to get
> > their input.
> 
> Summary to gvt maintainers: I want to get rid of the multiple GPIO vs PCH_GPIO
> defines we have today. For that I created the GPIO() macro, but it depends on
> dev_priv being populated with the gpio's block offset already which is not
> true while initializing gvt.
>

This also applys to GMBUS change, right?

> I can define a PCH_GPIO_BASE as above in i915_reg.h that is the same as
> PCH_GPIOA today. Or define it in a private gvt header. Do you have another
> option/suggestion?
>

yeah, adding a base define for gvt private seems good to me, as gvt handles
MMIO trap so may need to use them in different way.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next for 4.19

[Zhenyu Wang]

On 2018.07.16 23:07:35 -0700, Rodrigo Vivi wrote:
> On Tue, Jul 17, 2018 at 12:58:37PM +0800, Zhenyu Wang wrote:
> > 
> > Hi,
> > 
> > Left fixes for all W=1 warnings, I think better to send
> > to catch up last train for 4.19, mostly kernel doc comments
> > fixes with a trivial refactor.
> 
> I was going to pull it and by pass dim...
> 
> The changes on the patches themselves is something simple enough that I would
> ack myself, although in one of patches if we had review I'm sure
> that would become 2 patches
> 
> So at this point I'm not sure if I should bypass dim or request
> another eyes... so I'm just, at least, holding until tomorrow...
> 

Sorry for bothering you, let me rework this and ask proper review for next try.
You can ignore this one.

thanks

> > --
> > The following changes since commit 279ce5d117078ee8ea40c40199399889981fd808:
> > 
> >   drm/i915/gvt: declare gvt as i915's soft dependency (2018-07-10 11:13:11 
> > +0800)
> > 
> > are available in the Git repository at:
> > 
> >   https://github.com/intel/gvt-linux.git tags/gvt-next-2018-07-17
> > 
> > for you to fetch changes up to 3e494c2eb417715cdfed66827a5752e41de748c3:
> > 
> >   drm/i915/gvt: Fix W=1 warnings (2018-07-16 13:28:47 +0800)
> > 
> > ----
> > gvt-next-2018-07-17
> > 
> > - Fix all left W=1 warnings
> > 
> > 
> > Zhenyu Wang (2):
> >   drm/i915/gvt: make dma map/unmap kvmgt functions as static
> >   drm/i915/gvt: Fix W=1 warnings
> > 
> >  drivers/gpu/drm/i915/gvt/cfg_space.c| 12 
> >  drivers/gpu/drm/i915/gvt/display.c  |  1 +
> >  drivers/gpu/drm/i915/gvt/edid.c |  9 +
> >  drivers/gpu/drm/i915/gvt/gtt.c  |  9 ++---
> >  drivers/gpu/drm/i915/gvt/gvt.c  |  3 +--
> >  drivers/gpu/drm/i915/gvt/handlers.c |  1 +
> >  drivers/gpu/drm/i915/gvt/kvmgt.c|  4 ++--
> >  drivers/gpu/drm/i915/gvt/mmio.c |  3 ++-
> >  drivers/gpu/drm/i915/gvt/mmio_context.c | 13 -
> >  drivers/gpu/drm/i915/gvt/opregion.c |  1 -
> >  drivers/gpu/drm/i915/gvt/page_track.c   |  2 ++
> >  drivers/gpu/drm/i915/gvt/reg.h  |  9 +
> >  drivers/gpu/drm/i915/gvt/scheduler.c|  4 +++-
> >  13 files changed, 48 insertions(+), 23 deletions(-)
> > 
> > 
> > -- 
> > Open Source Technology Center, Intel ltd.
> > 
> > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
> 
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next for 4.19

[Zhenyu Wang]

Hi,

Left fixes for all W=1 warnings, I think better to send
to catch up last train for 4.19, mostly kernel doc comments
fixes with a trivial refactor.

Thanks
--
The following changes since commit 279ce5d117078ee8ea40c40199399889981fd808:

  drm/i915/gvt: declare gvt as i915's soft dependency (2018-07-10 11:13:11 
+0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-07-17

for you to fetch changes up to 3e494c2eb417715cdfed66827a5752e41de748c3:

  drm/i915/gvt: Fix W=1 warnings (2018-07-16 13:28:47 +0800)


gvt-next-2018-07-17

- Fix all left W=1 warnings


Zhenyu Wang (2):
  drm/i915/gvt: make dma map/unmap kvmgt functions as static
  drm/i915/gvt: Fix W=1 warnings

 drivers/gpu/drm/i915/gvt/cfg_space.c| 12 
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  9 +
 drivers/gpu/drm/i915/gvt/gtt.c  |  9 ++---
 drivers/gpu/drm/i915/gvt/gvt.c  |  3 +--
 drivers/gpu/drm/i915/gvt/handlers.c |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c|  4 ++--
 drivers/gpu/drm/i915/gvt/mmio.c |  3 ++-
 drivers/gpu/drm/i915/gvt/mmio_context.c | 13 -
 drivers/gpu/drm/i915/gvt/opregion.c |  1 -
 drivers/gpu/drm/i915/gvt/page_track.c   |  2 ++
 drivers/gpu/drm/i915/gvt/reg.h  |  9 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  4 +++-
 13 files changed, 48 insertions(+), 23 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] Revert "iommu/vt-d: Clean up pasid quirk for pre-production devices"

[Zhenyu Wang]

On 2018.07.16 14:02:12 +0800, Lu Baolu wrote:
> Hi Joerg,
> 
> The graphic guys are looking forward to having this in 4.18.
> Is it possible to take it in the following rcs?
> 

This breakes intel gfx driver in 4.18 when gfx dmar is on.
Please include this fix ASAP.

Tested-by: Zhenyu Wang 

thanks!

> 
> On 07/08/2018 02:23 PM, Lu Baolu wrote:
> > This reverts commit ab96746aaa344fb720a198245a837e266fad3b62.
> >
> > The commit ab96746aaa34 ("iommu/vt-d: Clean up pasid quirk for
> > pre-production devices") triggers ECS mode on some platforms
> > which have broken ECS support. As the result, graphic device
> > will be inoperable on boot.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107017
> >
> > Cc: Ashok Raj 
> > Signed-off-by: Lu Baolu 
> > ---
> >  drivers/iommu/intel-iommu.c | 32 ++--
> >  include/linux/intel-iommu.h |  1 +
> >  2 files changed, 31 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index b344a88..115ff26 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -484,14 +484,37 @@ static int dmar_forcedac;
> >  static int intel_iommu_strict;
> >  static int intel_iommu_superpage = 1;
> >  static int intel_iommu_ecs = 1;
> > +static int intel_iommu_pasid28;
> >  static int iommu_identity_mapping;
> >  
> >  #define IDENTMAP_ALL   1
> >  #define IDENTMAP_GFX   2
> >  #define IDENTMAP_AZALIA4
> >  
> > -#define ecs_enabled(iommu) (intel_iommu_ecs && ecap_ecs(iommu->ecap))
> > -#define pasid_enabled(iommu)   (ecs_enabled(iommu) && 
> > ecap_pasid(iommu->ecap))
> > +/* Broadwell and Skylake have broken ECS support — normal so-called "second
> > + * level" translation of DMA requests-without-PASID doesn't actually happen
> > + * unless you also set the NESTE bit in an extended context-entry. Which of
> > + * course means that SVM doesn't work because it's trying to do nested
> > + * translation of the physical addresses it finds in the process page 
> > tables,
> > + * through the IOVA->phys mapping found in the "second level" page tables.
> > + *
> > + * The VT-d specification was retroactively changed to change the 
> > definition
> > + * of the capability bits and pretend that Broadwell/Skylake never 
> > happened...
> > + * but unfortunately the wrong bit was changed. It's ECS which is broken, 
> > but
> > + * for some reason it was the PASID capability bit which was redefined 
> > (from
> > + * bit 28 on BDW/SKL to bit 40 in future).
> > + *
> > + * So our test for ECS needs to eschew those implementations which set the 
> > old
> > + * PASID capabiity bit 28, since those are the ones on which ECS is broken.
> > + * Unless we are working around the 'pasid28' limitations, that is, by 
> > putting
> > + * the device into passthrough mode for normal DMA and thus masking the 
> > bug.
> > + */
> > +#define ecs_enabled(iommu) (intel_iommu_ecs && ecap_ecs(iommu->ecap) && \
> > +   (intel_iommu_pasid28 || 
> > !ecap_broken_pasid(iommu->ecap)))
> > +/* PASID support is thus enabled if ECS is enabled and *either* of the old
> > + * or new capability bits are set. */
> > +#define pasid_enabled(iommu) (ecs_enabled(iommu) &&
> > \
> > + (ecap_pasid(iommu->ecap) || 
> > ecap_broken_pasid(iommu->ecap)))
> >  
> >  int intel_iommu_gfx_mapped;
> >  EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
> > @@ -554,6 +577,11 @@ static int __init intel_iommu_setup(char *str)
> > printk(KERN_INFO
> > "Intel-IOMMU: disable extended context table 
> > support\n");
> > intel_iommu_ecs = 0;
> > +   } else if (!strncmp(str, "pasid28", 7)) {
> > +   printk(KERN_INFO
> > +   "Intel-IOMMU: enable pre-production PASID 
> > support\n");
> > +   intel_iommu_pasid28 = 1;
> > +   iommu_identity_mapping |= IDENTMAP_GFX;
> > } else if (!strncmp(str, "tboot_noforce", 13)) {
> > printk(KERN_INFO
> > "Intel-IOMMU: not forcing on after tboot. This 
> > could expose security risk for tboot\n");
> > diff --git 

Re: [Intel-gfx] [PATCH 3/6] drm/i915/gtt: Disable read-only support under GVT

[Zhenyu Wang]

On 2018.07.12 20:36:03 +, Bloomfield, Jon wrote:
> > -Original Message-
> > From: Chris Wilson 
> > Sent: Thursday, July 12, 2018 11:53 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Zhenyu Wang
> > ; Bloomfield, Jon ;
> > Joonas Lahtinen ; Matthew Auld
> > 
> > Subject: [PATCH 3/6] drm/i915/gtt: Disable read-only support under GVT
> > 
> > GVT is not propagating the PTE bits, and is always setting the
> > read-write bit, thus breaking read-only support.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Zhenyu Wang 
> > Cc: Jon Bloomfield 
> > Cc: Joonas Lahtinen 
> > Cc: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 6c0b438afe46..8e70a45b8a90 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -1662,8 +1662,12 @@ static struct i915_hw_ppgtt
> > *gen8_ppgtt_create(struct drm_i915_private *i915)
> > 1ULL << 48 :
> > 1ULL << 32;
> > 
> > -   /* From bdw, there is support for read-only pages in the PPGTT */
> > -   ppgtt->vm.has_read_only = true;
> > +   /*
> > +* From bdw, there is support for read-only pages in the PPGTT.
> > +*
> > +* XXX GVT is not setting honouring the PTE bits.
> > +*/
> > +   ppgtt->vm.has_read_only = !intel_vgpu_active(i915);
> > 
> > i915_address_space_init(>vm, i915);
> > 
> > --
> > 2.18.0
> 
> Is there a blocker that prevents gvt respecting this bit? I can't think of an 
> obvious
> reason why it would be a bad thing to support.

I don't think any blocker for gvt support, we can respect that bit when 
shadowing.
But we need capability check on host gvt when that support is ready.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/kvmgt: Fix compilation error

[Zhenyu Wang]

On 2018.07.12 17:53:30 +0200, Micha?? Winiarski wrote:
> gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality:
> commit 79e542f5af79 ("drm/i915/kvmgt: Support setting dma map for huge pages")
> 
> And yet, part of it was reintroduced in:
> commit 39b4cbadb9a9 ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages")
> 
> Causing kvmgt part to no longer build. Let's remove it.
>

yeah, this change is correct. I found it too when merging against
upstreams for gvt staging tree, not caught by conflict though. Once
we backmerge upstream gvt requires this fix.

Acked-by: Zhenyu Wang 

Thanks!

> Reported-by: Tomasz Lis 
> Signed-off-by: Micha?? Winiarski 
> Cc: Changbin Du 
> Cc: Zhenyu Wang 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 718ab307a500..4d2f53ae9f0f 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -185,12 +185,6 @@ static int gvt_dma_map_page(struct intel_vgpu *vgpu, 
> unsigned long gfn,
>   if (ret)
>   return ret;
>  
> - if (!pfn_valid(pfn)) {
> - gvt_vgpu_err("pfn 0x%lx is not mem backed\n", pfn);
> - vfio_unpin_pages(mdev_dev(vgpu->vdev.mdev), , 1);
> - return -EINVAL;
> - }
> -
>   /* Setup DMA mapping. */
>   *dma_addr = dma_map_page(dev, page, 0, size, PCI_DMA_BIDIRECTIONAL);
>   ret = dma_mapping_error(dev, *dma_addr);
> -- 
> 2.17.1
> 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next for 4.19

[Zhenyu Wang]

On 2018.07.11 08:45:08 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-07-11 03:33:53)
> > 
> > Hi,
> > 
> > Here's last gvt-next pull for 4.19. Biggest change is to
> > add vGPU huge page support for guest, with one BXT fix and
> > gvt dependency handling.
> 
> Any progress to cleaning up all the compiler warnings for W=1?

I'll check all those, thanks for reminding me!

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-fixes for 4.18

[Zhenyu Wang]

Hi,

Here's one gvt fix for KBL vGPU hang to update virtual register from LRI.

Thanks.
--
The following changes since commit a4cae23cc05ccec749c2fc70fa9d8cda7c582319:

  drm/i915/gvt: changed DDI mode emulation type (2018-07-02 11:09:59 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-07-11

for you to fetch changes up to 6cef21a1964933b77c855c55bac2723053cc676d:

  drm/i915/gvt: update vreg on inhibit context lri command (2018-07-05 15:33:37 
+0800)


gvt-fixes-2018-07-11

- Fix KBL virtual register update from LRI for GPU hang (Henry)


Hang Yuan (1):
  drm/i915/gvt: update vreg on inhibit context lri command

 drivers/gpu/drm/i915/gvt/cmd_parser.c   | 23 +++
 drivers/gpu/drm/i915/gvt/gvt.h  | 29 +
 drivers/gpu/drm/i915/gvt/handlers.c | 24 
 drivers/gpu/drm/i915/gvt/mmio.h |  2 ++
 drivers/gpu/drm/i915/gvt/mmio_context.c |  4 +++-
 5 files changed, 81 insertions(+), 1 deletion(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next for 4.19

[Zhenyu Wang]

Hi,

Here's last gvt-next pull for 4.19. Biggest change is to
add vGPU huge page support for guest, with one BXT fix and
gvt dependency handling.

Thanks.
--
The following changes since commit 57c8a484a9cbf1315b5299702d12aef04867:

  drm/i915: Enable KVMGT for BXT. (2018-06-13 10:57:30 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-07-11

for you to fetch changes up to 279ce5d117078ee8ea40c40199399889981fd808:

  drm/i915/gvt: declare gvt as i915's soft dependency (2018-07-10 11:13:11 
+0800)


gvt-next-2018-07-11

- vGPU huge page support (Changbin)
- BXT display irq warning fix (Colin)
- Handle GVT dependency well (Henry)


Changbin Du (14):
  drm/i915/gvt: Add new 64K entry type
  drm/i915/gvt: Add PTE IPS bit operations
  drm/i915/gvt: Handle MMIO GEN8_GAMW_ECO_DEV_RW_IA for 64K GTT
  drm/i915/gvt: Detect 64K gtt entry by IPS bit of PDE
  drm/i915/gvt: Add software PTE flag to mark special 64K splited entry
  drm/i915/gvt: Add GTT clear_pse operation
  drm/i915/gvt: Split ppgtt_alloc_spt into two parts
  drm/i915/gvt: Make PTE iterator 64K entry aware
  drm/i915/gvt: Add 64K huge gtt support
  drm/i915/kvmgt: Support setting dma map for huge pages
  drm/i915/gvt: Add 2M huge gtt support
  drm/i915/gvt: Handle special sequence on PDE IPS bit
  drm/i915/gvt: Fix error handling in ppgtt_populate_spt_by_guest_entry
  drm/i915: Enable platform support for vGPU huge gtt pages

Colin Xu (1):
  drm/i915/gvt: Handle EDP_PSR_IMR and EDP_PSR_IIR for BXT.

Hang Yuan (1):
  drm/i915/gvt: declare gvt as i915's soft dependency

 drivers/gpu/drm/i915/gvt/gtt.c   | 423 ++-
 drivers/gpu/drm/i915/gvt/gtt.h   |   9 +
 drivers/gpu/drm/i915/gvt/gvt.c   |   4 +
 drivers/gpu/drm/i915/gvt/handlers.c  |  39 +++-
 drivers/gpu/drm/i915/gvt/hypercall.h |   2 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c | 126 ---
 drivers/gpu/drm/i915/gvt/mpt.h   |   7 +-
 drivers/gpu/drm/i915/gvt/vgpu.c  |   1 +
 8 files changed, 517 insertions(+), 94 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: declare gvt as i915's soft dependency

[Zhenyu Wang]

On 2018.07.09 18:24:10 +0800, intel-gvt-dev-boun...@lists.freedesktop.org wrote:
> From: Hang Yuan 
> 
> This helps initramfs builder and other tools to know the full dependencies
> of i915 and have gvt module loaded with i915.
> 
> v2: add condition and change to pre-dependency (Chris)
> v3: move declaration to gvt.c. (Chris)
> v4: remove xengt (Zhenyu)
> 
> Signed-off-by: Hang Yuan 
> Reviewed-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gvt/gvt.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index 4e65266..712f9d1 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -468,3 +468,7 @@ int intel_gvt_init_device(struct drm_i915_private 
> *dev_priv)
>   kfree(gvt);
>   return ret;
>  }
> +
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
> +MODULE_SOFTDEP("pre: kvmgt");
> +#endif
> -- 

Applied this, thanks!

btw pls fix your mail client or git config with correct From field.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: declare gvt as i915's soft dependency

[Zhenyu Wang]

On 2018.07.04 11:07:45 +0800, intel-gfx-boun...@lists.freedesktop.org wrote:
> From: Hang Yuan 
> 
> This helps initramfs builder and other tools to know the full dependencies
> of i915 and have gvt module loaded with i915.
> 
> v2: add condition and change to pre-dependency (Chris)
> v3: move declaration to gvt.c. (Chris)
> 
> Signed-off-by: Hang Yuan 
> ---
>  drivers/gpu/drm/i915/gvt/gvt.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index 4e65266..00f487e9 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -468,3 +468,10 @@ int intel_gvt_init_device(struct drm_i915_private 
> *dev_priv)
>   kfree(gvt);
>   return ret;
>  }
> +
> +#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
> +MODULE_SOFTDEP("pre: kvmgt");
> +#elif IS_ENABLED(CONFIG_DRM_I915_GVT_XENGT)
> +MODULE_SOFTDEP("pre: xengt");
> +#endif
> +

Why xengt? it's not in upstream at all, so should be splitted and
apply to its topic branch only.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-fixes for 4.18

[Zhenyu Wang]

Hi,

Here's two gvt fixes for 4.18. One is for guest warning to change
virtual transcoder mode for DVI to align with our virtual display,
and one to fix possible partial GGTT entry update from guest.

thanks
--
The following changes since commit 7a3727f385dc64773db1c144f6b15c1e9d4735bb:

  drm/i915: Enable provoking vertex fix on Gen9 systems. (2018-06-19 15:48:24 
+0300)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-07-03

for you to fetch changes up to a4cae23cc05ccec749c2fc70fa9d8cda7c582319:

  drm/i915/gvt: changed DDI mode emulation type (2018-07-02 11:09:59 +0800)


gvt-fixes-2018-07-03

- replace virtual transcoder mode as DVI to fix guest warning (Xiaolin)
- fix partial GGTT entry write (Yan)


Xiaolin Zhang (1):
  drm/i915/gvt: changed DDI mode emulation type

Zhao Yan (1):
  drm/i915/gvt: fix a bug of partially write ggtt enties

 drivers/gpu/drm/i915/gvt/display.c |  6 ++--
 drivers/gpu/drm/i915/gvt/gtt.c | 58 ++
 drivers/gpu/drm/i915/gvt/gtt.h |  2 ++
 3 files changed, 63 insertions(+), 3 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next

[Zhenyu Wang]

Hi,

Here is first gvt-next pull for next 4.19 kernel. Mostly on gvt
optimizations and has added BXT support for GVT-g.

Thanks.
---
The following changes since commit 14c3f8425080a1ff97df7b81f7c339bf42c427a3:

  drm/i915: Update DRIVER_DATE to 20180606 (2018-06-06 15:10:47 -0700)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-06-19

for you to fetch changes up to 57c8a484a9cbf1315b5299702d12aef04867:

  drm/i915: Enable KVMGT for BXT. (2018-06-13 10:57:30 +0800)


gvt-next-2018-06-19

- fine-grained per vgpu locking (Colin)
- fine-grained vgpu scheduler locking (Colin)
- deliver windows guest cursor hotspot info (Tina)
- GVT-g BXT support (Colin)
- other misc and checker fixes (Chris, Xinyun)


Chris Wilson (1):
  drm/i915/gvt: Use offsetofend() rather than offsetof + sizeof

Colin Xu (14):
  drm/i915/gvt: Use vgpu_lock to protect per vgpu access
  drm/i915/gvt: Use sched_lock to protect gvt scheduler logic.
  drm/i915/gvt: Add D_BXT device type define for BXT.
  drm/i915/gvt: Add MEDIA_POOL_STATE for BXT.
  drm/i915/gvt: Enable device info initialization for BXT.
  drm/i915/gvt: Enable gtt initialization for BXT.
  drm/i915/gvt: Enable irq initialization for BXT.
  drm/i915/gvt: Enable mmio context init and switch for BXT.
  drm/i915/gvt: Enable cmd_parser support for BXT.
  drm/i915/gvt: Enable force wake support for BXT.
  drm/i915/gvt: Enable virtual display support for BXT.
  drm/i915/gvt: Enable dma_buf support for BXT.
  drm/i915/gvt: Add mmio handler for for BXT.
  drm/i915: Enable KVMGT for BXT.

Tina Zhang (1):
  drm/i915/gvt: Deliver guest cursor hotspot info

Xinyun Liu (3):
  drm/i915/gvt: Avoid dereference a potential null pointer
  drm/i915/gvt: removed unnecessary boundary check
  drm/i915/gvt: use array to avoid potential buffer overflow

Zhenyu Wang (1):
  Merge tag 'drm-intel-next-2018-06-06' into gvt-next

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  43 ++--
 drivers/gpu/drm/i915/gvt/display.c  |  58 +++--
 drivers/gpu/drm/i915/gvt/dmabuf.c   |  26 ++-
 drivers/gpu/drm/i915/gvt/edid.c |  20 +-
 drivers/gpu/drm/i915/gvt/execlist.h |  13 +-
 drivers/gpu/drm/i915/gvt/fb_decoder.c   |  15 +-
 drivers/gpu/drm/i915/gvt/firmware.c |   2 +-
 drivers/gpu/drm/i915/gvt/gtt.c  |  11 +-
 drivers/gpu/drm/i915/gvt/gvt.c  |  27 +--
 drivers/gpu/drm/i915/gvt/gvt.h  |  16 ++
 drivers/gpu/drm/i915/gvt/handlers.c | 399 
 drivers/gpu/drm/i915/gvt/interrupt.c|  17 +-
 drivers/gpu/drm/i915/gvt/mmio.c |  12 +-
 drivers/gpu/drm/i915/gvt/mmio.h |  11 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c |  16 +-
 drivers/gpu/drm/i915/gvt/page_track.c   |   5 +-
 drivers/gpu/drm/i915/gvt/sched_policy.c |  36 ++-
 drivers/gpu/drm/i915/gvt/scheduler.c|  25 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |  56 ++---
 drivers/gpu/drm/i915/i915_pvinfo.h  |   5 +-
 drivers/gpu/drm/i915/intel_gvt.c|   2 +
 21 files changed, 612 insertions(+), 203 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Enable KVMGT for BXT

[Zhenyu Wang]

On 2018.06.11 10:09:52 +0100, Chris Wilson wrote:
> Quoting Patchwork (2018-06-11 10:05:46)
> > == Series Details ==
> > 
> > Series: drm/i915/gvt: Enable KVMGT for BXT
> > URL   : https://patchwork.freedesktop.org/series/44551/
> > State : success
> > 
> > == Summary ==
> > 
> > = CI Bug Log - changes from CI_DRM_4299 -> Patchwork_9253 =
> > 
> > == Summary - SUCCESS ==
> > 
> >   No regressions found.
> > 
> >   External URL: 
> > https://patchwork.freedesktop.org/api/1.0/series/44551/revisions/1/mbox/
> 
> While we have your attention, please note that all the gvtdvm machines
> are failing on suspend. Could you please investigate as it means we have
> no coverage at all for the impact on gvt of any patch?

Chris, where can we check current gvt-d config on CI machine?

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-fixes for 4.17

[Zhenyu Wang]

On 2018.04.19 15:39:48 +0800, Zhenyu Wang wrote:
> 
> Hi,
> 
> Here's current gvt fixes for 4.17 with several kernel warning
> and other misc fixes as detailed below.
> 
> p.s: I'll be on vacation from next week till May 2, Zhi will cover for me.
> 
> Thanks
> --

Looks this one got missed for merge...just found when trying to apply new
change that caused conflict..Pls help to merge and will request a backmerge
to apply -next change against those.

thanks

> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> 
>   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-04-19
> 
> for you to fetch changes up to 39b4cbadb9a95bf3f13ea102d6ec841940916ee2:
> 
>   drm/i915/kvmgt: Check the pfn got from vfio_pin_pages (2018-04-17 10:46:49 
> +0800)
> 
> 
> gvt-fixes-2018-04-19
> 
> - cmd parser error path mem leak fix (Colin)
> - fix dp aux header validation (Changbin)
> - sanity check on pfn after vfio pin page (Changbin)
> - fix msi eventfd put (Xiong)
> 
> 
> Changbin Du (2):
>   drm/i915/gvt: Fix the validation on size field of dp aux header
>   drm/i915/kvmgt: Check the pfn got from vfio_pin_pages
> 
> Colin Ian King (1):
>   drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path
> 
> Xiong Zhang (1):
>   drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore
> 
> Zhenyu Wang (1):
>   Back merge 'drm-intel-fixes' into gvt-fixes
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
>  drivers/gpu/drm/i915/gvt/display.h|  2 +-
>  drivers/gpu/drm/i915/gvt/handlers.c   | 13 +
>  drivers/gpu/drm/i915/gvt/kvmgt.c  | 34 +-
>  4 files changed, 44 insertions(+), 6 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827



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


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] vfio/mdev: Check globally for duplicate devices

[Zhenyu Wang]

On 2018.05.22 09:53:37 -0600, Alex Williamson wrote:
> [Cc +GVT-g maintainers/lists]
> 
> On Tue, 22 May 2018 10:13:46 +0200
> Cornelia Huck <coh...@redhat.com> wrote:
> 
> > On Fri, 18 May 2018 13:10:25 -0600
> > Alex Williamson <alex.william...@redhat.com> wrote:
> > 
> > > When we create an mdev device, we check for duplicates against the
> > > parent device and return -EEXIST if found, but the mdev device
> > > namespace is global since we'll link all devices from the bus.  We do
> > > catch this later in sysfs_do_create_link_sd() to return -EEXIST, but
> > > with it comes a kernel warning and stack trace for trying to create
> > > duplicate sysfs links, which makes it an undesirable response.
> > > 
> > > Therefore we should really be looking for duplicates across all mdev
> > > parent devices, or as implemented here, against our mdev device list.
> > > Using mdev_list to prevent duplicates means that we can remove
> > > mdev_parent.lock, but in order not to serialize mdev device creation
> > > and removal globally, we add mdev_device.active which allows UUIDs to
> > > be reserved such that we can drop the mdev_list_lock before the mdev
> > > device is fully in place.
> > > 
> > > Two behavioral notes; first, mdev_parent.lock had the side-effect of
> > > serializing mdev create and remove ops per parent device.  This was
> > > an implementation detail, not an intentional guarantee provided to
> > > the mdev vendor drivers.  Vendor drivers can trivially provide this
> > > serialization internally if necessary.  Second, review comments note
> > > the new -EAGAIN behavior when the device, and in particular the remove
> > > attribute, becomes visible in sysfs.  If a remove is triggered prior
> > > to completion of mdev_device_create() the user will see a -EAGAIN
> > > error.  While the errno is different, receiving an error during this
> > > period is not, the previous implementation returned -ENODEV for the
> > > same condition.  Furthermore, the consistency to the user is improved
> > > in the case where mdev_device_remove_ops() returns error.  Previously
> > > concurrent calls to mdev_device_remove() could see the device
> > > disappear with -ENODEV and return in the case of error.  Now a user
> > > would see -EAGAIN while the device is in this transitory state.
> > > 
> > > Signed-off-by: Alex Williamson <alex.william...@redhat.com>
> > > ---
> > >  Documentation/vfio-mediated-device.txt |5 ++
> > >  drivers/vfio/mdev/mdev_core.c  |  102 
> > > +++-
> > >  drivers/vfio/mdev/mdev_private.h   |2 -
> > >  3 files changed, 42 insertions(+), 67 deletions(-)  
> > 
> > Reviewed-by: Cornelia Huck <coh...@redhat.com>
> > 
> > I think it is better to deal with any possible vendor driver
> > implications on top of this (I still believe that vfio-ccw is fine).
> 
> Thanks Cornelia.  So if vfio-ccw is fine, presumably NVIDIA is fine,
> then this leaves GVT-g to see if there's any fallout.  Zhenyu & Zhi,
> I've linked the series under discussion here below[1].  The question to
> you is the first of the two behavioral notes listed above, does GVT-g
> have any dependency on the mdev core providing serialization per mdev
> parent device for the create and remove callbacks within the
> mdev_parent_ops?  This was never an intended feature of the
> implementation and as noted it should be trivial for for an mdev vendor
> driver to provide equivalent course grained serialization if
> necessary.  Of course it would be better to implement that sooner
> rather than later if required.
> 
> I see that __intel_gvt_create_vgpu() makes use of gvt->lock, which
> would seem to already provide this level of per-parent locking. The
> remove path makes use of this same lock, so I think we're ok, but
> looking for an explicit ack so there are no surprises.  I'd like
> to queue this series for v4.18.  Thanks,
> 

yeah, we don't expect mdev core for parent serialization for create and
remove of mdev device. Series look good to me.

Acked-by: Zhenyu Wang <zhen...@linux.intel.com>


> Alex
> 
> [1] https://lkml.org/lkml/2018/5/18/1035

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.

v2: Move request alloc earlier as already try to track shadow status
depending on request state, which also facilitate to use request->hw_context
for target engine context reference.

Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in 
i915_request")
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Zhi Wang <zhi.a.w...@intel.com>
Cc: Weinan Li <weinan.z...@intel.com>
Signed-off-by: Zhenyu Wang <zhen...@linux.intel.com>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 52 +---
 1 file changed, 16 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index e1760030dda1..7f5e01df95ee 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -348,6 +348,7 @@ int intel_gvt_scan_and_shadow_workload(struct 
intel_vgpu_workload *workload)
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
struct intel_engine_cs *engine = dev_priv->engine[workload->ring_id];
struct intel_context *ce;
+   struct i915_request *rq;
int ret;
 
lockdep_assert_held(_priv->drm.struct_mutex);
@@ -386,46 +387,26 @@ int intel_gvt_scan_and_shadow_workload(struct 
intel_vgpu_workload *workload)
goto err_shadow;
}
 
-   ret = populate_shadow_context(workload);
-   if (ret)
-   goto err_shadow;
-
-   return 0;
-
-err_shadow:
-   release_shadow_wa_ctx(>wa_ctx);
-err_unpin:
-   intel_context_unpin(ce);
-   return ret;
-}
-
-static int intel_gvt_generate_request(struct intel_vgpu_workload *workload)
-{
-   int ring_id = workload->ring_id;
-   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
-   struct i915_request *rq;
-   struct intel_vgpu *vgpu = workload->vgpu;
-   struct intel_vgpu_submission *s = >submission;
-   struct i915_gem_context *shadow_ctx = s->shadow_ctx;
-   int ret;
-
-   rq = i915_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
+   rq = i915_request_alloc(engine, shadow_ctx);
if (IS_ERR(rq)) {
gvt_vgpu_err("fail to allocate gem request\n");
ret = PTR_ERR(rq);
-   goto err_unpin;
+   goto err_shadow;
}
-
-   gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
-
workload->req = i915_request_get(rq);
-   ret = copy_workload_to_ring_buffer(workload);
+
+   ret = populate_shadow_context(workload);
if (ret)
-   goto err_unpin;
-   return 0;
+   goto err_req;
 
-err_unpin:
+   return 0;
+err_req:
+   rq = fetch_and_zero(>req);
+   i915_request_put(rq);
+err_shadow:
release_shadow_wa_ctx(>wa_ctx);
+err_unpin:
+   intel_context_unpin(ce);
return ret;
 }
 
@@ -609,7 +590,7 @@ static int prepare_workload(struct intel_vgpu_workload 
*workload)
goto err_unpin_mm;
}
 
-   ret = intel_gvt_generate_request(workload);
+   ret = copy_workload_to_ring_buffer(workload);
if (ret) {
gvt_vgpu_err("fail to generate request\n");
goto err_unpin_mm;
@@ -823,7 +804,7 @@ static void complete_current_workload(struct intel_gvt 
*gvt, int ring_id)
scheduler->current_workload[ring_id];
struct intel_vgpu *vgpu = workload->vgpu;
struct intel_vgpu_submission *s = >submission;
-   struct i915_request *rq;
+   struct i915_request *rq = workload->req;
int event;
 
mutex_lock(>lock);
@@ -832,7 +813,6 @@ static void complete_current_workload(struct intel_gvt 
*gvt, int ring_id)
 * switch to make sure request is completed.
 * For the workload w/o request, directly complete the workload.
 */
-   rq = fetch_and_zero(>req);
if (rq) {
wait_event(workload->shadow_ctx_status_wq,
   !atomic_read(>shadow_ctx_active));
@@ -863,7 +843,7 @@ static void complete_current_workload(struct intel_gvt 
*gvt, int ring_id)
intel_context_unpin(rq->hw_context);
mutex_unlock(>i915->drm.struct_mutex);
 
-   i915_request_put(rq);
+   i915_request_put(fetch_and_zero(>req));
}
 
gvt_dbg_sched("ring id %d complete workload %p status %d\n",
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

On 2018.05.18 11:22:06 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-05-18 11:13:05)
> > When we do shadowing, workload's request might not be allocated yet,
> > so we still require shadow context's object. And when complete workload,
> > delay to zero workload's request pointer after used for update guest 
> > context.
> 
> Please allocate the context earlier then. The point is that until you
> do, shadow_ctx->__engine[ring_id]->state is *undefined* and this code is
> still illegal. :-p
> 
> The intent is that you start tracking the lifetime of the state you are
> using because the assumptions made here will not hold for much longer.

Chris, after double check, for shadowing we do assure to pin our
context earlier for target engine context, so 
shadow_ctx->__engine[ring_id]->state
is always valid. We just don't require the real request be generated earlier
during scan/shadow, so use pinned context state pointer directly. Will that be
a problem in future?

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ??? Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

On 2018.05.18 12:03:02 +0100, Chris Wilson wrote:
> Quoting Patchwork (2018-05-18 11:55:01)
> > == Series Details ==
> > 
> > Series: drm/i915/gvt: Fix crash after request->hw_context change
> > URL   : https://patchwork.freedesktop.org/series/43406/
> > State : failure
> > 
> > == Summary ==
> > 
> > Applying: drm/i915/gvt: Fix crash after request->hw_context change
> > error: sha1 information is lacking or useless 
> > (drivers/gpu/drm/i915/gvt/scheduler.c).
> > error: could not build fake ancestor
> > Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context 
> > change
> 
> Wrong tree used as teh baseline, could you resend? Or an alternative to
> avoid dereferencing state outside of being pinned?

Sorry, applied against gvt dev tree which has unmerged ones against
dinq. Current code is to try to do possible shadowing earlier even not
requiring real request be allocated, need to relook for proper lifetime
to sort this out.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gvt: Fix crash after request->hw_context change

[Zhenyu Wang]

When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.

Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in 
i915_request")
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Signed-off-by: Zhenyu Wang <zhen...@linux.intel.com>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 2efb723b90cb..00f79fc940da 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -125,8 +125,9 @@ static int populate_shadow_context(struct 
intel_vgpu_workload *workload)
struct intel_vgpu *vgpu = workload->vgpu;
struct intel_gvt *gvt = vgpu->gvt;
int ring_id = workload->ring_id;
+   struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   workload->req->hw_context->state->obj;
+   shadow_ctx->__engine[ring_id].state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
void *dst;
@@ -595,8 +596,6 @@ static int prepare_workload(struct intel_vgpu_workload 
*workload)
return ret;
}
 
-   update_shadow_pdps(workload);
-
ret = intel_vgpu_sync_oos_pages(workload->vgpu);
if (ret) {
gvt_vgpu_err("fail to vgpu sync oos pages\n");
@@ -615,6 +614,8 @@ static int prepare_workload(struct intel_vgpu_workload 
*workload)
goto err_unpin_mm;
}
 
+   update_shadow_pdps(workload);
+
ret = prepare_shadow_batch_buffer(workload);
if (ret) {
gvt_vgpu_err("fail to prepare_shadow_batch_buffer\n");
@@ -825,7 +826,7 @@ static void complete_current_workload(struct intel_gvt 
*gvt, int ring_id)
scheduler->current_workload[ring_id];
struct intel_vgpu *vgpu = workload->vgpu;
struct intel_vgpu_submission *s = >submission;
-   struct i915_request *rq;
+   struct i915_request *rq = workload->req;
int event;
 
mutex_lock(>vgpu_lock);
@@ -835,7 +836,6 @@ static void complete_current_workload(struct intel_gvt 
*gvt, int ring_id)
 * switch to make sure request is completed.
 * For the workload w/o request, directly complete the workload.
 */
-   rq = fetch_and_zero(>req);
if (rq) {
wait_event(workload->shadow_ctx_status_wq,
   !atomic_read(>shadow_ctx_active));
@@ -866,7 +866,7 @@ static void complete_current_workload(struct intel_gvt 
*gvt, int ring_id)
intel_context_unpin(rq->hw_context);
mutex_unlock(>i915->drm.struct_mutex);
 
-   i915_request_put(rq);
+   i915_request_put(fetch_and_zero(>req));
}
 
gvt_dbg_sched("ring id %d complete workload %p status %d\n",
-- 
2.17.0

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store a pointer to intel_context in i915_request

[Zhenyu Wang]

On 2018.05.18 09:42:47 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-05-18 08:43:33)
> > 
> > On 18/05/2018 04:21, Zhenyu Wang wrote:
> > > On 2018.05.17 22:26:32 +0100, Chris Wilson wrote:
> > >> To ease the frequent and ugly pointer dance of
> > >> >gem_context->engine[request->engine->id] during request
> > >> submission, store that pointer as request->hw_context. One major
> > >> advantage that we will exploit later is that this decouples the logical
> > >> context state from the engine itself.
> > >>
> > >> v2: Set mock_context->ops so we don't crash and burn in selftests.
> > >>  Cleanups from Tvrtko.
> > >>
> > >> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> > >> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> > >> ---
> > >>   drivers/gpu/drm/i915/gvt/mmio_context.c   |   6 +-
> > >>   drivers/gpu/drm/i915/gvt/mmio_context.h   |   2 +-
> > >>   drivers/gpu/drm/i915/gvt/scheduler.c  | 141 +++---
> > >>   drivers/gpu/drm/i915/gvt/scheduler.h  |   1 -
> > > 
> > > gvt change looks fine to me.
> > > 
> > > Acked-by: Zhenyu Wang <zhen...@linux.intel.com>
> > 
> > Excellent, thanks!
> > 
> > And I think I already have my r-b earlier for non-GVT parts. So let me 
> > repeat it:
> > 
> > Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> 
> Thanks. Applied, please yell if I broke anything, or better yet donate
> some machines to testing intel-gfx@ :)

Well, looks it does break guest boot, patch mail is following. ;)
I do like to have gvt regression test for CI at least for easy case e.g
VM boot normal and better instruct some igt cases after boot. If that's
just machine resource issue, I can raise to mangement to see if anyone
can help.

> 
> There will be a few more changes to make struct intel_context a first
> class citizen for i915_request if Tvrtko manages to whip me or the api
> into shape. So expect a little more upheaval in the coming months.
> I'm thinking an api like:
> 
>   ce = intel_context_get_and_lock(context, engine);
> 
>   rq = i915_request_get(ce);
>   ...
>   i915_request_add(rq);
> 
>   intel_context_put_and_unlock(ce);
> 
> (get_and_lock() is a helper around _get() and _lock())
> 
> In the gvt case, I expect you will want to manage your intel_contexts
> explicitly as the ref/pin/locked phases is slightly longer for you than
> the typical construct-a-request used elsewhere. Note also that the goal
> is to replace the struct_mutex with fine grained locks.

yeah, looks we do need better refactor for those request/context
preparation and shadowing steps, even we've tried twice.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store a pointer to intel_context in i915_request

[Zhenyu Wang]

On 2018.05.17 22:26:32 +0100, Chris Wilson wrote:
> To ease the frequent and ugly pointer dance of
> >gem_context->engine[request->engine->id] during request
> submission, store that pointer as request->hw_context. One major
> advantage that we will exploit later is that this decouples the logical
> context state from the engine itself.
> 
> v2: Set mock_context->ops so we don't crash and burn in selftests.
> Cleanups from Tvrtko.
> 
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> ---
>  drivers/gpu/drm/i915/gvt/mmio_context.c   |   6 +-
>  drivers/gpu/drm/i915/gvt/mmio_context.h   |   2 +-
>  drivers/gpu/drm/i915/gvt/scheduler.c  | 141 +++---
>  drivers/gpu/drm/i915/gvt/scheduler.h  |   1 -

gvt change looks fine to me.

Acked-by: Zhenyu Wang <zhen...@linux.intel.com>

>  drivers/gpu/drm/i915/i915_drv.h   |   1 +
>  drivers/gpu/drm/i915/i915_gem.c   |  12 +-
>  drivers/gpu/drm/i915/i915_gem_context.c   |  17 ++-
>  drivers/gpu/drm/i915/i915_gem_context.h   |  21 ++-
>  drivers/gpu/drm/i915/i915_gpu_error.c |   3 +-
>  drivers/gpu/drm/i915/i915_perf.c  |  25 ++--
>  drivers/gpu/drm/i915/i915_request.c   |  34 ++---
>  drivers/gpu/drm/i915/i915_request.h   |   1 +
>  drivers/gpu/drm/i915/intel_engine_cs.c|  54 ---
>  drivers/gpu/drm/i915/intel_guc_submission.c   |  10 +-
>  drivers/gpu/drm/i915/intel_lrc.c  | 125 +---
>  drivers/gpu/drm/i915/intel_lrc.h  |   7 -
>  drivers/gpu/drm/i915/intel_ringbuffer.c   | 100 -
>  drivers/gpu/drm/i915/intel_ringbuffer.h   |   9 +-
>  drivers/gpu/drm/i915/selftests/mock_context.c |   7 +
>  drivers/gpu/drm/i915/selftests/mock_engine.c  |  41 +++--
>  20 files changed, 321 insertions(+), 296 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
> b/drivers/gpu/drm/i915/gvt/mmio_context.c
> index 0f949554d118..708170e61625 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@ -446,9 +446,9 @@ static void switch_mocs(struct intel_vgpu *pre, struct 
> intel_vgpu *next,
>  
>  #define CTX_CONTEXT_CONTROL_VAL  0x03
>  
> -bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id)
> +bool is_inhibit_context(struct intel_context *ce)
>  {
> - u32 *reg_state = ctx->__engine[ring_id].lrc_reg_state;
> + const u32 *reg_state = ce->lrc_reg_state;
>   u32 inhibit_mask =
>   _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
>  
> @@ -501,7 +501,7 @@ static void switch_mmio(struct intel_vgpu *pre,
>* itself.
>*/
>   if (mmio->in_context &&
> - !is_inhibit_context(s->shadow_ctx, ring_id))
> + 
> !is_inhibit_context(>shadow_ctx->__engine[ring_id]))
>   continue;
>  
>   if (mmio->mask)
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.h 
> b/drivers/gpu/drm/i915/gvt/mmio_context.h
> index 0439eb8057a8..5c3b9ff9f96a 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.h
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.h
> @@ -49,7 +49,7 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
>  
>  void intel_gvt_init_engine_mmio_context(struct intel_gvt *gvt);
>  
> -bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id);
> +bool is_inhibit_context(struct intel_context *ce);
>  
>  int intel_vgpu_restore_inhibit_context(struct intel_vgpu *vgpu,
>  struct i915_request *req);
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 17f9f8d7e148..e1760030dda1 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -54,11 +54,8 @@ static void set_context_pdp_root_pointer(
>  
>  static void update_shadow_pdps(struct intel_vgpu_workload *workload)
>  {
> - struct intel_vgpu *vgpu = workload->vgpu;
> - int ring_id = workload->ring_id;
> - struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
>   struct drm_i915_gem_object *ctx_obj =
> - shadow_ctx->__engine[ring_id].state->obj;
> + workload->req->hw_context->state->obj;
>   struct execlist_ring_context *shadow_ring_context;
>   struct page *page;
>  
> @@ -128,9 +125,8 @@ static int populate_shadow_context(struct 
> intel_vgpu_workload *workload)
>   struct intel_

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Use offsetofend() rather than offsetof + sizeof

[Zhenyu Wang]

On 2018.05.16 17:38:30 +0100, Chris Wilson wrote:
> Quoting Mika Kuoppala (2017-03-16 09:37:44)
> > Chris Wilson <ch...@chris-wilson.co.uk> writes:
> > 
> > > Compute the offset of the end of the crc32 field using offsetofend()
> > > rather than open-coding.
> > >
> > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> > > Cc: Zhenyu Wang <zhen...@linux.intel.com>
> > > Cc: Zhi Wang <zhi.a.w...@intel.com>
> > 
> > Reviewed-by: Mika Kuoppala <mika.kuopp...@intel.com>
> 
> This still applies...
>

Sorry for missed this one! Will pick it up for sure.

> > > ---
> > >  drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
> > > b/drivers/gpu/drm/i915/gvt/firmware.c
> > > index 933a7c211a1c..3a5a81fcb406 100644
> > > --- a/drivers/gpu/drm/i915/gvt/firmware.c
> > > +++ b/drivers/gpu/drm/i915/gvt/firmware.c
> > > @@ -159,7 +159,7 @@ static int verify_firmware(struct intel_gvt *gvt,
> > >  
> > >   h = (struct gvt_firmware_header *)fw->data;
> > >  
> > > - crc32_start = offsetof(struct gvt_firmware_header, crc32) + 4;
> > > + crc32_start = offsetofend(struct gvt_firmware_header, crc32);
> > >   mem = fw->data + crc32_start;
> > >  
> > >  #define VERIFY(s, a, b) do { \
> > > -- 
> > > 2.11.0
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 04/14] drm/i915/gvt: Detect 64K gtt entry by IPS bit of PDE

[Zhenyu Wang]

On 2018.05.10 16:17:35 +0100, Matthew Auld wrote:
> > @@ -934,6 +944,20 @@ static int ppgtt_invalidate_spt(struct 
> > intel_vgpu_ppgtt_spt *spt)
> > return ret;
> >  }
> >
> > +static bool vgpu_ips_enabled(struct intel_vgpu *vgpu)
> > +{
> > +   if (INTEL_GEN(vgpu->gvt->dev_priv) == 9) {
> > +   u32 ips = vgpu_vreg_t(vgpu, GEN8_GAMW_ECO_DEV_RW_IA) &
> > +   GAMW_ECO_ENABLE_64K_IPS_FIELD;
> > +
> > +   return ips == GAMW_ECO_ENABLE_64K_IPS_FIELD;
> > +   } else if (INTEL_GEN(vgpu->gvt->dev_priv) >= 10) {
> > +   /* 64K paging only controlled by IPS bit in PTE now. */
> > +   return true;
> 
> AFAIK the funny business with having to enable the IPS bit through
> mmio is also needed on GEN10.

yeah, looks it only won't be needed from Gen11.

Thanks for review! Will update that.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next for 4.17

[Zhenyu Wang]

On 2018.04.19 12:34:16 +0300, Jani Nikula wrote:
> On Thu, 19 Apr 2018, Zhi Wang  wrote:
> > Hi:
> >
> > Here is the pull request of gvt-next for 4.17 with some new features and 
> > optimizations.
> >
> > Thanks,
> > Zhi.
> >
> > --
> > The following changes since commit fadec6eefe232696c5c471b40df33e6db616e854:
> >
> >drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)
> >
> > are available in the git repository at:
> >
> >https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-19
> >
> > for you to fetch changes up to c0fb4098fc47dcaeb47085c08d8fafa42fa8e471:
> >
> >drm/i915/gvt: Mark expected switch fall-through in 
> > handle_g2v_notification (2018-04-19 16:35:55 +0800)
> >
> > 
> > - Minor condition check improvment (Gustavo A. R. Silva)
> > - Reverting GVT context priority hack (Weinan Li)
> > - Non-priviliged batch buffer scan (Yan Zhao)
> > - Scheduling optimizations (Zhipeng Gong)
> >
> > 
> > Gustavo A. R. Silva (2):
> >drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
> >drm/i915/gvt: Mark expected switch fall-through in 
> > handle_g2v_notification
> >
> > Weinan Li (1):
> >Revert "drm/i915/gvt: set max priority for gvt context"
> 
> This reverts a commit in v4.15. Why is it in a -next pull and not a
> -fixes pull?

This one was originally queued for 4.17 in gvt-next-fixes, but declined as
Joonas thought this is new feature as enabling vGPU priority scheduling,
https://lists.freedesktop.org/archives/intel-gfx/2018-March/160431.html

> 
> It also conflicts, please advise how to resolve:
> 
> diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
> index f3d21849b0cb,080fb5027d9c..
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@@ -1134,9 -1156,6 +1156,12 @@@ int intel_vgpu_setup_submission(struct 
> if (IS_ERR(s->shadow_ctx))
> return PTR_ERR(s->shadow_ctx);
>   
> ++<<< HEAD
>  +  if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv))
>  +  s->shadow_ctx->sched.priority = INT_MAX;
>  +
> ++===
> ++>>> c2f6410ef67740ebcbf5d92dffc2679d4a0e288c
> bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES);
>   
> s->workloads = kmem_cache_create_usercopy("gvt-g_vgpu_workload",
> 
> Finally, it's committed by Zhi Wang  but without
> his Signed-off-by.
> 
> 
> BR,
> Jani.
> 
> 
> >
> > Zhao Yan (1):
> >drm/i915/gvt: scan non-privileged batch buffer for debug purpose
> >
> > Zhipeng Gong (2):
> >drm/i915/gvt: Use real time to do timer check
> >drm/i915/gvt: Update time slice more frequently
> >
> >   drivers/gpu/drm/i915/gvt/cmd_parser.c   | 55 +++---
> >   drivers/gpu/drm/i915/gvt/debugfs.c  | 67 
> > 
> >   drivers/gpu/drm/i915/gvt/gvt.h  |  1 +
> >   drivers/gpu/drm/i915/gvt/handlers.c |  1 +
> >   drivers/gpu/drm/i915/gvt/sched_policy.c | 31 ---
> >   drivers/gpu/drm/i915/gvt/scheduler.c| 69 
> > +
> >   drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
> >   drivers/gpu/drm/i915/gvt/trace.h| 24 +---
> >   8 files changed, 193 insertions(+), 56 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-fixes for 4.17

[Zhenyu Wang]

Hi,

Here's current gvt fixes for 4.17 with several kernel warning
and other misc fixes as detailed below.

p.s: I'll be on vacation from next week till May 2, Zhi will cover for me.

Thanks
--
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-04-19

for you to fetch changes up to 39b4cbadb9a95bf3f13ea102d6ec841940916ee2:

  drm/i915/kvmgt: Check the pfn got from vfio_pin_pages (2018-04-17 10:46:49 
+0800)


gvt-fixes-2018-04-19

- cmd parser error path mem leak fix (Colin)
- fix dp aux header validation (Changbin)
- sanity check on pfn after vfio pin page (Changbin)
- fix msi eventfd put (Xiong)


Changbin Du (2):
  drm/i915/gvt: Fix the validation on size field of dp aux header
  drm/i915/kvmgt: Check the pfn got from vfio_pin_pages

Colin Ian King (1):
  drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path

Xiong Zhang (1):
  drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore

Zhenyu Wang (1):
  Back merge 'drm-intel-fixes' into gvt-fixes

 drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
 drivers/gpu/drm/i915/gvt/display.h|  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 13 +
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 34 +-
 4 files changed, 44 insertions(+), 6 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: Deliver guest cursor hotspot info

[Zhenyu Wang]

On 2018.04.16 13:51:38 +0800, Tina Zhang wrote:
> Guest OS driver uses PV info registers to deliver cursor hotspot info
> to host. This patch is used to get cursor hotspot info from virtual
> registers and deliver it to host userspace.
> 
> v3->v4:
> - return UINT_MAX when x_hot/y_hot is invalid. (Zhenyu)
> - correct version.
> 
> v2->v3:
> - add validate_hotspot(). (Zhenyu)
> 
> v1->v2:
> - name as cursor_x_hot/cursor_y_hot. (Zhenyu)
> - use i915_reg_t definition instead of magic numbers. (Zhenyu)
> 
> Signed-off-by: Tina Zhang <tina.zh...@intel.com>
> Cc: Zhenyu Wang <zhen...@linux.intel.com>
> Cc: Zhi Wang <zhi.a.w...@intel.com>
> Cc: Gerd Hoffmann <kra...@redhat.com>
> ---
>  drivers/gpu/drm/i915/gvt/dmabuf.c | 22 --
>  drivers/gpu/drm/i915/gvt/fb_decoder.c |  3 +++
>  drivers/gpu/drm/i915/gvt/handlers.c   |  4 ++--
>  drivers/gpu/drm/i915/gvt/vgpu.c   |  3 +++
>  drivers/gpu/drm/i915/i915_pvinfo.h|  5 -
>  5 files changed, 28 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c 
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 6f4f8e9..a7c7082 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -192,6 +192,14 @@ static struct drm_i915_gem_object 
> *vgpu_create_gem(struct drm_device *dev,
>   return obj;
>  }
>  
> +static bool validate_hotspot(struct intel_vgpu_cursor_plane_format *c)
> +{
> + if (c && (c->x_hot <= c->width) && (c->y_hot <= c->height))
> + return true;

No way c could be NULL here.

> + else
> + return false;
> +}
> +
>  static int vgpu_get_plane_info(struct drm_device *dev,
>   struct intel_vgpu *vgpu,
>   struct intel_vgpu_fb_info *info,
> @@ -229,12 +237,14 @@ static int vgpu_get_plane_info(struct drm_device *dev,
>   info->x_pos = c.x_pos;
>   info->y_pos = c.y_pos;
>  
> - /* The invalid cursor hotspot value is delivered to host
> -  * until we find a way to get the cursor hotspot info of
> -  * guest OS.
> -  */
> - info->x_hot = UINT_MAX;
> - info->y_hot = UINT_MAX;
> + if (validate_hotspot()) {
> + info->x_hot = c.x_hot;
> + info->y_hot = c.y_hot;
> + } else {
> + info->x_hot = UINT_MAX;
> + info->y_hot = UINT_MAX;
> + }
> +
>   info->size = (((info->stride * c.height * c.bpp) / 8)
>   + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
>   } else {
> diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c 
> b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> index 1c12068..5e7468b 100644
> --- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
> +++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> @@ -36,6 +36,7 @@
>  #include 
>  #include "i915_drv.h"
>  #include "gvt.h"
> +#include "i915_pvinfo.h"
>  
>  #define PRIMARY_FORMAT_NUM   16
>  struct pixel_format {
> @@ -384,6 +385,8 @@ int intel_vgpu_decode_cursor_plane(struct intel_vgpu 
> *vgpu,
>   plane->y_pos = (val & _CURSOR_POS_Y_MASK) >> _CURSOR_POS_Y_SHIFT;
>   plane->y_sign = (val & _CURSOR_SIGN_Y_MASK) >> _CURSOR_SIGN_Y_SHIFT;
>  
> + plane->x_hot = vgpu_vreg_t(vgpu, vgtif_reg(cursor_x_hot));
> + plane->y_hot = vgpu_vreg_t(vgpu, vgtif_reg(cursor_y_hot));
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index a33c1c3e..2c824a9 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -1201,8 +1201,8 @@ static int pvinfo_mmio_write(struct intel_vgpu *vgpu, 
> unsigned int offset,
>   ret = handle_g2v_notification(vgpu, data);
>   break;
>   /* add xhot and yhot to handled list to avoid error log */
> - case 0x78830:
> - case 0x78834:
> + case _vgtif_reg(cursor_x_hot):
> + case _vgtif_reg(cursor_y_hot):
>   case _vgtif_reg(pdp[0].lo):
>   case _vgtif_reg(pdp[0].hi):
>   case _vgtif_reg(pdp[1].lo):
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index 2e0a02a..bf75300 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -58,6 +58,9 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
>  
>   vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.fence_num)) = vgpu_fence_sz(vgpu);
>  
> + vgpu_v

[Intel-gfx] [PULL] gvt-fixes for 4.17-rc1

[Zhenyu Wang]

Hi,

Here's refreshed fixes for 4.17-rc1 with regression one removed,
contains a few fixes for vfio ioctl and dmabuf interface, properly
dma unmap for ggtt, etc.

thanks
--
The following changes since commit d8303075699292008ae5b2c8fc728d455b994c26:

  drm/i915/gvt: force to set all context control bits from guest (2018-03-19 
17:33:30 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-fixes-2018-04-03

for you to fetch changes up to 10996f802109c83421ca30556cfe36ffc3bebae3:

  drm/i915/gvt: Add drm_format_mod update (2018-03-30 14:47:20 +0800)


gvt-fixes-2018-04-03

- fix unhandled vfio ioctl return value (Gerd)
- no-op user interrupt for vGPU (Zhipeng)
- fix ggtt dma unmap (Changbin)
- fix warning in fb decoder (Xiong)
- dmabuf drm_format_mod fix (Tina)
- misc cleanup


Changbin Du (2):
  drm/i915/gvt: Missed to cancel dma map for ggtt entries
  drm/i915/gvt: Cancel dma map when resetting ggtt entries

Gerd Hoffmann (1):
  drm/i915/gvt: throw error on unhandled vfio ioctls

Gustavo A. R. Silva (1):
  drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification

Tina Zhang (1):
  drm/i915/gvt: Add drm_format_mod update

Xiong Zhang (2):
  drm/i915/gvt: Delete redundant error message in fb_decode.c
  drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
initialization

Zhipeng Gong (1):
  drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser

 drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
 drivers/gpu/drm/i915/gvt/display.c| 10 +++
 drivers/gpu/drm/i915/gvt/dmabuf.c |  1 +
 drivers/gpu/drm/i915/gvt/fb_decoder.c | 27 ++
 drivers/gpu/drm/i915/gvt/gtt.c| 52 ++-
 drivers/gpu/drm/i915/gvt/gtt.h|  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c   |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c  |  2 +-
 8 files changed, 69 insertions(+), 27 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Move vgpu balloon info into i915_virtual_gpu struct

[Zhenyu Wang]

On 2018.04.02 16:37:55 +0800, Xiong Zhang wrote:
> vgpu ballon info consists of four drm_mm_node which is used to reserve
> ggtt space, then linux guest won't use these reserved ggtt space.
> 
> Each vgpu has its own ballon info, so move ballon info into
> i915_virtual_gpu structure.
> 
> Signed-off-by: Xiong Zhang <xiong.y.zh...@intel.com>
> ---

Acked-by: Zhenyu Wang <zhen...@linux.intel.com>

>  drivers/gpu/drm/i915/i915_drv.h  | 14 
>  drivers/gpu/drm/i915/i915_vgpu.c | 47 
> 
>  2 files changed, 37 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 800230b..2adc73d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1301,6 +1301,20 @@ struct i915_workarounds {
>  struct i915_virtual_gpu {
>   bool active;
>   u32 caps;
> +
> + struct balloon_info {
> + /*
> +  * There are up to 2 regions per mappable/unmappable graphic
> +  * memory that might be ballooned. Here, index 0/1 is for
> +  * mappable graphic memory, 2/3 for unmappable graphic memory.
> +  */
> +#define VGPU_MAPPABLE_BALLOON_LOW 0
> +#define VGPU_MAPPABLE_BALLOON_HIGH1
> +#define VGPU_UNMAPPABLE_BALLOON_LOW   2
> +#define VGPU_UNMAPPABLE_BALLOON_HIGH  3
> +#define VGPU_MAX_BALLOON_NUM  4
> + struct drm_mm_node space[VGPU_MAX_BALLOON_NUM];
> + } bl_info;
>  };
>  
>  /* used in computing the new watermarks state */
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 7545686..79d3df4 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -86,17 +86,6 @@ bool intel_vgpu_has_full_48bit_ppgtt(struct 
> drm_i915_private *dev_priv)
>   return dev_priv->vgpu.caps & VGT_CAPS_FULL_48BIT_PPGTT;
>  }
>  
> -struct _balloon_info_ {
> - /*
> -  * There are up to 2 regions per mappable/unmappable graphic
> -  * memory that might be ballooned. Here, index 0/1 is for mappable
> -  * graphic memory, 2/3 for unmappable graphic memory.
> -  */
> - struct drm_mm_node space[4];
> -};
> -
> -static struct _balloon_info_ bl_info;
> -
>  static void vgt_deballoon_space(struct i915_ggtt *ggtt,
>   struct drm_mm_node *node)
>  {
> @@ -128,8 +117,9 @@ void intel_vgt_deballoon(struct drm_i915_private 
> *dev_priv)
>  
>   DRM_DEBUG("VGT deballoon.\n");
>  
> - for (i = 0; i < 4; i++)
> - vgt_deballoon_space(_priv->ggtt, _info.space[i]);
> + for (i = 0; i < VGPU_MAX_BALLOON_NUM; i++)
> + vgt_deballoon_space(_priv->ggtt,
> + _priv->vgpu.bl_info.space[i]);
>  }
>  
>  static int vgt_balloon_space(struct i915_ggtt *ggtt,
> @@ -200,6 +190,7 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
>  int intel_vgt_balloon(struct drm_i915_private *dev_priv)
>  {
>   struct i915_ggtt *ggtt = _priv->ggtt;
> + struct balloon_info *bl_info;
>   unsigned long ggtt_end = ggtt->base.total;
>  
>   unsigned long mappable_base, mappable_size, mappable_end;
> @@ -230,34 +221,39 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
>   return -EINVAL;
>   }
>  
> + bl_info = _priv->vgpu.bl_info;
>   /* Unmappable graphic memory ballooning */
>   if (unmappable_base > ggtt->mappable_end) {
> - ret = vgt_balloon_space(ggtt, _info.space[2],
> - ggtt->mappable_end, unmappable_base);
> + ret = vgt_balloon_space(ggtt,
> + _info->space[VGPU_UNMAPPABLE_BALLOON_LOW],
> + ggtt->mappable_end, unmappable_base);
>  
>   if (ret)
>   goto err;
>   }
>  
>   if (unmappable_end < ggtt_end) {
> - ret = vgt_balloon_space(ggtt, _info.space[3],
> - unmappable_end, ggtt_end);
> + ret = vgt_balloon_space(ggtt,
> + _info->space[VGPU_UNMAPPABLE_BALLOON_HIGH],
> + unmappable_end, ggtt_end);
>   if (ret)
>   goto err_upon_mappable;
>   }
>  
>   /* Mappable graphic memory ballooning */
>   if (mappable_base) {
> - ret = vgt_balloon_space(ggtt, _info.space[0],
> - 0, mappable_base);
> + ret = vgt_balloon_space(ggtt,
> +  

Re: [Intel-gfx] [PATCH] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

[Zhenyu Wang]

On 2018.03.30 07:01:02 +, Zhang, Xiong Y wrote:
> > + Zhi and Zhenyu
> > 
> > Quoting Xiong Zhang (2018-03-29 13:58:41)
> > > Four drm_mm_node are used to reserve guest ggtt space, but some of
> > > them may aren't initialized and used in intel_vgt_balloon(), so these
> > > unused drm_mm_node couldn't be removed through
> > drm_mm_remove_node().
> > 
> > I'm not sure how this slipped by in previous review, but is there an
> > explanation why we have;
> > 
> > static struct _balloon_info_ bl_info;
> > 
> > ... and are not even initializing it?
> > 
> > This should definitely find it's way into dev_priv and be properly 
> > initialized.
> [Zhang, Xiong Y] how about move bl_info into struct i915_virtual_gpu ? so 
> that we could get it through dev_priv->vgpu.bl_info
> 

yep, seems fine to me.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17

[Zhenyu Wang]

On 2018.03.28 16:26:17 +0800, Zhenyu Wang wrote:
> 
> Hi, Joonas
> 
> Here's refreshed pull for 4.17 without that revert patch which
> also include new fixes for ggtt dma unmap and virtual display.
> 

Joonas, pls ignore this one, smoke test pass but seems new issue found
in full test. I'll send you updated one later. Sorry!

> --
> The following changes since commit d8303075699292008ae5b2c8fc728d455b994c26:
> 
>   drm/i915/gvt: force to set all context control bits from guest (2018-03-19 
> 17:33:30 +0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-03-28
> 
> for you to fetch changes up to d35de041470fe08321bd9a7b42483ff653764918:
> 
>   drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
> initialization (2018-03-28 16:15:01 +0800)
> 
> 
> gvt-next-fixes-2018-03-28
> 
> - fix unhandled vfio ioctl return value (Gerd)
> - no-op user interrupt for vGPU (Zhipeng)
> - fix eventfd ctx deference (Xiong)
> - fix ggtt dma unmap (Changbin)
> - fix warning in fb decoder (Xiong)
> - misc cleanup
> 
> 
> Changbin Du (2):
>   drm/i915/gvt: Missed to cancel dma map for ggtt entries
>   drm/i915/gvt: Cancel dma map when resetting ggtt entries
> 
> Gerd Hoffmann (1):
>   drm/i915/gvt: throw error on unhandled vfio ioctls
> 
> Gustavo A. R. Silva (1):
>   drm/i915/gvt: Mark expected switch fall-through in 
> handle_g2v_notification
> 
> Xiong Zhang (3):
>   drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore
>   drm/i915/gvt: Delete redundant error message in fb_decode.c
>   drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
> initialization
> 
> Zhipeng Gong (1):
>   drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
>  drivers/gpu/drm/i915/gvt/display.c| 10 +++
>  drivers/gpu/drm/i915/gvt/fb_decoder.c | 27 ++
>  drivers/gpu/drm/i915/gvt/gtt.c| 52 
> ++-
>  drivers/gpu/drm/i915/gvt/gtt.h|  2 +-
>  drivers/gpu/drm/i915/gvt/handlers.c   |  1 +
>  drivers/gpu/drm/i915/gvt/kvmgt.c  | 18 ++--
>  7 files changed, 83 insertions(+), 28 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827



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


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17

[Zhenyu Wang]

On 2018.03.27 17:39:53 +0300, Joonas Lahtinen wrote:
> Quoting Joonas Lahtinen (2018-03-27 16:42:28)
> > Quoting Zhenyu Wang (2018-03-27 11:39:42)
> > > 
> > > Hi, Joonas
> > > 
> > > Here's this week's gvt-next-fixes queued for 4.17. One notable change
> > > is to revert previous workaround for gvt context preemption, now it
> > > has full support for preemption now. 
> > 
> > I've pulled the patches, but this revert sounds fishy. Is it something
> > that should have been done together with a commit in a batch introduced
> > to 4.17? To me, this sounds much like a feature patch, "enable
> > pre-emption on GVT context" is even written in the tag.
> > 
> > So I'm inclined to drop this patch from -fixes pull.
> 
> On a second thought, I'll drop the whole pull to make it less of a
> hassle with rebases. Please send and updated pull with just the fix
> patches.
>

Hi, Joonas

Here's refreshed pull for 4.17 without that revert patch which
also include new fixes for ggtt dma unmap and virtual display.

thanks
--
The following changes since commit d8303075699292008ae5b2c8fc728d455b994c26:

  drm/i915/gvt: force to set all context control bits from guest (2018-03-19 
17:33:30 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-03-28

for you to fetch changes up to d35de041470fe08321bd9a7b42483ff653764918:

  drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
initialization (2018-03-28 16:15:01 +0800)


gvt-next-fixes-2018-03-28

- fix unhandled vfio ioctl return value (Gerd)
- no-op user interrupt for vGPU (Zhipeng)
- fix eventfd ctx deference (Xiong)
- fix ggtt dma unmap (Changbin)
- fix warning in fb decoder (Xiong)
- misc cleanup


Changbin Du (2):
  drm/i915/gvt: Missed to cancel dma map for ggtt entries
  drm/i915/gvt: Cancel dma map when resetting ggtt entries

Gerd Hoffmann (1):
  drm/i915/gvt: throw error on unhandled vfio ioctls

Gustavo A. R. Silva (1):
  drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification

Xiong Zhang (3):
  drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore
  drm/i915/gvt: Delete redundant error message in fb_decode.c
  drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
initialization

Zhipeng Gong (1):
  drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser

 drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
 drivers/gpu/drm/i915/gvt/display.c| 10 +++
 drivers/gpu/drm/i915/gvt/fb_decoder.c | 27 ++
 drivers/gpu/drm/i915/gvt/gtt.c| 52 ++-
 drivers/gpu/drm/i915/gvt/gtt.h|  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c   |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 18 ++--
 7 files changed, 83 insertions(+), 28 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17

[Zhenyu Wang]

On 2018.03.27 16:42:28 +0300, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2018-03-27 11:39:42)
> > 
> > Hi, Joonas
> > 
> > Here's this week's gvt-next-fixes queued for 4.17. One notable change
> > is to revert previous workaround for gvt context preemption, now it
> > has full support for preemption now. 
> 
> I've pulled the patches, but this revert sounds fishy. Is it something
> that should have been done together with a commit in a batch introduced
> to 4.17? To me, this sounds much like a feature patch, "enable
> pre-emption on GVT context" is even written in the tag.
> 
> So I'm inclined to drop this patch from -fixes pull.
>

The dependent fix has already been queued for 4.17 as commit 702791f7f204
("drm/i915: add schedule out notification of preempted but completed request"),
and before we could revert previous workaround, we had a regression issue which
was later resolved, so this revert was delayed for regression verification and
validation. And now it has passed our full testing, so I consider to push it for
4.17 instead of still keeping previous workaround...

> Is there some specific reason why you don't use Fixes: tagging to
> make it easier to track which patches the fixes apply to, if there are
> some?

yeah, sorry, that's missed. Will fix that against workaround commit and re-send
this pull. Will that be fine for you?

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] more gvt-next-fixes for 4.17

[Zhenyu Wang]

Hi, Joonas

Here's this week's gvt-next-fixes queued for 4.17. One notable change
is to revert previous workaround for gvt context preemption, now it
has full support for preemption now. Others are normal fixes and
optimizations.

Thanks
--
The following changes since commit d8303075699292008ae5b2c8fc728d455b994c26:

  drm/i915/gvt: force to set all context control bits from guest (2018-03-19 
17:33:30 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-03-27

for you to fetch changes up to 21e6e1af36a3c9b1c34bc441e5fa27cb36fbb830:

  drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore 
(2018-03-27 11:20:58 +0800)


gvt-next-fixes-2018-03-27

- fix unhandled vfio ioctl return value (Gerd)
- revert gvt ctx preemption workaround, enable preemption
  on gvt context! (Weinan)
- no-op user interrupt for vGPU (Zhipeng)
- fix eventfd ctx deference (Xiong)
- misc cleanup


Gerd Hoffmann (1):
  drm/i915/gvt: throw error on unhandled vfio ioctls

Gustavo A. R. Silva (1):
  drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification

Weinan Li (1):
  Revert "drm/i915/gvt: set max priority for gvt context"

Xiong Zhang (1):
  drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore

Zhipeng Gong (1):
  drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser

 drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
 drivers/gpu/drm/i915/gvt/handlers.c   |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 18 --
 drivers/gpu/drm/i915/gvt/scheduler.c  |  3 ---
 4 files changed, 18 insertions(+), 5 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs

[Zhenyu Wang]

On 2018.03.22 21:31:33 +, Chris Wilson wrote:
> Quoting Gustavo A. R. Silva (2018-03-22 18:21:54)
> > The checks are misleading and not required [1].
> > 
> > [1] https://lkml.org/lkml/2018/3/19/1792
> > 
> > Addresses-Coverity-ID: 1466017
> > Cc: Chris Wilson 
> > Signed-off-by: Gustavo A. R. Silva 
> Reviewed-by: Chris Wilson 
> 

Looks good to me, I will pick this up, thanks!

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next-fixes for 4.17

[Zhenyu Wang]

Hi, Joonas

Here's gvt-next-fixes update for 4.17. One regression that
caused guest VM gpu hang has been fixed and with other changes
as details below.

Thanks
--
The following changes since commit 22de4e7a531b623962e62ee6d3a39a7e51bdf90e:

  drm/i915/pmu: Work around compiler warnings on some kernel configs 
(2018-03-16 14:35:41 +0200)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-03-20

for you to fetch changes up to d8303075699292008ae5b2c8fc728d455b994c26:

  drm/i915/gvt: force to set all context control bits from guest (2018-03-19 
17:33:30 +0800)


gvt-next-fixes-2018-03-20

- No need warning on untracked regs (Colin)
- Error handling fix for dma unmap (Changbin)
- invalidate shadow ppgtt for vGPU reset (Zhi)
- ensure to update shadow ppgtt after pinned (Zhi)
- force guest ctx ctrl update for sanity (Zhenyu/Xiong)
- one typo fix (Colin)


Changbin Du (1):
  drm/i915/kvmgt: Handle kzalloc failure

Colin Ian King (1):
  drm/i915/gvt: fix spelling mistake: "destoried" -> "destroyed"

Colin Xu (1):
  drm/i915/gvt: Remove reduntant printing of untracked mmio

Zhenyu Wang (1):
  drm/i915/gvt: force to set all context control bits from guest

Zhi Wang (2):
  drm/i915/gvt: Invalidate vGPU PPGTT mm objects during a vGPU reset.
  drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.

 drivers/gpu/drm/i915/gvt/gtt.c   | 24 ++-
 drivers/gpu/drm/i915/gvt/gtt.h   |  1 +
 drivers/gpu/drm/i915/gvt/handlers.c  |  9 +
 drivers/gpu/drm/i915/gvt/kvmgt.c | 22 ++---
 drivers/gpu/drm/i915/gvt/scheduler.c | 37 
 drivers/gpu/drm/i915/gvt/vgpu.c  |  1 +
 6 files changed, 82 insertions(+), 12 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] more gvt-fixes for 4.16

[Zhenyu Wang]

Hi,

Here's more gvt-fixes for final 4.16. Sorry it's a little late,
as Zhi had two days off this week and more regression tests
have been done for this.

Thanks.

--
The following changes since commit 88d3dfb6a69042381161290c7ce19e1f53fc2a66:

  drm/i915: Suspend submission tasklets around wedging (2018-03-05 16:08:31 
-0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-03-15

for you to fetch changes up to 850555d1d31e45fc3e9a2982f81717387e8d5e1b:

  drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field 
(2018-03-15 15:07:22 +0800)


gvt-fixes-2018-03-15

- Two warnings fix for runtime pm and usr copy (Xiong, Zhenyu)
- OA context fix for vGPU profiling (Min)
- privilege batch buffer reloc fix (Fred)


Min He (1):
  drm/i915/gvt: keep oa config in shadow ctx

Xiong Zhang (1):
  drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio

Zhenyu Wang (1):
  drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field

fred gao (1):
  drm/i915/gvt: Correct the privilege shadow batch buffer address

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  8 
 drivers/gpu/drm/i915/gvt/mmio_context.c |  2 +
 drivers/gpu/drm/i915/gvt/scheduler.c| 71 +++--
 drivers/gpu/drm/i915/gvt/scheduler.h|  5 +++
 4 files changed, 82 insertions(+), 4 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH][drm-next] drm/i915/gvt: fix spelling mistake: "destoried" -> "destroyed"

[Zhenyu Wang]

On 2018.03.12 12:43:58 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in gvt_err error message text.
> 
> Signed-off-by: Colin Ian King 
> ---

Thanks Colin, will pick up.

>  drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 0a100a288e6d..8eb76becd676 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -2046,7 +2046,7 @@ static void intel_vgpu_destroy_all_ppgtt_mm(struct 
> intel_vgpu *vgpu)
>   }
>  
>   if (GEM_WARN_ON(!list_empty(>gtt.ppgtt_mm_list_head)))
> - gvt_err("vgpu ppgtt mm is not fully destoried\n");
> + gvt_err("vgpu ppgtt mm is not fully destroyed\n");
>  
>   if (GEM_WARN_ON(!radix_tree_empty(>gtt.spt_tree))) {
>   gvt_err("Why we still has spt not freed?\n");
> -- 
> 2.15.1
> 

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next for 4.17

[Zhenyu Wang]

Hi,

Here's gvt-next update for 4.17. Biggest update is for huge code
refactor of shadow ppgtt from Changbin which is the most obscured
part, and with KBL context save/restore improvement from Weinan,
with other fixes.

Thanks.
--
The following changes since commit 1f267a572b573b0b155022750cba93001f4367a8:

  drm/i915: Update DRIVER_DATE to 20180305 (2018-03-05 11:56:15 +0200)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-03-08

for you to fetch changes up to 991ecefbdd4b81719597d6c406df8d26ef5c1546:

  drm/i915/gvt: Return error at the failure of finding page_track (2018-03-06 
14:49:38 +0800)


gvt-next-2018-03-08

- big refactor for shadow ppgtt (Changbin)
- KBL context save/restore via LRI cmd (Weinan)
- misc smatch fixes (Zhenyu)
- Properly unmap dma for guest page (Changbin)
- other misc fixes (Xiong, etc.)


Changbin Du (18):
  drm/i915/gvt: Rework shadow graphic memory management code
  drm/i915/gvt: Refine the intel_vgpu_mm reference management
  drm/i915/gvt: Refine ggtt and ppgtt root entry ops
  drm/i915/gvt: Refine ggtt_set_shadow_entry
  drm/i915/gvt: Add verbose gtt shadow logs
  drm/i915/gvt: Rename ggtt related functions to be more specific
  drm/i915/gvt: Factor out intel_vgpu_{get, put}_ppgtt_mm interface
  drm/i915/gvt: Use standard pte bit definition
  drm/i915/gvt: Refine pte shadowing process
  drm/i915/gvt: Rework shadow page management code
  drm/i915/gvt: Rename shadow_page to short name spt
  drm/i915/gvt: Rename mpt api {set, unset}_wp_page to {enable, 
disable}_page_track
  drm/i915/gvt: Don't extend page_track to mpt layer
  drm/i915/gvt: Provide generic page_track infrastructure for 
write-protected page
  drm/i915/gvt: Manage shadow pages with radix tree
  drm/i915/gvt: Define PTE addr mask with GENMASK_ULL
  drm/i915/gvt: Fix guest vGPU hang caused by very high dma setup overhead
  drm/i915/kvmgt: Add kvmgt debugfs entry nr_cache_entries under vgpu

Weinan Li (3):
  drm/i915/gvt: add define GEN9_MOCS_SIZE
  drm/i915/gvt: add interface to check if context is inhibit
  drm/i915/gvt: init mmio by lri command in vgpu inhibit context

Xiong Zhang (2):
  drm/i915/gvt: Release gvt->lock at the failure of finding page track
  drm/i915/gvt: Return error at the failure of finding page_track

Zhenyu Wang (7):
  drm/i915/gvt: Fix one gvt_vgpu_error() use in dmabuf.c
  drm/i915/gvt: remove gvt max port definition
  drm/i915/gvt: Fix vGPU sched timeslice calculation warning
  drm/i915/gvt: Fix check error of vgpu create failure message
  drm/i915/gvt: Fix check error on fence mmio handler
  drm/i915/gvt: Fix one indent error
  drm/i915/gvt: Fix check error on hws_pga_write() fail message

 drivers/gpu/drm/i915/gvt/Makefile   |2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c   |2 +-
 drivers/gpu/drm/i915/gvt/gtt.c  | 1457 ++-
 drivers/gpu/drm/i915/gvt/gtt.h  |  189 ++--
 drivers/gpu/drm/i915/gvt/gvt.c  |2 +-
 drivers/gpu/drm/i915/gvt/gvt.h  |   21 +-
 drivers/gpu/drm/i915/gvt/handlers.c |   38 +-
 drivers/gpu/drm/i915/gvt/hypercall.h|9 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c|  313 ---
 drivers/gpu/drm/i915/gvt/mmio.c |9 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c |  210 -
 drivers/gpu/drm/i915/gvt/mmio_context.h |5 +
 drivers/gpu/drm/i915/gvt/mpt.h  |   67 +-
 drivers/gpu/drm/i915/gvt/page_track.c   |  184 
 drivers/gpu/drm/i915/gvt/page_track.h   |   56 ++
 drivers/gpu/drm/i915/gvt/sched_policy.c |5 +-
 drivers/gpu/drm/i915/gvt/scheduler.c|   44 +-
 drivers/gpu/drm/i915/gvt/trace.h|   10 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |1 +
 19 files changed, 1468 insertions(+), 1156 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/page_track.c
 create mode 100644 drivers/gpu/drm/i915/gvt/page_track.h


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] git-fixes for 4.16-rc2

[Zhenyu Wang]

On 2018.02.20 20:15:22 +, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-02-14 05:28:27)
> > 
> > Hi, here's current gvt-fixes pull for 4.16-rc2, as it is close for
> > chinese new year, team would take one week off at least, so like to
> > send this out before vacation. This has one to fix GTT mmio 8b access
> > from guest and two simple ones for mmio switch and typo fix. And sorry
> > that patchwork link is still not there yet, using dim to pull should
> > be ok but might need direct push to skip dim push check for now.
> 
> There are still quite a few sore points that would be nice to fix:
> 
> drivers/gpu/drm/i915/gvt/handlers.c:203 sanitize_fence_mmio_access()
> error: 'vgpu' dereferencing possible ERR_PTR()
> drivers/gpu/drm/i915/gvt/handlers.c:323 gdrst_mmio_write() warn:
> inconsistent indenting
> drivers/gpu/drm/i915/gvt/handlers.c:871 dp_aux_ch_ctl_mmio_write()
> error: buffer overflow 'display->ports' 5 <= 5
> drivers/gpu/drm/i915/gvt/handlers.c:1392 hws_pga_write() error: 'vgpu'
> dereferencing possible ERR_PTR()
> drivers/gpu/drm/i915/gvt/handlers.c:1402 hws_pga_write() error: 'vgpu'
> dereferencing possible ERR_PTR()
> 
> + Lots of kerneldoc errors that should be tidied up.

Chris, thanks for this, we will double check those smatch warnings.

Strange thing is that 0day kernel does run kinds of static checker
against our tree, but seems reports are sent to Dan instead of our
developers...

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] git-fixes for 4.16-rc2

[Zhenyu Wang]

Hi, here's current gvt-fixes pull for 4.16-rc2, as it is close for
chinese new year, team would take one week off at least, so like to
send this out before vacation. This has one to fix GTT mmio 8b access
from guest and two simple ones for mmio switch and typo fix. And sorry
that patchwork link is still not there yet, using dim to pull should
be ok but might need direct push to skip dim push check for now.

thanks
--
The following changes since commit 4b8b41d15d9db54703958fbd2928a2fd319563f6:

  drm/i915/pmu: Fix building without CONFIG_PM (2018-02-13 16:56:06 -0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-02-14

for you to fetch changes up to 3cc7644e4af179e79153b1fd60f9dd937ee32684:

  drm/i915/gvt: fix one typo of render_mmio trace (2018-02-14 10:35:00 +0800)


gvt-fixes-2018-02-14

- gtt mmio 8b access fix (Tina)
- one KBL required mmio reg for switch (Weinan)
- one trace log typo fix (Weinan)


Tina Zhang (1):
  drm/i915/gvt: Support BAR0 8-byte reads/writes

Weinan Li (2):
  drm/i915/gvt: add 0xe4f0 into gen9 render list
  drm/i915/gvt: fix one typo of render_mmio trace

 drivers/gpu/drm/i915/gvt/kvmgt.c| 51 +++--
 drivers/gpu/drm/i915/gvt/mmio_context.c |  1 +
 drivers/gpu/drm/i915/gvt/trace.h|  2 +-
 3 files changed, 51 insertions(+), 3 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next-fixes for 4.16

[Zhenyu Wang]

On 2018.02.06 11:45:04 -0800, Rodrigo Vivi wrote:
> 
> Hi Zhi,
> 
> Daniel asked few weeks ago about the scripts that you run there,
> but I didn't see any follow-up.
> 
> I don't understand why yet, but apparently gvt pull request
> is not going to patchwork so dim is not able to add the "Link:"
> hence end up without mandatory patchwork links.
>
> Last round I by-pass dim and move forward even without the "Link:"
> if the solution is easier I'd like to do the right thing this time.

I think maybe previously Link tag was not mandatory? Or Daniel
bypassed at that time too? To have patchwork set up for gvt would be
good, as our QA's current infrastruture doesn't require that, so I
didn't push the request for it. Who may we contact to setup for us
now? Or open a fd.o bug?

> 
> Although I'm open to by-pass again,
> I'd like to know if we are in sync to understand what is happening
> again and get that fixed for next time
> 
> Cc: Daniel in case he know a quick fix or can at least provide more
> info there on what could be failing.

As we'd like to make those stable fixes in upstream soon, maybe better
bypass for lacking Link tag at this time, we'll try to fix that from
next pull. Sorry for any inconvenience.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next fixes for 4.16

[Zhenyu Wang]

On 2018.01.17 08:03:49 -0800, Rodrigo Vivi wrote:
> > 
> > Zhenyu Wang (2):
> >   drm/i915/gvt: cancel virtual vblank timer when no vGPU exists
> >   drm/i915/gvt: cancel scheduler timer when no vGPU exists
> 
> dim: ERROR: 0eb582541cfd7a17b6fcf9282c966c0e59efd02f is lacking mandatory 
> review, aborting
> 
> Is it possible to get someone to quickly review it and fix the original 
> commit, like last time?
> 

yeah that two have been on gvt list for a while and seems people
are fine with it and no regression for nightly test, I'll ask Zhi
to ack and should be able to resend pull today. I need to update
gvt tool to apply that rule as well.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-next fixes for 4.16

[Zhenyu Wang]

On 2018.01.17 08:03:49 -0800, Rodrigo Vivi wrote:
> 
> dim: ERROR: 0eb582541cfd7a17b6fcf9282c966c0e59efd02f is lacking mandatory 
> review, aborting
> 
> Is it possible to get someone to quickly review it and fix the original 
> commit, like last time?
> 

Hi, Rodrigo

Zhi has quickly helped to ack on that and here's updated pull for 4.16-rc1.

thanks
--
The following changes since commit 4fafba2d73fcaf1b433c26e753a98ad4b231754a:

  drm/i915/gvt: move write protect handler out of mmio emulation function 
(2017-12-22 16:33:50 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-01-18

for you to fetch changes up to 9c2341f767455848a049705d2df7ad60d2c93d5e:

  drm/i915/gvt: cancel scheduler timer when no vGPU exists (2018-01-18 14:03:10 
+0800)


gvt-next-2018-01-18:

- mmio switch regression fix (Xiong)
- dmabuf reference fix (Tina)
- one I915_NUM_ENGINES usage fix impacted by new hw enabling change (Michel)
- sanity check for valid gfn when shadow (Henry)
- keep gvt service thread quiet without vGPU (Zhenyu)


Hang Yuan (1):
  drm/i915/gvt: validate gfn before set shadow page entry

Michel Thierry (1):
  drm/i915/gvt: Do not use I915_NUM_ENGINES to iterate over the mocs regs 
array

Pei Zhang (1):
  drm/i915/gvt: add PLANE_KEYMAX regs to mmio track list

Tina Zhang (1):
  drm/i915/gvt: Keep obj->dma_buf link NULL during exporting

Xiong Zhang (1):
  drm/i915/gvt: Fix gen8/9_render_mmio_list[0] don't take effect

Zhenyu Wang (2):
  drm/i915/gvt: cancel virtual vblank timer when no vGPU exists
  drm/i915/gvt: cancel scheduler timer when no vGPU exists

 drivers/gpu/drm/i915/gvt/dmabuf.c   |  1 -
 drivers/gpu/drm/i915/gvt/gtt.c  | 24 +++-
 drivers/gpu/drm/i915/gvt/handlers.c |  3 +++
 drivers/gpu/drm/i915/gvt/hypercall.h|  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c| 16 
 drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-
 drivers/gpu/drm/i915/gvt/mpt.h  | 17 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  7 +++
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 9 files changed, 70 insertions(+), 11 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-next fixes for 4.16

[Zhenyu Wang]

Hi,

Here's queued gvt-next fixes for 4.16-rc1. Mostly with regression
fixes on vGPU display dmabuf, mmio switch and other misc changes,
details below.

thanks
--
The following changes since commit 4fafba2d73fcaf1b433c26e753a98ad4b231754a:

  drm/i915/gvt: move write protect handler out of mmio emulation function 
(2017-12-22 16:33:50 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-01-17

for you to fetch changes up to 0eb582541cfd7a17b6fcf9282c966c0e59efd02f:

  drm/i915/gvt: cancel scheduler timer when no vGPU exists (2018-01-16 10:23:42 
+0800)


gvt-next-2018-01-17:

- mmio switch regression fix (Xiong)
- dmabuf reference fix (Tina)
- one I915_NUM_ENGINES usage fix impacted by new hw enabling change (Michel)
- sanity check for valid gfn when shadow (Henry)
- keep gvt service thread quiet without vGPU (Zhenyu)


Hang Yuan (1):
  drm/i915/gvt: validate gfn before set shadow page entry

Michel Thierry (1):
  drm/i915/gvt: Do not use I915_NUM_ENGINES to iterate over the mocs regs 
array

Pei Zhang (1):
  drm/i915/gvt: add PLANE_KEYMAX regs to mmio track list

Tina Zhang (1):
  drm/i915/gvt: Keep obj->dma_buf link NULL during exporting

Xiong Zhang (1):
  drm/i915/gvt: Fix gen8/9_render_mmio_list[0] don't take effect

Zhenyu Wang (2):
  drm/i915/gvt: cancel virtual vblank timer when no vGPU exists
  drm/i915/gvt: cancel scheduler timer when no vGPU exists

 drivers/gpu/drm/i915/gvt/dmabuf.c   |  1 -
 drivers/gpu/drm/i915/gvt/gtt.c  | 24 +++-
 drivers/gpu/drm/i915/gvt/handlers.c |  3 +++
 drivers/gpu/drm/i915/gvt/hypercall.h|  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c| 16 
 drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-
 drivers/gpu/drm/i915/gvt/mpt.h  | 17 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  7 +++
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 9 files changed, 70 insertions(+), 11 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active

[Zhenyu Wang]

On 2018.01.15 12:07:28 +0200, Joonas Lahtinen wrote:
> On Fri, 2018-01-12 at 14:08 +0800, Du, Changbin wrote:
> > On Fri, Jan 12, 2018 at 11:32:30AM +0530, Sagar Arun Kamble wrote:
> > > Is skl-gvtdvm not having vGPU active?
> > > 
> > > It has flag X86_FEATURE_HYPERVISOR set however it might be set on host too
> > > so relying intel_vgpu_active().
> > > 
> > 
> > Do you mean flag X86_FEATURE_HYPERVISOR is set on host, too? This is weird 
> > since this
> > flag indicates the OS is running on a hypervisor.
> 
> + CI folks and Zhenyu
> 
> Somehow, magically, the virtual machine seems to starts skipping all
> tests when GuC is disabled?
> 
> Has somebody actually validated that the tests results are valid for
> the virtual machine? Or is this a one-off CI quirk?

Are these tests really run in VM with GVT-g enabled on host?

> 
> PS. I'd do the check as early return condition at the top, like vGPU
> feature disabling elsewhere. It's not much point calculating the
> details (calling into functions like intel_uc_fw_is_selected) and then
> throwing results out afterwards :)
>

yeah, better, and we do plan to support vGuC from ICL for vGPU.

> > 
> > > 
> > > On 1/11/2018 10:27 PM, Patchwork wrote:
> > > > == Series Details ==
> > > > 
> > > > Series: series starting with [1/2] drm/i915/guc: Don't enable GuC when 
> > > > vGPU is active
> > > > URL   : https://patchwork.freedesktop.org/series/36343/
> > > > State : failure
> > > > 
> > > > == Summary ==
> > > > 
> > > > Series 36343v1 series starting with [1/2] drm/i915/guc: Don't enable 
> > > > GuC when vGPU is active
> > > > https://patchwork.freedesktop.org/api/1.0/series/36343/revisions/1/mbox/
> > > > 
> > > > Test core_auth:
> > > >  Subgroup basic-auth:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test core_prop_blob:
> > > >  Subgroup basic:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test debugfs_test:
> > > >  Subgroup read_all_entries:
> > > >  dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test drv_getparams_basic:
> > > >  Subgroup basic-eu-total:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-subslice-total:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test drv_hangman:
> > > >  Subgroup error-state-basic:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_basic:
> > > >  Subgroup bad-close:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup create-close:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup create-fd-close:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_busy:
> > > >  Subgroup basic-busy-default:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-hang-default:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm) fdo#104108 +2
> > > > Test gem_close_race:
> > > >  Subgroup basic-process:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-threads:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_cpu_reloc:
> > > >  Subgroup basic:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_cs_tlb:
> > > >  Subgroup basic-default:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_ctx_create:
> > > >  Subgroup basic:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-files:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_ctx_exec:
> > > >  Subgroup basic:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_ctx_param:
> > > >  Subgroup basic:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-default:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_ctx_switch:
> > > >  Subgroup basic-default:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-default-heavy:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > > Test gem_exec_basic:
> > > >  Subgroup basic-blt:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-bsd:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-bsd1:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-bsd2:
> > > >  pass   -> SKIP   (fi-skl-gvtdvm)
> > > >  Subgroup basic-default:
> > > >  

[Intel-gfx] [PULL] gvt-fixes for 4.15

[Zhenyu Wang]

Hi,

Final gvt fixes for 4.15 with two more fixes. One is to fix
some windows driver issues for shadow gtt from Zhi. Another
is for runtime kasan warning of stack out-of-bound.

thanks
--
The following changes since commit f5f00e7dcc4161f07b76ff1a854e8b1ea7a1ed41:

  drm/i915/gvt: Fix pipe A enable as default for vgpu (2017-12-11 17:23:11 
+0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-01-08

for you to fetch changes up to 65e7439204b57b7a7f6e4694f9e2a9adde5e77ed:

  drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser (2018-01-08 12:01:11 
+0800)


gvt-fixes-2018-01-08

- clear shadow entry for post-sync (Zhi)
- fix stack out-of-bound warning in cmd parser (Changbin)


Changbin Du (1):
  drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser

Zhi Wang (1):
  drm/i915/gvt: Clear the shadow page table entry after post-sync

 drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/gvt/gtt.c| 5 -
 2 files changed, 6 insertions(+), 3 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] more gvt-next for 4.16

[Zhenyu Wang]

On 2017.12.22 09:49:36 +0200, Jani Nikula wrote:
> 
> Yes. We want a minimum of two people looking at each patch. It's pretty
> much irrelevant if the committer/maintainer is the author or not. 2*sob
> or sob+rb or sob+ack, or more for more complicated things.
> 
> It's unfortunately common that the "obviously correct and trivial" patch
> quickly committed by the author without anyone else looking at it is
> actually buggy...
> 
> > If yes, I will apply this rule for gvt tree as well and encourage gvt
> > developer to send a-b/r-b mail as looks people more like to use IM to
> > exchange review comment..
> 
> We don't have a strict rule to always send acks or rb by mail. IRC or IM
> is fine too for simple things. But we want to record the acks and rb in
> the commit regardless. When I push patches that got IRC review, I add
> the tags, and typically reply with something along the lines of, "Pushed
> with J. Random Hacker's IRC review".
> 
> That said, I do encourage explicit ack/rb messages on the lists for
> non-trivial things in the interest of open development and transparency.
> 

Thanks to clarify! Here's updated pull for commits that were verified and
acked by Xiong and Zhi, now with proper r-b tag.

thanks
--
The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:

  drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22

for you to fetch changes up to 4fafba2d73fcaf1b433c26e753a98ad4b231754a:

  drm/i915/gvt: move write protect handler out of mmio emulation function 
(2017-12-22 16:33:50 +0800)


gvt-next-2017-12-22:

- more mmio switch optimization (Weinan)
- cleanup i915_reg_t vs. offset usage (Zhenyu)
- move write protect handler out of mmio handler (Zhenyu)


Weinan Li (4):
  drm/i915/gvt: refine trace_render_mmio
  drm/i915/gvt: optimize for vGPU mmio switch
  drm/i915/gvt: refine mocs save restore policy
  drm/i915/gvt: load host render mocs once in mocs switch

Xiaolin Zhang (1):
  drm/i915/gvt: Fix pipe A enable as default for vgpu

Zhenyu Wang (4):
  Merge tag 'drm-intel-next-2017-12-14' into gvt-next
  drm/i915/gvt: always use i915_reg_t for MMIO handler definition
  drm/i915/gvt: cleanup usage for typed mmio reg vs. offset
  drm/i915/gvt: move write protect handler out of mmio emulation function

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  39 +-
 drivers/gpu/drm/i915/gvt/display.c  |  81 ++--
 drivers/gpu/drm/i915/gvt/edid.c |  22 +-
 drivers/gpu/drm/i915/gvt/fb_decoder.c   |  30 +-
 drivers/gpu/drm/i915/gvt/gtt.c  |  37 +-
 drivers/gpu/drm/i915/gvt/gtt.h  |   3 +
 drivers/gpu/drm/i915/gvt/gvt.c  |   1 +
 drivers/gpu/drm/i915/gvt/gvt.h  |  33 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 750 
 drivers/gpu/drm/i915/gvt/kvmgt.c|   4 +-
 drivers/gpu/drm/i915/gvt/mmio.c |  57 +--
 drivers/gpu/drm/i915/gvt/mmio.h |   7 -
 drivers/gpu/drm/i915/gvt/mmio_context.c | 238 +-
 drivers/gpu/drm/i915/gvt/trace.h|  15 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |  24 +-
 15 files changed, 675 insertions(+), 666 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] more gvt-next for 4.16

[Zhenyu Wang]

On 2017.12.21 19:07:07 -0800, Rodrigo Vivi wrote:
> On Fri, Dec 22, 2017 at 02:43:06AM +0000, Zhenyu Wang wrote:
> > 
> > Hi,
> > 
> > Here's last gvt-next pull for 4.16 merge window. I need to backmerge
> > once for one i915 param change to resolve patch dependence. This includes
> > mmio switch optimization, cleanups for write protect handler and our
> > i915_reg_t vs. offset usage.
> > 
> > thanks
> > --
> > The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:
> > 
> >   drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
> > 
> > for you to fetch changes up to 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7:
> > 
> >   drm/i915/gvt: move write protect handler out of mmio emulation function 
> > (2017-12-21 11:03:27 +0800)
> > 
> > 
> > gvt-next-2017-12-22:
> > 
> > - more mmio switch optimization (Weinan)
> > - cleanup i915_reg_t vs. offset usage (Zhenyu)
> > - move write protect handler out of mmio handler (Zhenyu)
> > 
> > 
> > Weinan Li (4):
> >   drm/i915/gvt: refine trace_render_mmio
> >   drm/i915/gvt: optimize for vGPU mmio switch
> >   drm/i915/gvt: refine mocs save restore policy
> >   drm/i915/gvt: load host render mocs once in mocs switch
> > 
> > Xiaolin Zhang (1):
> >   drm/i915/gvt: Fix pipe A enable as default for vgpu
> > 
> > Zhenyu Wang (4):
> >   Merge tag 'drm-intel-next-2017-12-14' into gvt-next
> >   drm/i915/gvt: always use i915_reg_t for MMIO handler definition
> >   drm/i915/gvt: cleanup usage for typed mmio reg vs. offset
> >   drm/i915/gvt: move write protect handler out of mmio emulation 
> > function
> 
> dim apply-pull drm-intel-next-queued
> 
> https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
> From https://github.com/intel/gvt-linux
>  * tag gvt-next-2017-12-22 -> FETCH_HEAD
> dim: ERROR: 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7 is lacking mandatory 
> review, aborting
>

Looks dim doesn't allow committer == author without ack or r-b? Is this
really mandatory required? If yes, I will apply this rule for gvt tree as well
and encourage gvt developer to send a-b/r-b mail as looks people more like
to use IM to exchange review comment..

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] more gvt-next for 4.16

[Zhenyu Wang]

Hi,

Here's last gvt-next pull for 4.16 merge window. I need to backmerge
once for one i915 param change to resolve patch dependence. This includes
mmio switch optimization, cleanups for write protect handler and our
i915_reg_t vs. offset usage.

thanks
--
The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:

  drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22

for you to fetch changes up to 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7:

  drm/i915/gvt: move write protect handler out of mmio emulation function 
(2017-12-21 11:03:27 +0800)


gvt-next-2017-12-22:

- more mmio switch optimization (Weinan)
- cleanup i915_reg_t vs. offset usage (Zhenyu)
- move write protect handler out of mmio handler (Zhenyu)


Weinan Li (4):
  drm/i915/gvt: refine trace_render_mmio
  drm/i915/gvt: optimize for vGPU mmio switch
  drm/i915/gvt: refine mocs save restore policy
  drm/i915/gvt: load host render mocs once in mocs switch

Xiaolin Zhang (1):
  drm/i915/gvt: Fix pipe A enable as default for vgpu

Zhenyu Wang (4):
  Merge tag 'drm-intel-next-2017-12-14' into gvt-next
  drm/i915/gvt: always use i915_reg_t for MMIO handler definition
  drm/i915/gvt: cleanup usage for typed mmio reg vs. offset
  drm/i915/gvt: move write protect handler out of mmio emulation function

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  39 +-
 drivers/gpu/drm/i915/gvt/display.c  |  81 ++--
 drivers/gpu/drm/i915/gvt/edid.c |  22 +-
 drivers/gpu/drm/i915/gvt/fb_decoder.c   |  30 +-
 drivers/gpu/drm/i915/gvt/gtt.c  |  37 +-
 drivers/gpu/drm/i915/gvt/gtt.h  |   3 +
 drivers/gpu/drm/i915/gvt/gvt.c  |   1 +
 drivers/gpu/drm/i915/gvt/gvt.h  |  33 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 750 
 drivers/gpu/drm/i915/gvt/kvmgt.c|   4 +-
 drivers/gpu/drm/i915/gvt/mmio.c |  57 +--
 drivers/gpu/drm/i915/gvt/mmio.h |   7 -
 drivers/gpu/drm/i915/gvt/mmio_context.c | 238 +-
 drivers/gpu/drm/i915/gvt/trace.h|  15 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |  24 +-
 15 files changed, 675 insertions(+), 666 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-fixes for 4.15

[Zhenyu Wang]

Hi,

Please pull one fix for 4.15 that correct default pipe
enable for virtual display in a previous commit from Xiaolin.

thanks
--
The following changes since commit 11474e9091cf2002e948647fd9f63a7f027e488a:

  drm/i915/gvt: set max priority for gvt context (2017-12-06 11:38:21 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2017-12-21

for you to fetch changes up to f5f00e7dcc4161f07b76ff1a854e8b1ea7a1ed41:

  drm/i915/gvt: Fix pipe A enable as default for vgpu (2017-12-11 17:23:11 
+0800)


gvt-fixes-2017-12-21:

- default pipe enable fix for virtual display (Xiaolin)


Xiaolin Zhang (1):
  drm/i915/gvt: Fix pipe A enable as default for vgpu

 drivers/gpu/drm/i915/gvt/display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] more gvt-next for 4.16

[Zhenyu Wang]

Hi,

Please pull more gvt-next updates for 4.16. Mostly on code and
regression fixes for last two gvt-next pulls and more refinement.
Details below.

thanks
--
The following changes since commit 1603660b3342269c95fcafee1945790342a8c28e:

  drm/i915/gvt: set max priority for gvt context (2017-12-04 11:24:35 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-14

for you to fetch changes up to 461bd6227ede277138bf33c2156b6ebd1fba04c2:

  drm/i915/gvt/fb_decoder: Fix out-of-bounds read (2017-12-11 17:18:39 +0800)


gvt-next-2017-12-14:

- fixes for two coverity scan errors (Colin)
- mmio switch code refine (Changbin)
- more virtual display dmabuf fixes (Tina/Gustavo)
- misc cleanups (Pei)


Changbin Du (4):
  drm/i915/gvt: Refine the ring mmio list definition
  drm/i915/gvt: Select appropriate mmio list at initialization time
  drm/i915/gvt: Remove MMIO barrier in MMIO switch
  drm/i915/gvt: Rename file render.{c, h} to mmio_context.{c, h}

Colin Ian King (2):
  drm/i915/gvt: Add missing breaks in switch statement
  drm/i915/gvt: fix off-by-one comparison of ring_id

Gustavo A. R. Silva (1):
  drm/i915/gvt/fb_decoder: Fix out-of-bounds read

Pei Zhang (2):
  drm/i915/gvt/kvmgt: fill info for ROM/VGA region
  drm/i915/gvt: refine function emulate_mmio_read/write

Tina Zhang (1):
  drm/i915/gvt: Refine dmabuf_obj cleanup process

 drivers/gpu/drm/i915/gvt/Makefile  |   2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c  |  15 +-
 drivers/gpu/drm/i915/gvt/fb_decoder.c  |   6 +
 drivers/gpu/drm/i915/gvt/gvt.c |   2 +
 drivers/gpu/drm/i915/gvt/gvt.h |   4 +-
 drivers/gpu/drm/i915/gvt/handlers.c|   6 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c   |   6 +-
 drivers/gpu/drm/i915/gvt/mmio.c|  36 ++-
 .../gpu/drm/i915/gvt/{render.c => mmio_context.c}  | 262 ++---
 .../gpu/drm/i915/gvt/{render.h => mmio_context.h}  |   9 +
 10 files changed, 181 insertions(+), 167 deletions(-)
 rename drivers/gpu/drm/i915/gvt/{render.c => mmio_context.c} (53%)
 rename drivers/gpu/drm/i915/gvt/{render.h => mmio_context.h} (91%)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt/fb_decoder: Fix out-of-bounds read

[Zhenyu Wang]

On 2017.12.09 00:37:59 -0600, Gustavo A. R. Silva wrote:
> In case function skl_format_to_drm returns -EINVAL, fmt turns into a huge
> number as fmt is of type u32, hence there is an out-of-bounds read when
> using fmt as an index for array skl_pixel_formats at line 225:
> plane->bpp = skl_pixel_formats[fmt].bpp;
> 
> Fix this by comparing the value returned by function skl_format_to_drm
> against the size of array skl_pixel_formats, so in case it is greater than
> or equal to the number of items contained in skl_pixel_formats, print an
> error message and return -EINVAL.
> 
> Addresses-Coverity-ID: 1462495
> Addresses-Coverity-ID: 1462502 ("Out-of-bounds read")
> Fixes: 9f31d1063b43 ("drm/i915/gvt: Add framebuffer decoder support")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/gpu/drm/i915/gvt/fb_decoder.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c 
> b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> index 72f4217..aed578b 100644
> --- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
> +++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> @@ -222,6 +222,12 @@ int intel_vgpu_decode_primary_plane(struct intel_vgpu 
> *vgpu,
>   val & PLANE_CTL_ORDER_RGBX,
>   val & PLANE_CTL_ALPHA_MASK,
>   val & PLANE_CTL_YUV422_ORDER_MASK);
> +
> + if (fmt >= ARRAY_SIZE(skl_pixel_formats)) {
> + gvt_vgpu_err("Out-of-bounds pixel format index\n");
> + return -EINVAL;
> + }
> +
>   plane->bpp = skl_pixel_formats[fmt].bpp;
>   plane->drm_format = skl_pixel_formats[fmt].drm_format;
>   } else {
> -- 

Applied this, thanks!

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GIT PULL] gvt-fixes for 4.15-rc3

[Zhenyu Wang]

Hi,

Here's gvt-fixes for 4.15-rc3 with several fixes backported.

thanks
--
The following changes since commit b721b65af4eb46df6a1d9e34b14003225e403565:

  drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition (2017-11-28 17:24:30 
+0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2017-12-06

for you to fetch changes up to 11474e9091cf2002e948647fd9f63a7f027e488a:

  drm/i915/gvt: set max priority for gvt context (2017-12-06 11:38:21 +0800)


gvt-fixes-2017-12-06

- Fix invalid hw reg read value for vGPU (Xiong)
- Fix qemu warning on PCI ROM bar missing (Changbin)
- Workaround preemption regression (Zhenyu)


Changbin Du (1):
  drm/i915/gvt: Emulate PCI expansion ROM base address register

Xiong Zhang (1):
  drm/i915/gvt: Limit read hw reg to active vgpu

Zhenyu Wang (2):
  drm/i915/gvt: Don't mark vgpu context as inactive when preempted
  drm/i915/gvt: set max priority for gvt context

Zhi Wang (1):
  drm/i915/gvt: Export intel_gvt_render_mmio_to_ring_id()

 drivers/gpu/drm/i915/gvt/cfg_space.c | 21 
 drivers/gpu/drm/i915/gvt/handlers.c  | 47 
 drivers/gpu/drm/i915/gvt/mmio.h  |  2 ++
 drivers/gpu/drm/i915/gvt/scheduler.c | 22 -
 4 files changed, 81 insertions(+), 11 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fixes that failed to cleanly apply to v4.15-rc1

[Zhenyu Wang]

On 2017.12.05 17:02:34 +0200, Joonas Lahtinen wrote:
> Dropping GVT folks that are not affected.
> 
> Keeping Zhenyu and Zhi as a heads-up, there's no need for GVT pull for this 
> rc?
>

I need to backport one from -next once it's pulled and it's done now.
I will send a fixes pull today.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GIT PULL] more gvt-next for 4.16

[Zhenyu Wang]

Hi,

Here's more gvt-next updates for 4.16. Mostly for final VFIO mdev
display dmabuf interface and gvt implementation which have been
reviewed by VFIO maintainer and acked to push through gvt merge path.
User space qemu support was sent as
https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg02213.html,
and tracked at
https://www.kraxel.org/cgit/qemu/log/?h=work/intel-vgpu

Others include VFIO opregion support, scheduler optimization and
preemption fix, etc.

thanks
--
The following changes since commit f2880e04f3a5419366926182fc97a3c2e4fd8f2a:

  drm/i915/gvt: Move request alloc to dispatch_workload path only (2017-11-16 
11:51:55 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-05

for you to fetch changes up to 1603660b3342269c95fcafee1945790342a8c28e:

  drm/i915/gvt: set max priority for gvt context (2017-12-04 11:24:35 +0800)


gvt-next-2017-12-05

- VFIO mdev display dmabuf interface and gvt support (Tina)
- VFIO mdev opregion support/fixes (Tina/Xiong/Chris)
- workload scheduling optimization (Changbin)
- preemption fix and temporal workaround (Zhenyu)
- and misc fixes after refactor (Chris)


Changbin Du (2):
  drm/i915/gvt: Convert macro queue_workload to a function
  drm/i915/gvt: Kick scheduler when new workload queued

Chris Wilson (2):
  drm/i915/gvt: Cleanup unwanted public symbols
  drm/i915/gvt: Fix out-of-bounds buffer write into opregion->signature[]

Tina Zhang (7):
  drm/i915/gvt: Add opregion support
  drm/i915/gvt: Add framebuffer decoder support
  vfio: ABI for mdev display dma-buf operation
  drm/i915/gvt: Dmabuf support for GVT-g
  drm/i915/gvt: Handle orphan dmabuf_objs
  drm/i915/gvt: Introduce KBL to dma-buf on Gvt-g
  drm/i915/gvt: Free dmabuf_obj list in intel_vgpu_dmabuf_cleanup

Xiong Zhang (1):
  drm/i915/gvt: Alloc and Init guest opregion at vgpu creation

Zhenyu Wang (2):
  drm/i915/gvt: Don't mark vgpu context as inactive when preempted
  drm/i915/gvt: set max priority for gvt context

 drivers/gpu/drm/i915/gvt/Makefile   |   3 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c|   3 +-
 drivers/gpu/drm/i915/gvt/display.c  |   2 +-
 drivers/gpu/drm/i915/gvt/display.h  |   2 +
 drivers/gpu/drm/i915/gvt/dmabuf.c   | 538 
 drivers/gpu/drm/i915/gvt/dmabuf.h   |  67 
 drivers/gpu/drm/i915/gvt/execlist.c |   8 +-
 drivers/gpu/drm/i915/gvt/fb_decoder.c   | 508 ++
 drivers/gpu/drm/i915/gvt/fb_decoder.h   | 169 ++
 drivers/gpu/drm/i915/gvt/gvt.c  |   2 +
 drivers/gpu/drm/i915/gvt/gvt.h  |  17 +-
 drivers/gpu/drm/i915/gvt/hypercall.h|   3 +
 drivers/gpu/drm/i915/gvt/kvmgt.c| 161 +-
 drivers/gpu/drm/i915/gvt/mpt.h  |  45 +++
 drivers/gpu/drm/i915/gvt/opregion.c | 137 +---
 drivers/gpu/drm/i915/gvt/sched_policy.c |   5 +
 drivers/gpu/drm/i915/gvt/sched_policy.h |   2 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  21 +-
 drivers/gpu/drm/i915/gvt/scheduler.h|   7 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |  17 +-
 drivers/gpu/drm/i915/i915_gem_object.h  |   2 +
 include/uapi/linux/vfio.h   |  62 
 22 files changed, 1709 insertions(+), 72 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


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915/gvt: make release_shadow_wa_ctx static.

[Zhenyu Wang]

On 2017.12.04 15:15:28 +0200, Joonas Lahtinen wrote:
> + GVT-g list
> 
> Zhenyu, please pick this up.
> 

I've queued fixes from Chris for this and will just send for next pull.

thanks.

> 
> On Mon, 2017-12-04 at 09:42 +1000, Dave Airlie wrote:
> > From: Dave Airlie 
> > 
> > This was removed from the header file in
> > d0d51282b8 drm/i915/gvt: Remove one extra declaration in scheduler.h
> > 
> > Make it static then.
> > 
> > Signed-off-by: Dave Airlie 
> > ---
> >  drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > index d6177a0..41bccbc 100644
> > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > @@ -246,7 +246,7 @@ static int copy_workload_to_ring_buffer(struct 
> > intel_vgpu_workload *workload)
> > return 0;
> >  }
> >  
> > -void release_shadow_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
> > +static void release_shadow_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
> >  {
> > if (!wa_ctx->indirect_ctx.obj)
> > return;
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix out-of-bounds buffer write into opregion->signature[]

[Zhenyu Wang]

On 2017.11.21 10:19:21 +, Chris Wilson wrote:
> Quoting Zhenyu Wang (2017-11-21 03:19:51)
> > On 2017.11.20 21:15:16 +, Chris Wilson wrote:
> > > sparse spots
> > > 
> > > drivers/gpu/drm/i915/gvt/opregion.c:234 alloc_and_init_virt_opregion() 
> > > error: memcpy() 'header->signature' too small (16 vs 17)
> > > 
> > > as gvt is indeed trying to memcpy a string longer than the signature[].
> > > 
> > > Fixes: b2d6ef70614e ("drm/i915/gvt: Let each vgpu has separate opregion 
> > > memory")
> > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> > > Cc: Xiong Zhang <xiong.y.zh...@intel.com>
> > > Cc: Zhenyu Wang <zhen...@linux.intel.com>
> > > Cc: Zhi Wang <zhi.a.w...@intel.com>
> > > Cc: intel-gvt-...@lists.freedesktop.org
> > > ---
> > >  drivers/gpu/drm/i915/gvt/opregion.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/opregion.c 
> > > b/drivers/gpu/drm/i915/gvt/opregion.c
> > > index 80720e59723a..3cf4c6f18152 100644
> > > --- a/drivers/gpu/drm/i915/gvt/opregion.c
> > > +++ b/drivers/gpu/drm/i915/gvt/opregion.c
> > > @@ -232,7 +232,7 @@ static int alloc_and_init_virt_opregion(struct 
> > > intel_vgpu *vgpu)
> > >   buf = (u8 *)vgpu_opregion(vgpu)->va;
> > >   header = (struct opregion_header *)buf;
> > >   memcpy(header->signature, OPREGION_SIGNATURE,
> > > - sizeof(OPREGION_SIGNATURE));
> > > + sizeof(OPREGION_SIGNATURE) - 1);
> > >   header->size = 0x8;
> > >   header->opregion_ver = 0x0200;
> > >   header->mboxes = MBOX_VBT;
> > > -- 
> > 
> > applied this, thanks!
> 
> It's not the best patch; after sleep I think you want
> 
> static const char opregion_signature[16] = "IntelFooBar";
> 
> memcpy(header->signature, opregion_signature, sizeof(opregion_signature));

yeah, I applied below one instead. Thanks.

From ea26c96d59b27e878fe61e8ef0fed840d2281a2f Mon Sep 17 00:00:00 2001
From: Chris Wilson <ch...@chris-wilson.co.uk>
Date: Mon, 4 Dec 2017 11:23:44 +0800
Subject: [PATCH] drm/i915/gvt: Fix out-of-bounds buffer write into 
opregion->signature[]

sparse spots

drivers/gpu/drm/i915/gvt/opregion.c:234 alloc_and_init_virt_opregion() error: 
memcpy() 'header->signature' too small (16 vs 17)

as gvt is indeed trying to memcpy a string longer than the signature[].

Fixes: b2d6ef70614e ("drm/i915/gvt: Let each vgpu has separate opregion memory")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Xiong Zhang <xiong.y.zh...@intel.com>
Cc: Zhenyu Wang <zhen...@linux.intel.com>
Cc: Zhi Wang <zhi.a.w...@intel.com>
Cc: intel-gvt-...@lists.freedesktop.org
Signed-off-by: Zhenyu Wang <zhen...@linux.intel.com>
---
 drivers/gpu/drm/i915/gvt/opregion.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/opregion.c 
b/drivers/gpu/drm/i915/gvt/opregion.c
index 80720e59723a..bf8e5c49a64a 100644
--- a/drivers/gpu/drm/i915/gvt/opregion.c
+++ b/drivers/gpu/drm/i915/gvt/opregion.c
@@ -218,6 +218,7 @@ static int alloc_and_init_virt_opregion(struct intel_vgpu 
*vgpu)
u8 *buf;
struct opregion_header *header;
struct vbt v;
+   const char opregion_signature[16] = OPREGION_SIGNATURE;
 
gvt_dbg_core("init vgpu%d opregion\n", vgpu->id);
vgpu_opregion(vgpu)->va = (void *)__get_free_pages(GFP_KERNEL |
@@ -231,8 +232,8 @@ static int alloc_and_init_virt_opregion(struct intel_vgpu 
*vgpu)
/* emulated opregion with VBT mailbox only */
buf = (u8 *)vgpu_opregion(vgpu)->va;
header = (struct opregion_header *)buf;
-   memcpy(header->signature, OPREGION_SIGNATURE,
-   sizeof(OPREGION_SIGNATURE));
+   memcpy(header->signature, opregion_signature,
+  sizeof(opregion_signature));
header->size = 0x8;
header->opregion_ver = 0x0200;
header->mboxes = MBOX_VBT;
-- 
2.15.0


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: Signed-off-by missing for commits in the drm tree

[Zhenyu Wang]

On 2017.12.04 10:57:35 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> There is a series of commits
> 
>   54cff6479fd8 - c1802534e5a6
> (not all in that range)
> 
> that are missing a Signed-off-by from their committer.
> 

They were originally committed by Zhi himself, but I had to rebase
onto intel -next before they're sent for pull and missed my signed-off..
Really sorry for that! I think maybe we could still be able to fix that
before next kernel merge.

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GIT PULL] gvt fixes for 4.15-rc2

[Zhenyu Wang]

Hi,

Pls pull gvt fixes for 4.15-rc2, which contains one backport
from f2880e04f3a5 ("drm/i915/gvt: Move request alloc to dispatch_workload path 
only"),
and more new fixes.

thanks
--
The following changes since commit ac29fc66855b79c2960c63a4a66952d5b721d698:

  drm/i915: fix intel_backlight_device_register declaration (2017-11-28 
10:31:59 +0200)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2017-11-28

for you to fetch changes up to b721b65af4eb46df6a1d9e34b14003225e403565:

  drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition (2017-11-28 17:24:30 
+0800)


gvt-fixes-2017-11-28

- regression fix for sane request alloc (Fred)
- locking fix (Changbin)
- fix invalid addr mask (Xiong)
- compression regression fix (Weinan)
- fix default pipe enable for virtual display (Xiaolin)


Changbin Du (1):
  drm/i915/gvt: Fix unsafe locking caused by spin_unlock_bh

Weinan Li (1):
  drm/i915/gvt: remove skl_misc_ctl_write handler

Xiaolin Zhang (1):
  drm/i915/gvt: enabled pipe A default on creating vgpu

Xiong Zhang (1):
  drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition

fred gao (1):
  drm/i915/gvt: Move request alloc to dispatch_workload path only

 drivers/gpu/drm/i915/gvt/display.c   |  2 ++
 drivers/gpu/drm/i915/gvt/execlist.c  |  6 +
 drivers/gpu/drm/i915/gvt/gtt.c   |  6 ++---
 drivers/gpu/drm/i915/gvt/handlers.c  | 45 
 drivers/gpu/drm/i915/gvt/scheduler.c | 33 +++---
 drivers/gpu/drm/i915/gvt/scheduler.h |  3 +++
 6 files changed, 44 insertions(+), 51 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fixes that failed to cleanly apply to v4.15-rc1

[Zhenyu Wang]

On 2017.11.28 10:54:27 +0200, Joonas Lahtinen wrote:
> Hello,
> 
> TL;DR Reply with backported patches for v4.15-rc1 latest TODAY
> 
> Dear patch authors/Cc:s, the following patches failed to cleanly
> backport to v4.15-rc1, if you believe they still are valid patches to
> be included in drm-intel-fixes, please backport them and send them as a
> REPLY TO THIS EMAIL before the END OF TODAY.
> 
> The patches that failed to cherry-pick:
> 8cf80a2e4b31 ("drm/i915/gvt: Rename reserved ring buffer")

ignore this one.

> f2880e04f3a5 ("drm/i915/gvt: Move request alloc to dispatch_workload path 
> only")

Done in last gvt-fixes pull request, but seems that missed 4.15-rc1,
so will send new pull to include this.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GIT PULL] git fixes for 4.15

[Zhenyu Wang]

Hi,

Here's current gvt fixes for 4.15. One is backport from
f2880e04f3a5 ("drm/i915/gvt: Move request alloc to dispatch_workload path 
only").
And other two regression fixes.

thanks
--
The following changes since commit 3572f04c69ed4369da5d3c65d84fb18774aa60b6:

  drm/i915: Fix init_clock_gating for resume (2017-11-21 11:40:12 +0200)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2017-11-24

for you to fetch changes up to e0d1ffe5a86326fb769cce03e726d2f1fca0725c:

  drm/i915/gvt: Move request alloc to dispatch_workload path only (2017-11-22 
14:52:07 +0800)


gvt-next-fixes-2017-11-24

- regression fixes for safe lock, compression workaround
  and sane request allocation order.


Changbin Du (1):
  drm/i915/gvt: Fix unsafe locking caused by spin_unlock_bh

Weinan Li (1):
  drm/i915/gvt: remove skl_misc_ctl_write handler

fred gao (1):
  drm/i915/gvt: Move request alloc to dispatch_workload path only

 drivers/gpu/drm/i915/gvt/execlist.c  |  6 +
 drivers/gpu/drm/i915/gvt/handlers.c  | 45 
 drivers/gpu/drm/i915/gvt/scheduler.c | 33 +++---
 drivers/gpu/drm/i915/gvt/scheduler.h |  3 +++
 4 files changed, 39 insertions(+), 48 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v18 0/6] drm/i915/gvt: Dma-buf support for GVT-g

[Zhenyu Wang]

On 2017.11.15 11:49:00 +0100, Gerd Hoffmann wrote:
> On Wed, Nov 15, 2017 at 05:11:49PM +0800, Tina Zhang wrote:
> > v17->v18:
> > 1) unmap vgpu's opregion when destroying vgpu.
> > 2) update comments for VFIO_DEVICE_GET_GFX_DMABUF. (Alex)
> 
> > This patch set adds the dma-buf support for intel GVT-g.
> > 
> > dma-buf is an uniform mechanism to share DMA buffers across different
> > devices and subsystems. dma-buf for intel GVT-g is mainly used to share
> > the vgpu's framebuffer to userspace to leverage userspace graphics stacks
> > to render the framebuffer to the display monitor.
> > 
> > The main idea is that we create a gem object and set vgpu's framebuffer as
> > its backing storage. Then, export a dma-buf associated with this gem object.
> > With the fd of this dma-buf, userspace can directly handle this buffer.
> > 
> > This patch set can be tried with the following example:
> > git://git.kraxel.org/qemu  branch: work/intel-vgpu
> > 
> > A topic branch with the latest patch set is:
> > https://github.com/intel/gvt-linux.git   branch: topic/dmabuf
> 
> Tested-by: Gerd Hoffmann 
> 

After debugging with Tina on one left race that fixed by
https://lists.freedesktop.org/archives/intel-gvt-dev/2017-November/002505.html

I still need below qemu fix for proper cursor handling, otherwise qemu
just crashed when I click in my terminal program which hides cursor then.

diff --git a/hw/vfio/display.c b/hw/vfio/display.c
index e500ec2cb1..d9a044b080 100644
--- a/hw/vfio/display.c
+++ b/hw/vfio/display.c
@@ -169,8 +169,9 @@ static void vfio_display_dmabuf_update(void *opaque)
 cursor = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_CURSOR);
 if (vdev->cursor != cursor) {
 vdev->cursor = cursor;
-dpy_gl_cursor_dmabuf(vdev->display_con,
- >buf);
+if (cursor)
+dpy_gl_cursor_dmabuf(vdev->display_con,
+ >buf);
 free_bufs = true;
 }
 if (cursor != NULL) {

And with these it seems pretty fine now that I'll queue them up for -next pull.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx