Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

2016-02-25 Thread Zhi Wang 

Hi Joonas:

Thanks for you time and comments. :) See my replies below.

On 02/23/16 20:42, Joonas Lahtinen wrote:

Hi,

Code is looking a lot better.

A general question still; why you seem to be preferring multi-stage
alloc and destroy?

Are there going to be scenarios when things will be allocated but not
initialized? I don't see a such use scenario.

I wouldn't split the init functions down as much as you currently do
because that'll require a lot of boilerplate code to propagate the
errors up, which is currently not done. The boilerplate for propagation
becomes necessary when the teardown function is complex, but currently
the teardown itself is less lines of code than the function
boilerplate.

So just squash those into gvt_device_create() and gvt_device_destroy()
where _create() will propagate any lower level errors up and tear down
a partially initialized struct. _destroy() can then expect to just tear
the whole struct down with no ifs.


OK. Sure no problem.

Regards, Joonas

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:

This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.

v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled, the
stubs here do nothing.

Take Joonas's comments:
- Replace boolean return value with int.
- Replace customized info/warn/debug macros with DRM macros.
- Document all non-static functions like i915.
- Remove empty and unused functions.
- Replace magic number with marcos.
- Set GVT-g in kernel config to "n" by default.

Signed-off-by: Zhi Wang 
---
  drivers/gpu/drm/i915/Kconfig |  15 ++
  drivers/gpu/drm/i915/Makefile|   2 +
  drivers/gpu/drm/i915/gvt/Makefile|   5 +
  drivers/gpu/drm/i915/gvt/debug.h |  57 +
  drivers/gpu/drm/i915/gvt/gvt.c   | 393 +++
  drivers/gpu/drm/i915/gvt/gvt.h   | 100 +
  drivers/gpu/drm/i915/gvt/hypercall.h |  30 +++
  drivers/gpu/drm/i915/gvt/mpt.h   |  34 +++
  drivers/gpu/drm/i915/gvt/params.c|  32 +++
  drivers/gpu/drm/i915/gvt/params.h|  34 +++
  drivers/gpu/drm/i915/gvt/reg.h   |  34 +++
  drivers/gpu/drm/i915/i915_dma.c  |  14 ++
  drivers/gpu/drm/i915/i915_drv.h  |  12 ++
  drivers/gpu/drm/i915/i915_gvt.c  |  93 +
  drivers/gpu/drm/i915/i915_gvt.h  |  49 +
  15 files changed, 904 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
  create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
  create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
  create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
  create mode 100644 drivers/gpu/drm/i915/gvt/params.c
  create mode 100644 drivers/gpu/drm/i915/gvt/params.h
  create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
  create mode 100644 drivers/gpu/drm/i915/i915_gvt.c
  create mode 100644 drivers/gpu/drm/i915/i915_gvt.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4c59793..082e77d 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,3 +45,18 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
  option changes the default for that module option.

  If in doubt, say "N".
+
+config DRM_I915_GVT
+tristate "GVT-g host driver"
+depends on DRM_I915
+default n
+help
+  Enabling GVT-g mediated graphics passthrough technique for Intel i915
+  based integrated graphics card. With GVT-g, it's possible to have one
+  integrated i915 device shared by multiple VMs. Performance critical
+  opterations such as apperture accesses and ring buffer operations
+  are pass-throughed to VM, with a minimal set of conflicting resources
+  (e.g. display settings) mediated by vGT driver. The benefit of vGT
+  is on both the performance, given that each VM could directly operate
+  its aperture space and submit commands like running on native, and
+  the feature completeness, given that a true GEN hardware is exposed.
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..c65026c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -91,6 +91,8 @@ i915-y += dvo_ch7017.o \
  intel_sdvo.o \
  intel_tv.o

+obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o gvt/
+
  # virtual gpu code
  i915-y += i915_vgpu.o

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
new file mode 100644
index 000..959305f
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -0,0 +1,5 @@
+GVT_SOURCE := gvt.o params.o
+
+ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
-Wno-unused-function
+i915_gvt-y

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

2016-02-25 Thread Zhi Wang 



On 02/24/16 16:08, Tian, Kevin wrote:

From: Wang, Zhi A
Sent: Thursday, February 18, 2016 7:42 PM
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
new file mode 100644
index 000..52cfa32
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/gvt.c

[...]

+
+#include 
+#include 


would this inclusion lead to a dependency on Xen?


+#include 
+
+#include "gvt.h"
+
+struct gvt_host gvt_host;
+
+static const char * const supported_hypervisors[] = {
+   [GVT_HYPERVISOR_TYPE_XEN] = "Xen Hypervisor",
+   [GVT_HYPERVISOR_TYPE_KVM] = "KVM",
+};
+
+static int gvt_init_host(void)
+{
+   struct gvt_host *host = _host;
+
+   if (!gvt.enable) {
+   gvt_dbg_core("GVT-g has been disabled by kernel parameter");
+   return -EINVAL;
+   }
+
+   if (host->initialized) {
+   gvt_err("GVT-g has already been initialized!");
+   return -EINVAL;
+   }
+
+   /* Xen DOM U */
+   if (xen_domain() && !xen_initial_domain())
+   return -ENODEV;
+
+   if (xen_initial_domain()) {
+   /* Xen Dom0 */
+   host->kdm = try_then_request_module(
+   symbol_get(xengt_kdm), "xengt");
+   host->hypervisor_type = GVT_HYPERVISOR_TYPE_XEN;
+   } else {
+   /* not in Xen. Try KVMGT */
+   host->kdm = try_then_request_module(
+   symbol_get(kvmgt_kdm), "kvm");
+   host->hypervisor_type = GVT_HYPERVISOR_TYPE_KVM;
+   }


It'd be clearer to add a comment here that above is only a short-term
solution. It's supposed to have a general registration framework in
the future so any hypervisor (Xen or KVM) can register their callbacks
at run-time, then we'll not need such direct Xen/KVM references or
hard assumption in driver code. That framework is now still under
discussion with Xen/KVM community. It doesn't prevent reviewing of
other bits, but better to document it clear here.

I'm keeping thinking if we should split this patch into much smaller 
patches and just push some basic definitions and functions for GVT 
context patch review here before MPT framework is finally figured out 
with RH guys?



+static int init_device_info(struct pgt_device *pdev)
+{
+   struct gvt_device_info *info = >device_info;
+
+   if (!IS_BROADWELL(pdev->dev_priv)) {
+   DRM_DEBUG_DRIVER("Unsupported GEN device");
+   return -ENODEV;
+   }
+
+   if (IS_BROADWELL(pdev->dev_priv)) {
+   info->max_gtt_gm_sz = (1ULL << 32); /* 4GB */
+   /*
+* The layout of BAR0 in BDW:
+* |< - MMIO 2MB ->|<- Reserved 6MB ->|<- MAX GTT 8MB->|
+*
+* GTT offset in BAR0 starts from 8MB to 16MB, and
+* Whatever GTT size is configured in BIOS,
+* the size of BAR0 is always 16MB. The actual configured
+* GTT size can be found in GMCH_CTRL.
+*/
+   info->gtt_start_offset = (1UL << 23); /* 8MB */
+   info->max_gtt_size = (1UL << 23); /* 8MB */
+   info->gtt_entry_size = 8;
+   info->gtt_entry_size_shift = 3;
+   info->gmadr_bytes_in_cmd = 8;
+   info->mmio_size = 2 * 1024 * 1024; /* 2MB */


Above are pure device info. Joonas, do you think whether it makes
sense to make them to drm_i915_private, though gvt is the only
user today?


+   }
+
+   return 0;
+}
+
+static void init_initial_cfg_space_state(struct pgt_device *pdev)


'init' -> 'setup'


+{
+   struct pci_dev *pci_dev = pdev->dev_priv->dev->pdev;
+   int i;
+
+   gvt_dbg_core("init initial cfg space, id %d", pdev->id);
+
+   for (i = 0; i < GVT_CFG_SPACE_SZ; i += 4)
+   pci_read_config_dword(pci_dev, i,
+   (u32 *)>initial_cfg_space[i]);
+
+   for (i = 0; i < GVT_BAR_NUM; i++) {
+   pdev->bar_size[i] = pci_resource_len(pci_dev, i * 2);
+   gvt_dbg_core("bar %d size: %llx", i, pdev->bar_size[i]);
+   }
+}
+
+static void clean_initial_mmio_state(struct pgt_device *pdev)
+{
+   if (pdev->gttmmio_va) {
+   iounmap(pdev->gttmmio_va);
+   pdev->gttmmio_va = NULL;
+   }
+
+   if (pdev->gmadr_va) {
+   iounmap(pdev->gmadr_va);
+   pdev->gmadr_va = NULL;
+   }


Can we reuse existing mapping in i915?

Yes, but we have to flush the tlb stuffs like i915, as i915 maps GTT 
MMIOs as WC...



+}
+
+static int init_initial_mmio_state(struct pgt_device *pdev)
+{


'init' -> 'setup'


+   struct gvt_device_info *info = >device_info;
+
+   u64 bar0, bar1;
+   int rc;
+
+   gvt_dbg_core("init initial mmio state, id %d", pdev->id);
+
+   bar0 = *(u64 *)>initial_cfg_space[GVT_REG_CFG_SPACE_BAR0];
+   bar1 = *(u64 *)>initial_cfg_space[GVT_REG_CFG_SPACE_BAR1];
+
+

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

2016-02-24 Thread Tian, Kevin 
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, February 23, 2016 8:42 PM
> 
> Hi,
> 
> Code is looking a lot better.
> 
> A general question still; why you seem to be preferring multi-stage
> alloc and destroy?

One reason for multi-stage, IMO, is that GVT needs to do a snapshot
of initial MMIO state before i915 driver does actual initialization. That
snapshot will be presented to each VM which can then observe same
state as it would observe on a bare metal. Then the majority of
initialization needs to wait after i915 driver completes initialization. 
Zhi can correct me here.

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

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

2016-02-24 Thread Tian, Kevin 
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, February 23, 2016 8:54 PM
> > diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> > b/drivers/gpu/drm/i915/gvt/Makefile
> > new file mode 100644
> > index 000..959305f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/gvt/Makefile
> > @@ -0,0 +1,5 @@
> > +GVT_SOURCE := gvt.o params.o
> > +
> > +ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
> > -Wno-unused-function
> > +i915_gvt-y := $(GVT_SOURCE)
> 
> (This name conflicts with upper level i915_gvt, which I suggested
> renaming to intel_gvt.c. A one more reason more so this can be kept as
> is).
> 

Curious what's the criteria whether a file should be called i915_xxx or 
intel_xxx?

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

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

2016-02-23 Thread Joonas Lahtinen 
A one more note below.

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:
> This patch introduces the very basic framework of GVT-g device model,
> includes basic prototypes, definitions, initialization.
> 
> v2:
> - Introduce i915_gvt.c.
> It's necessary to introduce the stubs between i915 driver and GVT-g host,
> as GVT-g components is configurable in kernel config. When disabled, the
> stubs here do nothing.
> 
> Take Joonas's comments:
> - Replace boolean return value with int.
> - Replace customized info/warn/debug macros with DRM macros.
> - Document all non-static functions like i915.
> - Remove empty and unused functions.
> - Replace magic number with marcos.
> - Set GVT-g in kernel config to "n" by default.
> 
> Signed-off-by: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/Kconfig |  15 ++
>  drivers/gpu/drm/i915/Makefile|   2 +
>  drivers/gpu/drm/i915/gvt/Makefile|   5 +
>  drivers/gpu/drm/i915/gvt/debug.h |  57 +
>  drivers/gpu/drm/i915/gvt/gvt.c   | 393 
> +++
>  drivers/gpu/drm/i915/gvt/gvt.h   | 100 +
>  drivers/gpu/drm/i915/gvt/hypercall.h |  30 +++
>  drivers/gpu/drm/i915/gvt/mpt.h   |  34 +++
>  drivers/gpu/drm/i915/gvt/params.c|  32 +++
>  drivers/gpu/drm/i915/gvt/params.h|  34 +++
>  drivers/gpu/drm/i915/gvt/reg.h   |  34 +++
>  drivers/gpu/drm/i915/i915_dma.c  |  14 ++
>  drivers/gpu/drm/i915/i915_drv.h  |  12 ++
>  drivers/gpu/drm/i915/i915_gvt.c  |  93 +
>  drivers/gpu/drm/i915/i915_gvt.h  |  49 +
>  15 files changed, 904 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
>  create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.c
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4c59793..082e77d 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -45,3 +45,18 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
>     option changes the default for that module option.
>  
>     If in doubt, say "N".
> +
> +config DRM_I915_GVT
> +tristate "GVT-g host driver"
> +depends on DRM_I915
> +default n
> +help
> +  Enabling GVT-g mediated graphics passthrough technique for Intel 
> i915
> +  based integrated graphics card. With GVT-g, it's possible to have 
> one
> +  integrated i915 device shared by multiple VMs. Performance critical
> +  opterations such as apperture accesses and ring buffer operations
> +  are pass-throughed to VM, with a minimal set of conflicting 
> resources
> +  (e.g. display settings) mediated by vGT driver. The benefit of vGT
> +  is on both the performance, given that each VM could directly 
> operate
> +  its aperture space and submit commands like running on native, and
> +  the feature completeness, given that a true GEN hardware is 
> exposed.
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0851de07..c65026c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -91,6 +91,8 @@ i915-y += dvo_ch7017.o \
>     intel_sdvo.o \
>     intel_tv.o
>  
> +obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o gvt/
> +
>  # virtual gpu code
>  i915-y += i915_vgpu.o
>  
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> new file mode 100644
> index 000..959305f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -0,0 +1,5 @@
> +GVT_SOURCE := gvt.o params.o
> +
> +ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
> -Wno-unused-function
> +i915_gvt-y := $(GVT_SOURCE)

(This name conflicts with upper level i915_gvt, which I suggested
renaming to intel_gvt.c. A one more reason more so this can be kept as
is).

As the module will be called i915_gvt, I bet the debug prefix should be
changed to reflect that.

So it should look like;

${WHATEVER_DRM_PRINTS} i915-gvt: core: Core debug
${WHATEVER_DRM_PRINTS} i915-gvt: mm: Memory debug

Regards, Joonas

> +obj-$(CONFIG_DRM_I915_GVT) += i915_gvt.o
> diff --git a/drivers/gpu/drm/i915/gvt/debug.h 
> b/drivers/gpu/drm/i915/gvt/debug.h
> new file mode 100644
> index 000..0747f28
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/debug.h
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

2016-02-23 Thread Joonas Lahtinen 
Hi,

Code is looking a lot better.

A general question still; why you seem to be preferring multi-stage
alloc and destroy?

Are there going to be scenarios when things will be allocated but not
initialized? I don't see a such use scenario.

I wouldn't split the init functions down as much as you currently do
because that'll require a lot of boilerplate code to propagate the
errors up, which is currently not done. The boilerplate for propagation
becomes necessary when the teardown function is complex, but currently
the teardown itself is less lines of code than the function
boilerplate.

So just squash those into gvt_device_create() and gvt_device_destroy()
where _create() will propagate any lower level errors up and tear down
a partially initialized struct. _destroy() can then expect to just tear
the whole struct down with no ifs.

Regards, Joonas

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:
> This patch introduces the very basic framework of GVT-g device model,
> includes basic prototypes, definitions, initialization.
> 
> v2:
> - Introduce i915_gvt.c.
> It's necessary to introduce the stubs between i915 driver and GVT-g host,
> as GVT-g components is configurable in kernel config. When disabled, the
> stubs here do nothing.
> 
> Take Joonas's comments:
> - Replace boolean return value with int.
> - Replace customized info/warn/debug macros with DRM macros.
> - Document all non-static functions like i915.
> - Remove empty and unused functions.
> - Replace magic number with marcos.
> - Set GVT-g in kernel config to "n" by default.
> 
> Signed-off-by: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/Kconfig |  15 ++
>  drivers/gpu/drm/i915/Makefile|   2 +
>  drivers/gpu/drm/i915/gvt/Makefile|   5 +
>  drivers/gpu/drm/i915/gvt/debug.h |  57 +
>  drivers/gpu/drm/i915/gvt/gvt.c   | 393 
> +++
>  drivers/gpu/drm/i915/gvt/gvt.h   | 100 +
>  drivers/gpu/drm/i915/gvt/hypercall.h |  30 +++
>  drivers/gpu/drm/i915/gvt/mpt.h   |  34 +++
>  drivers/gpu/drm/i915/gvt/params.c|  32 +++
>  drivers/gpu/drm/i915/gvt/params.h|  34 +++
>  drivers/gpu/drm/i915/gvt/reg.h   |  34 +++
>  drivers/gpu/drm/i915/i915_dma.c  |  14 ++
>  drivers/gpu/drm/i915/i915_drv.h  |  12 ++
>  drivers/gpu/drm/i915/i915_gvt.c  |  93 +
>  drivers/gpu/drm/i915/i915_gvt.h  |  49 +
>  15 files changed, 904 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
>  create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.c
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4c59793..082e77d 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -45,3 +45,18 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
>     option changes the default for that module option.
>  
>     If in doubt, say "N".
> +
> +config DRM_I915_GVT
> +tristate "GVT-g host driver"
> +depends on DRM_I915
> +default n
> +help
> +  Enabling GVT-g mediated graphics passthrough technique for Intel 
> i915
> +  based integrated graphics card. With GVT-g, it's possible to have 
> one
> +  integrated i915 device shared by multiple VMs. Performance critical
> +  opterations such as apperture accesses and ring buffer operations
> +  are pass-throughed to VM, with a minimal set of conflicting 
> resources
> +  (e.g. display settings) mediated by vGT driver. The benefit of vGT
> +  is on both the performance, given that each VM could directly 
> operate
> +  its aperture space and submit commands like running on native, and
> +  the feature completeness, given that a true GEN hardware is 
> exposed.
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0851de07..c65026c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -91,6 +91,8 @@ i915-y += dvo_ch7017.o \
>     intel_sdvo.o \
>     intel_tv.o
>  
> +obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o gvt/
> +
>  # virtual gpu code
>  i915-y += i915_vgpu.o
>  
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> new file mode 100644
> index 000..959305f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -0,0 +1,5 @@
> +GVT_SOURCE := gvt.o params.o
> +
> +ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
>

[Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

2016-02-18 Thread Zhi Wang 
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.

v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled, the
stubs here do nothing.

Take Joonas's comments:
- Replace boolean return value with int.
- Replace customized info/warn/debug macros with DRM macros.
- Document all non-static functions like i915.
- Remove empty and unused functions.
- Replace magic number with marcos.
- Set GVT-g in kernel config to "n" by default.

Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/Kconfig |  15 ++
 drivers/gpu/drm/i915/Makefile|   2 +
 drivers/gpu/drm/i915/gvt/Makefile|   5 +
 drivers/gpu/drm/i915/gvt/debug.h |  57 +
 drivers/gpu/drm/i915/gvt/gvt.c   | 393 +++
 drivers/gpu/drm/i915/gvt/gvt.h   | 100 +
 drivers/gpu/drm/i915/gvt/hypercall.h |  30 +++
 drivers/gpu/drm/i915/gvt/mpt.h   |  34 +++
 drivers/gpu/drm/i915/gvt/params.c|  32 +++
 drivers/gpu/drm/i915/gvt/params.h|  34 +++
 drivers/gpu/drm/i915/gvt/reg.h   |  34 +++
 drivers/gpu/drm/i915/i915_dma.c  |  14 ++
 drivers/gpu/drm/i915/i915_drv.h  |  12 ++
 drivers/gpu/drm/i915/i915_gvt.c  |  93 +
 drivers/gpu/drm/i915/i915_gvt.h  |  49 +
 15 files changed, 904 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
 create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
 create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
 create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
 create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
 create mode 100644 drivers/gpu/drm/i915/gvt/params.c
 create mode 100644 drivers/gpu/drm/i915/gvt/params.h
 create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
 create mode 100644 drivers/gpu/drm/i915/i915_gvt.c
 create mode 100644 drivers/gpu/drm/i915/i915_gvt.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4c59793..082e77d 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,3 +45,18 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
  option changes the default for that module option.
 
  If in doubt, say "N".
+
+config DRM_I915_GVT
+tristate "GVT-g host driver"
+depends on DRM_I915
+default n
+help
+  Enabling GVT-g mediated graphics passthrough technique for Intel i915
+  based integrated graphics card. With GVT-g, it's possible to have one
+  integrated i915 device shared by multiple VMs. Performance critical
+  opterations such as apperture accesses and ring buffer operations
+  are pass-throughed to VM, with a minimal set of conflicting resources
+  (e.g. display settings) mediated by vGT driver. The benefit of vGT
+  is on both the performance, given that each VM could directly operate
+  its aperture space and submit commands like running on native, and
+  the feature completeness, given that a true GEN hardware is exposed.
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..c65026c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -91,6 +91,8 @@ i915-y += dvo_ch7017.o \
  intel_sdvo.o \
  intel_tv.o
 
+obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o gvt/
+
 # virtual gpu code
 i915-y += i915_vgpu.o
 
diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
new file mode 100644
index 000..959305f
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -0,0 +1,5 @@
+GVT_SOURCE := gvt.o params.o
+
+ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
-Wno-unused-function
+i915_gvt-y := $(GVT_SOURCE)
+obj-$(CONFIG_DRM_I915_GVT) += i915_gvt.o
diff --git a/drivers/gpu/drm/i915/gvt/debug.h b/drivers/gpu/drm/i915/gvt/debug.h
new file mode 100644
index 000..0747f28
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/debug.h
@@ -0,0 +1,57 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED,