[Intel-gfx] [GIT PULL] GVT-g fixes for 4.11-rc2

[Zhenyu Wang]

On 2017.02.24 12:13:12 +0200, Jani Nikula wrote:
> On Fri, 24 Feb 2017, Zhenyu Wang  wrote:
> > Hi,
> >
> > This pull includes latest GVT-g fixes for 4.11 to resolve stablity
> > and usability issues found during co-debugging with distribution
> > developers which improves a lot.
> 
> I'll pull this in when we have v4.11-rc1.
> 

Hi, this is current gvt fixes for 4.11 based upon last gvt pull,
please help to merge them in order. Thanks!

---
The following changes since commit d1a513be1f0a25f094e1577d059b9aebaa279bb2:

  drm/i915/gvt: add resolution definition for vGPU type (2017-02-24 13:25:18 
+0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-03-08

for you to fetch changes up to 627c845c0907894a1e5cd2d90ff4fc86c9e4458e:

  drm/i915/gvt: change some gvt_err to gvt_dbg_cmd (2017-03-08 10:33:36 +0800)


gvt-fixes-2017-03-08

- MMIO cmd access flag cleanup
- Virtual display fixes from Weinan and Bing
- config space reset fix from Changbin
- better workload submission error path fix from Chuanxiao
- other misc fixes


Bing Niu (1):
  drm/i915/gvt: set SFUSE_STRAP properly for vitual monitor detection

Changbin Du (1):
  drm/i915/gvt: protect RO and Rsvd bits of virtual vgpu configuration space

Chuanxiao Dong (2):
  drm/i915/gvt: use pfn_valid for better checking
  drm/i915/gvt: handle workload lifecycle properly

Pei Zhang (1):
  drm/i915/gvt: add some new MMIOs to cmd_access white list

Tina Zhang (1):
  drm/i915/gvt: change some gvt_err to gvt_dbg_cmd

Weinan Li (1):
  drm/i915/gvt: fix pcode mailbox write emulation of BDW

Zhao Yan (4):
  drm/i915/gvt: have more registers with F_CMD_ACCESS flags set
  drm/i915/gvt: add more registers into handlers list
  drm/i915/gvt: fix an error for one register
  drm/i915/gvt: fix an error for F_RO flag

 drivers/gpu/drm/i915/gvt/cfg_space.c  |  54 ++-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |  10 +-
 drivers/gpu/drm/i915/gvt/display.c|  14 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 290 --
 drivers/gpu/drm/i915/gvt/kvmgt.c  |   4 +-
 drivers/gpu/drm/i915/gvt/scheduler.c  |  49 --
 6 files changed, 272 insertions(+), 149 deletions(-)


> 
> 
> > ---
> > The following changes since commit 4a0b3444da3ce1090d0f894f4e343756a94ab8c3:
> >
> >   drm/i915/gvt: return error code if dma map iova failed (2017-02-14 
> > 17:35:39 +0800)
> >
> > are available in the git repository at:
> >
> >   https://github.com/01org/gvt-linux.git tags/gvt-next-2017-02-24
> >
> > for you to fetch changes up to d1a513be1f0a25f094e1577d059b9aebaa279bb2:
> >
> >   drm/i915/gvt: add resolution definition for vGPU type (2017-02-24 
> > 13:25:18 +0800)
> >
> > 
> > gvt-next-2017-02-24
> >
> > - Min's vGPU failsafe to guard against non-secured guest
> > - Some guest warning fix and host error message cleanup
> > - Fixed vGPU type refinement for usability issue
> > - environ string fix from Takashi Iwai
> > - one kernel oops fix from Chuanxiao
> > - other misc fixes
> >
> > 
> > Chuanxiao Dong (1):
> >   drm/i915/gvt: add a NULL pointer check to avoid kernel panic
> >
> > Min He (2):
> >   drm/i915/gvt: introduced failsafe mode into vgpu
> >   drm/i915/gvt: enter failsafe mode when guest requires more resources
> >
> > Pei Zhang (1):
> >   drm/i915/gvt: add cmd_access to GEN7_HALF_SLICE_CHICKEN1
> >
> > Ping Gao (1):
> >   drm/i915/gvt: clear the vGPU reset logic
> >
> > Takashi Iwai (1):
> >   drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var
> >
> > Weinan Li (1):
> >   drm/i915/gvt: refine pcode write emulation
> >
> > Zhao Yan (4):
> >   drm/i915/gvt: fix unhandled mmio warnings
> >   drm/i915/gvt: add more registers to context save/restore list
> >   drm/i915/gvt: force-nopriv register handling
> >   drm/i915/gvt: set default value to 0 for unhandled mmio regs
> >
> > Zhao, Xinda (3):
> >   drm/i915/gvt: handle fence reg access during GPU reset
> >   drm/i915/gvt: decrease priority of output msg for untracked mmio
> >   drm/i915/gvt: remove unnecessary error msg from gtt write
> >
> > Zhenyu Wang (4):
> >   drm/i915/gvt: Fix check error on opregion.c
> >   drm/i915/gvt: adjust to fixed vGPU types
> >  

[Intel-gfx] [GIT PULL] more GVT-g fixes for 4.11

[Zhenyu Wang]

Hi,

This pull includes latest GVT-g fixes for 4.11 to resolve stablity
and usability issues found during co-debugging with distribution
developers which improves a lot.

Thanks.
---
The following changes since commit 4a0b3444da3ce1090d0f894f4e343756a94ab8c3:

  drm/i915/gvt: return error code if dma map iova failed (2017-02-14 17:35:39 
+0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-2017-02-24

for you to fetch changes up to d1a513be1f0a25f094e1577d059b9aebaa279bb2:

  drm/i915/gvt: add resolution definition for vGPU type (2017-02-24 13:25:18 
+0800)


gvt-next-2017-02-24

- Min's vGPU failsafe to guard against non-secured guest
- Some guest warning fix and host error message cleanup
- Fixed vGPU type refinement for usability issue
- environ string fix from Takashi Iwai
- one kernel oops fix from Chuanxiao
- other misc fixes


Chuanxiao Dong (1):
  drm/i915/gvt: add a NULL pointer check to avoid kernel panic

Min He (2):
  drm/i915/gvt: introduced failsafe mode into vgpu
  drm/i915/gvt: enter failsafe mode when guest requires more resources

Pei Zhang (1):
  drm/i915/gvt: add cmd_access to GEN7_HALF_SLICE_CHICKEN1

Ping Gao (1):
  drm/i915/gvt: clear the vGPU reset logic

Takashi Iwai (1):
  drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var

Weinan Li (1):
  drm/i915/gvt: refine pcode write emulation

Zhao Yan (4):
  drm/i915/gvt: fix unhandled mmio warnings
  drm/i915/gvt: add more registers to context save/restore list
  drm/i915/gvt: force-nopriv register handling
  drm/i915/gvt: set default value to 0 for unhandled mmio regs

Zhao, Xinda (3):
  drm/i915/gvt: handle fence reg access during GPU reset
  drm/i915/gvt: decrease priority of output msg for untracked mmio
  drm/i915/gvt: remove unnecessary error msg from gtt write

Zhenyu Wang (4):
  drm/i915/gvt: Fix check error on opregion.c
  drm/i915/gvt: adjust to fixed vGPU types
  drm/i915/gvt: Add more edid definition support
  drm/i915/gvt: add resolution definition for vGPU type

 drivers/gpu/drm/i915/gvt/cfg_space.c |   3 +
 drivers/gpu/drm/i915/gvt/display.c   | 125 ++--
 drivers/gpu/drm/i915/gvt/display.h   |  20 -
 drivers/gpu/drm/i915/gvt/firmware.c  |   2 +-
 drivers/gpu/drm/i915/gvt/gtt.c   |  40 +
 drivers/gpu/drm/i915/gvt/gvt.h   |  12 ++-
 drivers/gpu/drm/i915/gvt/handlers.c  | 157 +++
 drivers/gpu/drm/i915/gvt/kvmgt.c |   8 +-
 drivers/gpu/drm/i915/gvt/mmio.c  |  66 ++-
 drivers/gpu/drm/i915/gvt/opregion.c  |   5 +-
 drivers/gpu/drm/i915/gvt/render.c|  16 
 drivers/gpu/drm/i915/gvt/scheduler.c |   3 +
 drivers/gpu/drm/i915/gvt/vgpu.c  |  72 ++--
 13 files changed, 418 insertions(+), 111 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 superfluous newline in GVT_DISPLAY_READY env var

[Zhenyu Wang]

On 2017.02.20 14:58:25 +0100, Takashi Iwai wrote:
> send_display_send_uevent() sends two environment variable, and the
> first one GVT_DISPLAY_READY is set including a new line at the end of
> the string; that is obviously superfluous and wrong -- at least, it
> *looks* so when you only read the code.
> 
> However, it doesn't appear in the actual output by a (supposedly
> unexpected) trick.  The code uses snprintf() and truncates the string
> in size 20 bytes.  This makes the string as GVT_DISPLAY_READY=0 or
> ...=1 including the trailing NUL-letter.  That is, the '\n' found in
> the format string is always cut off as a result.
> 
> Although the code gives the correct result, it is confusing.  This
> patch addresses it, just removing the superfluous '\n' from the format
> string for avoiding further confusion.  If the argument "ready" were
> not a  bool, the size 20 should be corrected as well.  But it's a
> bool, so we can leave the magic number 20 as is for now.
> 
> FWIW, the bug was spotted by a new GCC7 warning:
>   drivers/gpu/drm/i915/gvt/handlers.c: In function 'pvinfo_mmio_write':
>   drivers/gpu/drm/i915/gvt/handlers.c:1042:34: error: 'snprintf' output 
> truncated before the last format character [-Werror=format-truncation=]
> snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
> ^~~~
>   drivers/gpu/drm/i915/gvt/handlers.c:1042:2: note: 'snprintf' output 21 
> bytes into a destination of size 20
> snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
> ^~~~
> 
> Fixes: 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization")
> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1025903
> Reported-by: Richard Biener 
> Cc: 
> Signed-off-by: Takashi Iwai 
> ---

Applied. Thanks!

>  drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 1d450627ff65..845aa1511cbf 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -1039,7 +1039,7 @@ static int send_display_ready_uevent(struct intel_vgpu 
> *vgpu, int ready)
>   char vmid_str[20];
>   char display_ready_str[20];
>  
> - snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
> + snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d", ready);
>   env[0] = display_ready_str;
>  
>   snprintf(vmid_str, 20, "VMID=%d", vgpu->id);
> -- 
> 2.11.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

[Intel-gfx] [GIT PULL] more GVT-g fixes for 4.11

[Zhenyu Wang]

Hi,

This contains recent gvt fixes that target for 4.11. Team is busy on
know issues fixing and improve usability. This includes IOMMU workaround
fix with proper dma mapping from Chuanxiao, some log message cleanup, one
kernel oops fix in error path of workload submission from Changbin, and
with other misc fixes, etc.

Thanks
--

The following changes since commit 2d6ceb8e654a0ce998762b13f0ba2c275220a244:

  drm/i915/gvt: fix vgpu type size init (2017-02-07 17:22:01 +0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-2017-02-15

for you to fetch changes up to 4a0b3444da3ce1090d0f894f4e343756a94ab8c3:

  drm/i915/gvt: return error code if dma map iova failed (2017-02-14 17:35:39 
+0800)


gvt-next-2017-02-15

- Chuanxiao's IOMMU workaround fix
- debug message cleanup from Changbin
- oops fix in fail path of workload submission when GPU reset from Changbin
- other misc fixes


Changbin Du (5):
  drm/i915/gvt: remove a noisy unimportant log in sched_policy
  drm/i915/gvt: remove a redundant end of line in debug log
  drm/i915/gvt: reduce the line of interrupt logs and log friendly
  drm/i915/gvt: fix crash at function release_shadow_wa_ctx
  drm/i915/gvt: add missing display part reset for vGPU reset

Chuanxiao Dong (5):
  drm/i915/gvt: Map shadow page before using it in shadow page table
  drm/i915/gvt: map pfn for PTE entry in kvm
  drm/i915/gvt: enable IOMMU for gvt
  drm/i915/gvt: optimize the inhibit context mmio load
  drm/i915/gvt: return error code if dma map iova failed

Dan Carpenter (1):
  drm/i915/gvt/kvmgt: remove some dead code

Xu Han (1):
  drm/i915/gvt: add sprite plane flip done support.

Zhenyu Wang (2):
  drm/i915/gvt: Fix alignment for GTT allocation
  drm/i915/gvt: Fix shadow context descriptor

 drivers/gpu/drm/i915/gvt/aperture_gm.c  | 15 +++
 drivers/gpu/drm/i915/gvt/cmd_parser.c   | 20 +-
 drivers/gpu/drm/i915/gvt/display.c  | 12 ++
 drivers/gpu/drm/i915/gvt/display.h  |  1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  2 +-
 drivers/gpu/drm/i915/gvt/gtt.c  | 70 +++--
 drivers/gpu/drm/i915/gvt/gvt.c  |  7 
 drivers/gpu/drm/i915/gvt/interrupt.c| 57 +++
 drivers/gpu/drm/i915/gvt/kvmgt.c| 70 -
 drivers/gpu/drm/i915/gvt/render.c   | 17 
 drivers/gpu/drm/i915/gvt/sched_policy.c |  1 -
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 ++-
 drivers/gpu/drm/i915/gvt/vgpu.c |  1 +
 13 files changed, 179 insertions(+), 99 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 v2] drm/i915/gvt/kvmgt: remove some dead code

[Zhenyu Wang]

On 2017.02.08 14:49:22 +0200, Joonas Lahtinen wrote:
> On ti, 2017-02-07 at 17:53 +0300, Dan Carpenter wrote:
> > "caps.buf" is always NULL here and "caps.size" is always zero.  The code
> > is a no-op and can be removed.
> > 
> > Signed-off-by: Dan Carpenter 
> 
> Reviewed-by: Joonas Lahtinen 
> 
> I assume Zhenyu will merge this through their tree.
> 

yeah, already put in queue. 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-g fixes for 4.11 merge

[Zhenyu Wang]

Hi,

These are GVT-g changes for 4.11 merge window, mostly for gvt init
order fix that impacted resource handling for device model, the one
i915 change has been reviewed and acked.

I can't find good tag on dinf for this now, so base on current dinf.
I can re-generate as required.

thanks
---

The following changes since commit 18566acac18f5784347bc5fe636a26897d1c963b:

  Merge branch 'exynos-drm-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next 
(2017-02-01 08:43:42 +1000)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-2017-02-07

for you to fetch changes up to 2d6ceb8e654a0ce998762b13f0ba2c275220a244:

  drm/i915/gvt: fix vgpu type size init (2017-02-07 17:22:01 +0800)


Chuanxiao Dong (1):
  drm/i915/gvt: add more resolutions in virtual edid

Zhenyu Wang (5):
  drm/i915: make intel_gvt_init() later instead of too early
  drm/i915/gvt: move intel iommu detection to intel_gvt_init()
  drm/i915/gvt: remove detect_host() MPT hook
  drm/i915/gvt: use normal mmio read function for firmware exposure
  drm/i915/gvt: fix vgpu type size init

 drivers/gpu/drm/i915/gvt/display.c   | 19 +--
 drivers/gpu/drm/i915/gvt/firmware.c  | 47 +++-
 drivers/gpu/drm/i915/gvt/gvt.c   | 14 +--
 drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
 drivers/gpu/drm/i915/gvt/kvmgt.c | 38 -
 drivers/gpu/drm/i915/gvt/mpt.h   | 12 -
 drivers/gpu/drm/i915/gvt/vgpu.c  | 13 +-
 drivers/gpu/drm/i915/i915_drv.c  | 14 +--
 drivers/gpu/drm/i915/intel_gvt.c |  5 
 9 files changed, 42 insertions(+), 121 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] MAINTAINERS: update new mail list for intel gvt driver

[Zhenyu Wang]

On 2017.01.25 12:49:48 +0200, Jani Nikula wrote:
> Side note, in the admin interface, please allow anyone subscribed to
> intel-gfx or dri-devel post to intel-gvt-dev without moderation. It's
> under Privacy options... | Sender filters | List of non-member addresses
> whose postings should be automatically accepted. Add @intel-gfx and
> @dri-devel there, one per line. (I whitelisted intel-gvt-dev members for
> intel-gfx).
> 

Changed that 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

[Intel-gfx] [GIT PULL] GVT-g fixes for 4.10-rc6

[Zhenyu Wang]

Hi,

This is gvt fixes for rc6 including shadow batch buffer re-enable
which was falsely turned off during initial upstream merge, which is a
security issue, Tina re-enabled and verified with Chris's patch too.
Also include important ABI fix from Alex, caused by a typo but impact
usage with libvirt integration. And update new mail list address for
gvt.

btw, gvt team will be offline for coming chinese new year from Jan 27,
most people would come back from Feb 5.

Thanks.

---

The following changes since commit c34eaa8d0f9d9ae26a4a6af7bc3aca57310cf483:

  drm/i915/gvt: rewrite gt reset handler using new function 
intel_gvt_reset_vgpu_locked (2017-01-13 15:05:38 +0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-01-25

for you to fetch changes up to ba7addcd805e5c83e201b118a2693b921a980b44:

  MAINTAINERS: update new mail list for intel gvt driver (2017-01-25 10:30:02 
+0800)


gvt-fixes-2017-01-25

- re-enable shadow batch buffer for security that was falsely turned off.
- kvmgt/mdev typo fix for correct ABI
- gvt mail list change


Alex Williamson (2):
  drm/i915/gvt/kvmgt: mdev ABI is available_instances, not 
available_instance
  drm/i915/gvt: Fix kmem_cache_create() name

Chris Wilson (1):
  drm/i915/gvt: Fix relocation of shadow bb

Tina Zhang (1):
  drm/i915/gvt: Enable the shadow batch buffer

Zhenyu Wang (1):
  MAINTAINERS: update new mail list for intel gvt driver

 MAINTAINERS   |  2 +-
 drivers/gpu/drm/i915/gvt/cmd_parser.c |  4 ---
 drivers/gpu/drm/i915/gvt/execlist.c   | 66 ++-
 drivers/gpu/drm/i915/gvt/kvmgt.c  |  8 ++---
 drivers/gpu/drm/i915/gvt/scheduler.h  |  2 +-
 5 files changed, 25 insertions(+), 57 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] [PATCH] MAINTAINERS: update new mail list for intel gvt driver

[Zhenyu Wang]

We've moved to lists.freedesktop.org from lists.01.org.
Update info in MAINTAINERS.

Signed-off-by: Zhenyu Wang 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f0420a..5bd03d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4153,7 +4153,7 @@ F:Documentation/gpu/i915.rst
 INTEL GVT-g DRIVERS (Intel GPU Virtualization)
 M:  Zhenyu Wang 
 M:  Zhi Wang 
-L:  igvt-g-...@lists.01.org
+L:  intel-gvt-...@lists.freedesktop.org
 L:  intel-gfx@lists.freedesktop.org
 W:  https://01.org/igvt-g
 T:  git https://github.com/01org/gvt-linux.git
-- 
2.10.2

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

Re: [Intel-gfx] [igvt-g-dev] [PATCH] drm/i915/gvt: Fix kmem_cache_create() name

[Zhenyu Wang]

On 2017.01.24 13:15:43 -0700, Alex Williamson wrote:
> According to kmem_cache_sanity_check(), spaces are not allowed in the
> name of a cache and results in a kernel oops with CONFIG_DEBUG_VM.
> Convert to underscores.
> 
> Signed-off-by: Alex Williamson 
> ---

Will send to 4.10 fixes. Thanks!

>  drivers/gpu/drm/i915/gvt/execlist.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> b/drivers/gpu/drm/i915/gvt/execlist.c
> index f32bb6f..d03b229 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.c
> +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> @@ -826,7 +826,7 @@ int intel_vgpu_init_execlist(struct intel_vgpu *vgpu)
>   INIT_LIST_HEAD(&vgpu->workload_q_head[i]);
>   }
>  
> - vgpu->workloads = kmem_cache_create("gvt-g vgpu workload",
> + vgpu->workloads = kmem_cache_create("gvt-g_vgpu_workload",
>   sizeof(struct intel_vgpu_workload), 0,
>   SLAB_HWCACHE_ALIGN,
>   NULL);
> 
> ___
> igvt-g-dev mailing list
> igvt-g-...@lists.01.org
> https://lists.01.org/mailman/listinfo/igvt-g-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] [igvt-g-dev] [PATCH] drm/i915/gvt/kvmgt: mdev ABI is available_instances, not available_instance

[Zhenyu Wang]

On 2017.01.24 12:53:45 -0700, Alex Williamson wrote:
> Per the ABI specification[1], each mdev_supported_types entry should
> have an available_instances, with an "s", not available_instance.
> 
> [1] Documentation/ABI/testing/sysfs-bus-vfio-mdev
> 
> Signed-off-by: Alex Williamson 
> ---
> 
> This should really be fixed before initial release in v4.10

Will queue this up for 4.10 fixes. 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-g fixes for 4.10-rc5

[Zhenyu Wang]

Hi,

This pull contains vGPU/mdev reset fixes from Changbin to fix vGPU hang
for VM reboot and vGPU/mdev instance reuse issues that might impact usage. 
Several preparation patches are to align reset code for each functional part
and actual fix is just to reset device model state for all components.

Thanks.

---
The following changes since commit 9631739f8196ec80b5d9bf955f79b711490c0205:

  drm/i915/gvt: cleanup GFP flags (2017-01-09 17:31:05 +0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-01-16

for you to fetch changes up to c34eaa8d0f9d9ae26a4a6af7bc3aca57310cf483:

  drm/i915/gvt: rewrite gt reset handler using new function 
intel_gvt_reset_vgpu_locked (2017-01-13 15:05:38 +0800)


gvt-fixes-2017-01-16

vGPU reset fixes from Changbin.


Changbin Du (8):
  drm/i915/gvt: introudce intel_vgpu_reset_resource() to reset vgpu 
resource state
  drm/i915/gvt: introuduce intel_vgpu_reset_gtt() to reset gtt
  drm/i915/gvt: move cfg space inititation function to cfg_space.c
  drm/i915/gvt: introduce intel_vgpu_reset_cfg_space to reset configuration 
space
  drm/i915/gvt: move mmio init/clean function to mmio.c
  drm/i915/gvt: introduce intel_vgpu_reset_mmio() to reset mmio space
  drm/i915/gvt: fix vGPU instance reuse issues by vGPU reset function
  drm/i915/gvt: rewrite gt reset handler using new function 
intel_gvt_reset_vgpu_locked

 drivers/gpu/drm/i915/gvt/aperture_gm.c |  29 ++-
 drivers/gpu/drm/i915/gvt/cfg_space.c   |  74 
 drivers/gpu/drm/i915/gvt/gtt.c |  27 ++
 drivers/gpu/drm/i915/gvt/gtt.h |   1 +
 drivers/gpu/drm/i915/gvt/gvt.h |   8 +-
 drivers/gpu/drm/i915/gvt/handlers.c|  90 +++
 drivers/gpu/drm/i915/gvt/mmio.c|  53 
 drivers/gpu/drm/i915/gvt/mmio.h|   4 +
 drivers/gpu/drm/i915/gvt/vgpu.c| 154 -
 9 files changed, 298 insertions(+), 142 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] [igvt-g-dev] [PATCH v2 2/3] drm/i915: Extract reserving space in the GTT to a helper

[Zhenyu Wang]

On 2017.01.11 11:23:11 +, Chris Wilson wrote:
> Extract drm_mm_reserve_node + calling i915_gem_evict_for_node into its
> own routine so that it can be shared rather than duplicated.
> 
> v2: Kerneldoc
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: igvt-g-...@lists.01.org
> Reviewed-by: Joonas Lahtinen 
> ---

Looks good for vgpu balloon change.

Acked-by: Zhenyu Wang 

>  drivers/gpu/drm/i915/i915_drv.h|  5 ++--
>  drivers/gpu/drm/i915/i915_gem_evict.c  | 33 --
>  drivers/gpu/drm/i915/i915_gem_gtt.c| 51 
> ++
>  drivers/gpu/drm/i915/i915_gem_gtt.h|  5 
>  drivers/gpu/drm/i915/i915_gem_stolen.c |  7 ++---
>  drivers/gpu/drm/i915/i915_trace.h  | 16 +--
>  drivers/gpu/drm/i915/i915_vgpu.c   | 33 --
>  drivers/gpu/drm/i915/i915_vma.c| 16 ---
>  8 files changed, 105 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 89e0038ea26b..a29d138b6906 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3468,8 +3468,9 @@ int __must_check i915_gem_evict_something(struct 
> i915_address_space *vm,
> unsigned cache_level,
> u64 start, u64 end,
> unsigned flags);
> -int __must_check i915_gem_evict_for_vma(struct i915_vma *vma,
> - unsigned int flags);
> +int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
> +  struct drm_mm_node *node,
> +  unsigned int flags);
>  int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
>  
>  /* belongs in i915_gem_gtt.h */
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 6a5415e31acf..50b4645bf627 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -231,7 +231,8 @@ i915_gem_evict_something(struct i915_address_space *vm,
>  
>  /**
>   * i915_gem_evict_for_vma - Evict vmas to make room for binding a new one
> - * @target: address space and range to evict for
> + * @vm: address space to evict from
> + * @target: range (and color) to evict for
>   * @flags: additional flags to control the eviction algorithm
>   *
>   * This function will try to evict vmas that overlap the target node.
> @@ -239,18 +240,20 @@ i915_gem_evict_something(struct i915_address_space *vm,
>   * To clarify: This is for freeing up virtual address space, not for freeing
>   * memory in e.g. the shrinker.
>   */
> -int i915_gem_evict_for_vma(struct i915_vma *target, unsigned int flags)
> +int i915_gem_evict_for_node(struct i915_address_space *vm,
> + struct drm_mm_node *target,
> + unsigned int flags)
>  {
>   LIST_HEAD(eviction_list);
>   struct drm_mm_node *node;
> - u64 start = target->node.start;
> - u64 end = start + target->node.size;
> + u64 start = target->start;
> + u64 end = start + target->size;
>   struct i915_vma *vma, *next;
>   bool check_color;
>   int ret = 0;
>  
> - lockdep_assert_held(&target->vm->i915->drm.struct_mutex);
> - trace_i915_gem_evict_vma(target, flags);
> + lockdep_assert_held(&vm->i915->drm.struct_mutex);
> + trace_i915_gem_evict_node(vm, target, flags);
>  
>   /* Retire before we search the active list. Although we have
>* reasonable accuracy in our retirement lists, we may have
> @@ -258,18 +261,18 @@ int i915_gem_evict_for_vma(struct i915_vma *target, 
> unsigned int flags)
>* retiring.
>*/
>   if (!(flags & PIN_NONBLOCK))
> - i915_gem_retire_requests(target->vm->i915);
> + i915_gem_retire_requests(vm->i915);
>  
> - check_color = target->vm->mm.color_adjust;
> + check_color = vm->mm.color_adjust;
>   if (check_color) {
>   /* Expand search to cover neighbouring guard pages (or lack!) */
> - if (start > target->vm->start)
> + if (start > vm->start)
>   start -= I915_GTT_PAGE_SIZE;
> - if (end < target->vm->start + target->vm->total)
> + if (end < vm->start + vm->total)
>   end += I915_GTT_PAGE_SIZE;
>   }
>  
> - drm_mm_for_each_node_in_range(node, &target->vm->mm, start, end) {
>

Re: [Intel-gfx] [PATCH 1/5] drm/i915: make intel_gvt_init() later instead of too early

[Zhenyu Wang]

On 2017.01.11 11:13:06 +0800, Jike Song wrote:
> On 01/10/2017 02:52 PM, Zhenyu Wang wrote:
> > Previously intel_gvt_init() was called very early even before
> > MMIO initialization which had several drawbacks:
> > - Have to handle MMIO access for initial MMIO state dump if golden
> >   state firmware is not available
> > - Hypervisor detection should depend on pvinfo only instead of detecting
> >   hypervisor status.
> > - Don't know hw resource size e.g aperture, ggtt size to determine
> >   for vGPU type, etc.
> > 
> > This trys to move intel_gvt_init() call late after required info
> > has already been initialized for GVT host.
> > 
> > Signed-off-by: Zhenyu Wang 
> > ---
> >  drivers/gpu/drm/i915/gvt/gvt.c   | 20 
> >  drivers/gpu/drm/i915/i915_drv.c  | 14 +++---
> >  drivers/gpu/drm/i915/intel_gvt.c |  5 +
> >  3 files changed, 20 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> > index e6bf5c533fbe..35264a991776 100644
> > --- a/drivers/gpu/drm/i915/gvt/gvt.c
> > +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> > @@ -73,23 +73,19 @@ int intel_gvt_init_host(void)
> > if (intel_gvt_host.initialized)
> > return 0;
> >  
> > -   /* Xen DOM U */
> > -   if (xen_domain() && !xen_initial_domain())
> > -   return -ENODEV;
> > -
> > /* Try to load MPT modules for hypervisors */
> > -   if (xen_initial_domain()) {
> > +#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
> > +   /* Try KVMGT */
> > +   intel_gvt_host.mpt = try_then_request_module(
> > +   symbol_get(kvmgt_mpt), "kvmgt");
> > +   intel_gvt_host.hypervisor_type = INTEL_GVT_HYPERVISOR_KVM;
> > +#endif
> > +
> > +   if (!intel_gvt_host.mpt && xen_initial_domain()) {
> > /* In Xen dom0 */
> > intel_gvt_host.mpt = try_then_request_module(
> > symbol_get(xengt_mpt), "xengt");
> > intel_gvt_host.hypervisor_type = INTEL_GVT_HYPERVISOR_XEN;
> > -   } 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");
> > -   intel_gvt_host.hypervisor_type = INTEL_GVT_HYPERVISOR_KVM;
> > -#endif
> > }
> >  
> 
> Hi Zhenyu,
> 
> It is always easy for xengt to detect dom0 case, but difficult for kvmgt
> to detect host, so I guess xen_initial_domain() should be removed from here,
> and placed in xengt.ko.
> 
> [xengt.ko]
> 
>   static int __init xengt_init(void)
>   {
>  if (!xen_initial_domain())
>  return -EINVAL;
>   ...
> 
> [gvt]
>   request xengt_mpt
>   if (failed)
>   request kvmgt_mpt
> 
> With logic above, we can avoid calling xen_initial_domain(), and remove
> "#include " from gvt.c.
> 
> What'd you say? :)
> 

yep, sounds good 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] [PATCH 2/5] drm/i915/gvt: move intel iommu detection to intel_gvt_init()

[Zhenyu Wang]

On 2017.01.11 10:18:30 +0800, Jike Song wrote:
> On 01/10/2017 02:52 PM, Zhenyu Wang wrote:
> > Prepare to remove detect_host() hook. Move intel iommu detection early
> > in intel_gvt_init().
> > 
> > Signed-off-by: Zhenyu Wang 
> > ---
> >  drivers/gpu/drm/i915/gvt/gvt.c   | 7 +++
> >  drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
> >  2 files changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> > index 35264a991776..7a7886644acf 100644
> > --- a/drivers/gpu/drm/i915/gvt/gvt.c
> > +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> > @@ -73,6 +73,13 @@ int intel_gvt_init_host(void)
> > if (intel_gvt_host.initialized)
> > return 0;
> >  
> > +#ifdef CONFIG_INTEL_IOMMU
> > +   if (intel_iommu_gfx_mapped) {
> > +   gvt_err("Hardware IOMMU compatibility not yet supported, try to 
> > boot with intel_iommu=igfx_off\n");
> > +   return -ENODEV;
> > +   }
> > +#endif
> > +
> 
> Hi Zhenyu,
> 
> Per my understanding, the "intel_iommu=" parameter acts only on native (think 
> about XenGT),
> so it's better to keep it somewhere in kvmgt.c, maybe kvmgt_init()?
> 

hmm, I think it's just a limit for current gvt device model but not related to 
hypervisor,
and it would bail out to disable gvt only. Anyway we'll fix it soon so not 
worry much for 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

[Intel-gfx] [PATCH 3/5] drm/i915/gvt: remove detect_host() MPT hook

[Zhenyu Wang]

We only depend on pvinfo register for GVT-g state detection,
not require hypervisor host detect any more.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/gvt.c   |  7 ---
 drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
 drivers/gpu/drm/i915/gvt/kvmgt.c | 32 
 drivers/gpu/drm/i915/gvt/mpt.h   | 12 
 4 files changed, 52 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 7a7886644acf..c8002bf200ad 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -68,8 +68,6 @@ static const struct intel_gvt_ops intel_gvt_ops = {
  */
 int intel_gvt_init_host(void)
 {
-   int ret;
-
if (intel_gvt_host.initialized)
return 0;
 
@@ -99,11 +97,6 @@ int intel_gvt_init_host(void)
if (!intel_gvt_host.mpt)
return -EINVAL;
 
-   /* Try to detect if we're running in host instead of VM. */
-   ret = intel_gvt_hypervisor_detect_host();
-   if (ret)
-   return -ENODEV;
-
gvt_dbg_core("Running with hypervisor %s in host mode\n",
supported_hypervisors[intel_gvt_host.hypervisor_type]);
 
diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h 
b/drivers/gpu/drm/i915/gvt/hypercall.h
index 30e543f5a703..df7f33abd393 100644
--- a/drivers/gpu/drm/i915/gvt/hypercall.h
+++ b/drivers/gpu/drm/i915/gvt/hypercall.h
@@ -38,7 +38,6 @@
  * both Xen and KVM by providing dedicated hypervisor-related MPT modules.
  */
 struct intel_gvt_mpt {
-   int (*detect_host)(void);
int (*host_init)(struct device *dev, void *gvt, const void *ops);
void (*host_exit)(struct device *dev, void *gvt);
int (*attach_vgpu)(void *vgpu, unsigned long *handle);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index f29d2a27ccb1..080ca77abd22 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1248,37 +1248,6 @@ static void kvmgt_page_track_flush_slot(struct kvm *kvm,
spin_unlock(&kvm->mmu_lock);
 }
 
-static bool kvmgt_check_guest(void)
-{
-   unsigned int eax, ebx, ecx, edx;
-   char s[12];
-   unsigned int *i;
-
-   eax = KVM_CPUID_SIGNATURE;
-   ebx = ecx = edx = 0;
-
-   asm volatile ("cpuid"
- : "+a"(eax), "=b"(ebx), "=c"(ecx), "=d"(edx)
- :
- : "cc", "memory");
-   i = (unsigned int *)s;
-   i[0] = ebx;
-   i[1] = ecx;
-   i[2] = edx;
-
-   return !strncmp(s, "KVMKVMKVM", strlen("KVMKVMKVM"));
-}
-
-/**
- * NOTE:
- * It's actually impossible to check if we are running in KVM host,
- * since the "KVM host" is simply native. So we only dectect guest here.
- */
-static int kvmgt_detect_host(void)
-{
-   return kvmgt_check_guest() ? -ENODEV : 0;
-}
-
 static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu, struct kvm *kvm)
 {
struct intel_vgpu *itr;
@@ -1453,7 +1422,6 @@ static unsigned long kvmgt_virt_to_pfn(void *addr)
 }
 
 struct intel_gvt_mpt kvmgt_mpt = {
-   .detect_host = kvmgt_detect_host,
.host_init = kvmgt_host_init,
.host_exit = kvmgt_host_exit,
.attach_vgpu = kvmgt_attach_vgpu,
diff --git a/drivers/gpu/drm/i915/gvt/mpt.h b/drivers/gpu/drm/i915/gvt/mpt.h
index 1af5830c0a56..419353624c5a 100644
--- a/drivers/gpu/drm/i915/gvt/mpt.h
+++ b/drivers/gpu/drm/i915/gvt/mpt.h
@@ -44,18 +44,6 @@
  */
 
 /**
- * intel_gvt_hypervisor_detect_host - check if GVT-g is running within
- * hypervisor host/privilged domain
- *
- * Returns:
- * Zero on success, -ENODEV if current kernel is running inside a VM
- */
-static inline int intel_gvt_hypervisor_detect_host(void)
-{
-   return intel_gvt_host.mpt->detect_host();
-}
-
-/**
  * intel_gvt_hypervisor_host_init - init GVT-g host side
  *
  * Returns:
-- 
2.11.0

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

[Intel-gfx] [PATCH 4/5] drm/i915/gvt: use normal mmio read function for firmware exposure

[Zhenyu Wang]

As now gvt init is late after MMIO initialization, use normal MMIO
read function for initial firmware exposure if no available firmware
loaded.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/firmware.c | 47 -
 1 file changed, 4 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 2fae2a2ca96f..1cb29b2d7dc6 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -48,31 +48,6 @@ struct gvt_firmware_header {
unsigned char data[1];
 };
 
-#define RD(offset) (readl(mmio + offset.reg))
-#define WR(v, offset) (writel(v, mmio + offset.reg))
-
-static void bdw_forcewake_get(void __iomem *mmio)
-{
-   WR(_MASKED_BIT_DISABLE(0x), FORCEWAKE_MT);
-
-   RD(ECOBUS);
-
-   if (wait_for((RD(FORCEWAKE_ACK_HSW) & FORCEWAKE_KERNEL) == 0, 50))
-   gvt_err("fail to wait forcewake idle\n");
-
-   WR(_MASKED_BIT_ENABLE(FORCEWAKE_KERNEL), FORCEWAKE_MT);
-
-   if (wait_for((RD(FORCEWAKE_ACK_HSW) & FORCEWAKE_KERNEL), 50))
-   gvt_err("fail to wait forcewake ack\n");
-
-   if (wait_for((RD(GEN6_GT_THREAD_STATUS_REG) &
- GEN6_GT_THREAD_STATUS_CORE_MASK) == 0, 50))
-   gvt_err("fail to wait c0 wake up\n");
-}
-
-#undef RD
-#undef WR
-
 #define dev_to_drm_minor(d) dev_get_drvdata((d))
 
 static ssize_t
@@ -91,9 +66,9 @@ static struct bin_attribute firmware_attr = {
.mmap = NULL,
 };
 
-static int expose_firmware_sysfs(struct intel_gvt *gvt,
-   void __iomem *mmio)
+static int expose_firmware_sysfs(struct intel_gvt *gvt)
 {
+   struct drm_i915_private *dev_priv = gvt->dev_priv;
struct intel_gvt_device_info *info = &gvt->device_info;
struct pci_dev *pdev = gvt->dev_priv->drm.pdev;
struct intel_gvt_mmio_info *e;
@@ -132,7 +107,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt,
 
for (j = 0; j < e->length; j += 4)
*(u32 *)(p + e->offset + j) =
-   readl(mmio + e->offset + j);
+   I915_READ_NOTRACE(_MMIO(e->offset + j));
}
 
memcpy(gvt->firmware.mmio, p, info->mmio_size);
@@ -235,7 +210,6 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt)
struct gvt_firmware_header *h;
const struct firmware *fw;
char *path;
-   void __iomem *mmio;
void *mem;
int ret;
 
@@ -260,17 +234,6 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt)
 
firmware->mmio = mem;
 
-   mmio = pci_iomap(pdev, info->mmio_bar, info->mmio_size);
-   if (!mmio) {
-   kfree(path);
-   kfree(firmware->cfg_space);
-   kfree(firmware->mmio);
-   return -EINVAL;
-   }
-
-   if (IS_BROADWELL(gvt->dev_priv) || IS_SKYLAKE(gvt->dev_priv))
-   bdw_forcewake_get(mmio);
-
sprintf(path, "%s/vid_0x%04x_did_0x%04x_rid_0x%04x.golden_hw_state",
 GVT_FIRMWARE_PATH, pdev->vendor, pdev->device,
 pdev->revision);
@@ -300,13 +263,11 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt)
 
release_firmware(fw);
firmware->firmware_loaded = true;
-   pci_iounmap(pdev, mmio);
return 0;
 
 out_free_fw:
release_firmware(fw);
 expose_firmware:
-   expose_firmware_sysfs(gvt, mmio);
-   pci_iounmap(pdev, mmio);
+   expose_firmware_sysfs(gvt);
return 0;
 }
-- 
2.11.0

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

[Intel-gfx] [PATCH 5/5] drm/i915/gvt: fix vgpu type size init

[Zhenyu Wang]

As now gvt init after knowing hw resource info, we can determine vGPU
type from machine size instead of pre-defined value.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/vgpu.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index f0e86123e45b..cfeba443f7e2 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -147,7 +147,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
 int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
 {
unsigned int num_types;
-   unsigned int i, low_avail;
+   unsigned int i, low_avail, high_avail;
unsigned int min_low;
 
/* vGPU type name is defined as GVTg_Vx_y which contains
@@ -162,9 +162,9 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
 * to indicate how many vGPU instance can be created for this
 * type.
 *
-* Currently use static size here as we init type earlier..
 */
-   low_avail = MB_TO_BYTES(256) - HOST_LOW_GM_SIZE;
+   low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
+   high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
num_types = 4;
 
gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type),
@@ -179,7 +179,8 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
gvt->types[i].low_gm_size = min_low;
gvt->types[i].high_gm_size = max((min_low<<3), 
MB_TO_BYTES(384U));
gvt->types[i].fence = 4;
-   gvt->types[i].max_instance = low_avail / min_low;
+   gvt->types[i].max_instance = min(low_avail / min_low,
+high_avail / 
gvt->types[i].high_gm_size);
gvt->types[i].avail_instance = gvt->types[i].max_instance;
 
if (IS_GEN8(gvt->dev_priv))
@@ -215,9 +216,9 @@ static void intel_gvt_update_vgpu_types(struct intel_gvt 
*gvt)
/* Need to depend on maxium hw resource size but keep on
 * static config for now.
 */
-   low_gm_avail = MB_TO_BYTES(256) - HOST_LOW_GM_SIZE -
+   low_gm_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE -
gvt->gm.vgpu_allocated_low_gm_size;
-   high_gm_avail = MB_TO_BYTES(256) * 8UL - HOST_HIGH_GM_SIZE -
+   high_gm_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE -
gvt->gm.vgpu_allocated_high_gm_size;
fence_avail = gvt_fence_sz(gvt) - HOST_FENCE -
gvt->fence.vgpu_allocated_fence_num;
-- 
2.11.0

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

[Intel-gfx] [PATCH 0/5] Fix issues caused by gvt init timing

[Zhenyu Wang]

This trys to change origin gvt init time which was too early that caused several
workarounds be applied in GVT-g device model driver. To move gvt init a bit 
later,
we can fix up those without workarounds.

First one in series touches i915 driver init path that need to be acked.

thanks

Zhenyu Wang (5):
  drm/i915: make intel_gvt_init() later instead of too early
  drm/i915/gvt: move intel iommu detection to intel_gvt_init()
  drm/i915/gvt: remove detect_host() MPT hook
  drm/i915/gvt: use normal mmio read function for firmware exposure
  drm/i915/gvt: fix vgpu type size init

 drivers/gpu/drm/i915/gvt/firmware.c  | 47 +++-
 drivers/gpu/drm/i915/gvt/gvt.c   | 30 ++-
 drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
 drivers/gpu/drm/i915/gvt/kvmgt.c | 38 -
 drivers/gpu/drm/i915/gvt/mpt.h   | 12 -
 drivers/gpu/drm/i915/gvt/vgpu.c  | 13 +-
 drivers/gpu/drm/i915/i915_drv.c  | 14 +--
 drivers/gpu/drm/i915/intel_gvt.c |  5 
 8 files changed, 36 insertions(+), 124 deletions(-)

-- 
2.11.0

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

[Intel-gfx] [PATCH 2/5] drm/i915/gvt: move intel iommu detection to intel_gvt_init()

[Zhenyu Wang]

Prepare to remove detect_host() hook. Move intel iommu detection early
in intel_gvt_init().

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/gvt.c   | 7 +++
 drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 35264a991776..7a7886644acf 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -73,6 +73,13 @@ int intel_gvt_init_host(void)
if (intel_gvt_host.initialized)
return 0;
 
+#ifdef CONFIG_INTEL_IOMMU
+   if (intel_iommu_gfx_mapped) {
+   gvt_err("Hardware IOMMU compatibility not yet supported, try to 
boot with intel_iommu=igfx_off\n");
+   return -ENODEV;
+   }
+#endif
+
/* Try to load MPT modules for hypervisors */
 #if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
/* Try KVMGT */
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 0c9234a87a20..f29d2a27ccb1 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1276,12 +1276,6 @@ static bool kvmgt_check_guest(void)
  */
 static int kvmgt_detect_host(void)
 {
-#ifdef CONFIG_INTEL_IOMMU
-   if (intel_iommu_gfx_mapped) {
-   gvt_err("Hardware IOMMU compatibility not yet supported, try to 
boot with intel_iommu=igfx_off\n");
-   return -ENODEV;
-   }
-#endif
return kvmgt_check_guest() ? -ENODEV : 0;
 }
 
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/5] drm/i915: make intel_gvt_init() later instead of too early

[Zhenyu Wang]

Previously intel_gvt_init() was called very early even before
MMIO initialization which had several drawbacks:
- Have to handle MMIO access for initial MMIO state dump if golden
  state firmware is not available
- Hypervisor detection should depend on pvinfo only instead of detecting
  hypervisor status.
- Don't know hw resource size e.g aperture, ggtt size to determine
  for vGPU type, etc.

This trys to move intel_gvt_init() call late after required info
has already been initialized for GVT host.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/gvt.c   | 20 
 drivers/gpu/drm/i915/i915_drv.c  | 14 +++---
 drivers/gpu/drm/i915/intel_gvt.c |  5 +
 3 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index e6bf5c533fbe..35264a991776 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -73,23 +73,19 @@ int intel_gvt_init_host(void)
if (intel_gvt_host.initialized)
return 0;
 
-   /* Xen DOM U */
-   if (xen_domain() && !xen_initial_domain())
-   return -ENODEV;
-
/* Try to load MPT modules for hypervisors */
-   if (xen_initial_domain()) {
+#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
+   /* Try KVMGT */
+   intel_gvt_host.mpt = try_then_request_module(
+   symbol_get(kvmgt_mpt), "kvmgt");
+   intel_gvt_host.hypervisor_type = INTEL_GVT_HYPERVISOR_KVM;
+#endif
+
+   if (!intel_gvt_host.mpt && xen_initial_domain()) {
/* In Xen dom0 */
intel_gvt_host.mpt = try_then_request_module(
symbol_get(xengt_mpt), "xengt");
intel_gvt_host.hypervisor_type = INTEL_GVT_HYPERVISOR_XEN;
-   } 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");
-   intel_gvt_host.hypervisor_type = INTEL_GVT_HYPERVISOR_KVM;
-#endif
}
 
/* Fail to load MPT modules - bail out */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d22b4b479b8..9270dda354db 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -815,10 +815,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
if (ret < 0)
return ret;
 
-   ret = intel_gvt_init(dev_priv);
-   if (ret < 0)
-   goto err_workqueues;
-
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
 
@@ -832,7 +828,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
intel_init_audio_hooks(dev_priv);
ret = i915_gem_load_init(dev_priv);
if (ret < 0)
-   goto err_gvt;
+   goto err_workqueues;
 
intel_display_crc_init(dev_priv);
 
@@ -844,8 +840,6 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
return 0;
 
-err_gvt:
-   intel_gvt_cleanup(dev_priv);
 err_workqueues:
i915_workqueues_cleanup(dev_priv);
return ret;
@@ -1068,6 +1062,10 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_DRIVER("can't enable MSI");
}
 
+   ret = intel_gvt_init(dev_priv);
+   if (ret)
+   goto out_ggtt;
+
return 0;
 
 out_ggtt:
@@ -1281,6 +1279,8 @@ void i915_driver_unload(struct drm_device *dev)
 
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
+   intel_gvt_cleanup(dev_priv);
+
i915_driver_unregister(dev_priv);
 
drm_vblank_cleanup(dev);
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index 290384e86c63..d23c0fcff751 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -67,6 +67,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
return 0;
}
 
+   if (intel_vgpu_active(dev_priv)) {
+   DRM_DEBUG_DRIVER("GVT-g is disabled for guest\n");
+   goto bail;
+   }
+
if (!is_supported_device(dev_priv)) {
DRM_DEBUG_DRIVER("Unsupported device. GVT-g is disabled\n");
goto bail;
-- 
2.11.0

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

[Intel-gfx] [GIT PULL] GVT-g fixes for 4.10-rc4

[Zhenyu Wang]

Hi,

Please pull GVT-g device model fixes for rc4. This is based on rc3 with
new vfio/mdev interface change.

Thanks.
---

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-01-10

for you to fetch changes up to 9631739f8196ec80b5d9bf955f79b711490c0205:

  drm/i915/gvt: cleanup GFP flags (2017-01-09 17:31:05 +0800)


Changbin Du (5):
  drm/i915/gvt: fix error handing of tlb_control emulation
  drm/i915/gvt: fix return value in mul_force_wake_write
  drm/i915/gvt: always use readq and writeq
  drm/i915/gvt: fix use after free for workload
  drm/i915/gvt: dec vgpu->running_workload_num after the workload is really 
done

Jike Song (5):
  drm/i915/gvt: init/destroy vgpu_idr properly
  drm/i915/gvt: destroy the allocated idr on vgpu creating failures
  drm/i915/gvt: cleanup opregion memory allocation code
  drm/i915/gvt/kvmgt: return meaningful error for vgpu creating failure
  drm/i915/gvt: cleanup GFP flags

Nicolas Iooss (1):
  drm/i915/gvt: verify functions types in new_mmio_info()

Pei Zhang (1):
  drm/i915/gvt: print correct value for untracked mmio

Zhenyu Wang (2):
  drm/i915/gvt: adjust high memory size for default vGPU type
  drm/i915/gvt: remove duplicated definition

 drivers/gpu/drm/i915/gvt/aperture_gm.c |  7 -
 drivers/gpu/drm/i915/gvt/gtt.c | 54 +++---
 drivers/gpu/drm/i915/gvt/gvt.c |  8 -
 drivers/gpu/drm/i915/gvt/handlers.c| 13 
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 14 ++---
 drivers/gpu/drm/i915/gvt/mmio.c| 31 +--
 drivers/gpu/drm/i915/gvt/opregion.c|  8 ++---
 drivers/gpu/drm/i915/gvt/reg.h |  3 +-
 drivers/gpu/drm/i915/gvt/scheduler.c   | 14 -
 drivers/gpu/drm/i915/gvt/vgpu.c|  8 +++--
 10 files changed, 73 insertions(+), 87 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] [PATCH v2] drm/i915: check ppgtt validity when init reg state

[Zhenyu Wang]

Check if ppgtt is valid for context when init reg state. For gvt
context which has no i915 allocated ppgtt, failed to check that
would cause kernel null ptr reference error.

v2: remove !48bit ppgtt case as we'll always update before submit (Chris)

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/intel_lrc.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6db246ad2f13..37fc9d4e876a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2103,19 +2103,12 @@ static void execlists_init_reg_state(u32 *reg_state,
ASSIGN_CTX_REG(reg_state, CTX_PDP0_LDW, GEN8_RING_PDP_LDW(engine, 0),
   0);
 
-   if (USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
+   if (ppgtt && USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
/* 64b PPGTT (48bit canonical)
 * PDP0_DESCRIPTOR contains the base address to PML4 and
 * other PDP Descriptors are ignored.
 */
ASSIGN_CTX_PML4(ppgtt, reg_state);
-   } else {
-   /* 32b PPGTT
-* PDP*_DESCRIPTOR contains the base address of space supported.
-* With dynamic page allocation, PDPs may not be allocated at
-* this point. Point the unallocated PDPs to the scratch page
-*/
-   execlists_update_context_pdps(ppgtt, reg_state);
}
 
if (engine->id == RCS) {
-- 
2.11.0

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

[Intel-gfx] [PATCH] drm/i915: check ppgtt validity when init reg state

[Zhenyu Wang]

Check if ppgtt is valid for context when init reg state. For gvt
context which has no i915 allocated ppgtt, failed to check that
would cause kernel null ptr reference error.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/intel_lrc.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6db246ad2f13..8f10927f6c84 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2103,19 +2103,21 @@ static void execlists_init_reg_state(u32 *reg_state,
ASSIGN_CTX_REG(reg_state, CTX_PDP0_LDW, GEN8_RING_PDP_LDW(engine, 0),
   0);
 
-   if (USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
-   /* 64b PPGTT (48bit canonical)
-* PDP0_DESCRIPTOR contains the base address to PML4 and
-* other PDP Descriptors are ignored.
-*/
-   ASSIGN_CTX_PML4(ppgtt, reg_state);
-   } else {
-   /* 32b PPGTT
-* PDP*_DESCRIPTOR contains the base address of space supported.
-* With dynamic page allocation, PDPs may not be allocated at
-* this point. Point the unallocated PDPs to the scratch page
-*/
-   execlists_update_context_pdps(ppgtt, reg_state);
+   if (ppgtt) {
+   if (USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
+   /* 64b PPGTT (48bit canonical)
+* PDP0_DESCRIPTOR contains the base address to PML4 and
+* other PDP Descriptors are ignored.
+*/
+   ASSIGN_CTX_PML4(ppgtt, reg_state);
+   } else {
+   /* 32b PPGTT
+* PDP*_DESCRIPTOR contains the base address of space 
supported.
+* With dynamic page allocation, PDPs may not be 
allocated at
+* this point. Point the unallocated PDPs to the 
scratch page
+*/
+   execlists_update_context_pdps(ppgtt, reg_state);
+   }
}
 
if (engine->id == RCS) {
-- 
2.11.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 relocation of shadow bb

[Zhenyu Wang]

On 2017.01.06 19:58:16 +, Chris Wilson wrote:
> set_gma_to_bb_cmd() is completely bogus - it is (incorrectly) applying
> the rules to read a GTT offset from a command as opposed to writing the
> GTT offset. And to cap it all set_gma_to_bb_cmd() is called within a list
> iterator of the most strange construction.
>

Looks fine to me. I'll pick up this after validating with batch buffer scan on.

Thanks.

> Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
> Signed-off-by: Chris Wilson 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: Yulei Zhang 
> Cc:  # v4.10-rc1+
> ---
>  drivers/gpu/drm/i915/gvt/execlist.c  | 64 
> ++--
>  drivers/gpu/drm/i915/gvt/scheduler.h |  2 +-
>  2 files changed, 19 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> b/drivers/gpu/drm/i915/gvt/execlist.c
> index 9a98553ad742..4b8454b445cd 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.c
> +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> @@ -364,58 +364,30 @@ static void free_workload(struct intel_vgpu_workload 
> *workload)
>  #define get_desc_from_elsp_dwords(ed, i) \
>   ((struct execlist_ctx_descriptor_format *)&((ed)->data[i * 2]))
>  
> -
> -#define BATCH_BUFFER_ADDR_MASK ((1UL << 32) - (1U << 2))
> -#define BATCH_BUFFER_ADDR_HIGH_MASK ((1UL << 16) - (1U))
> -static int set_gma_to_bb_cmd(struct intel_shadow_bb_entry *entry_obj,
> -  unsigned long add, int gmadr_bytes)
> -{
> - if (WARN_ON(gmadr_bytes != 4 && gmadr_bytes != 8))
> - return -1;
> -
> - *((u32 *)(entry_obj->bb_start_cmd_va + (1 << 2))) = add &
> - BATCH_BUFFER_ADDR_MASK;
> - if (gmadr_bytes == 8) {
> - *((u32 *)(entry_obj->bb_start_cmd_va + (2 << 2))) =
> - add & BATCH_BUFFER_ADDR_HIGH_MASK;
> - }
> -
> - return 0;
> -}
> -
>  static void prepare_shadow_batch_buffer(struct intel_vgpu_workload *workload)
>  {
> - int gmadr_bytes = workload->vgpu->gvt->device_info.gmadr_bytes_in_cmd;
> + const int gmadr_bytes = 
> workload->vgpu->gvt->device_info.gmadr_bytes_in_cmd;
> + struct intel_shadow_bb_entry *entry_obj;
>  
>   /* pin the gem object to ggtt */
> - if (!list_empty(&workload->shadow_bb)) {
> - struct intel_shadow_bb_entry *entry_obj =
> - list_first_entry(&workload->shadow_bb,
> -  struct intel_shadow_bb_entry,
> -  list);
> - struct intel_shadow_bb_entry *temp;
> + list_for_each_entry(entry_obj, &workload->shadow_bb, list) {
> + struct i915_vma *vma;
>  
> - list_for_each_entry_safe(entry_obj, temp, &workload->shadow_bb,
> - list) {
> - struct i915_vma *vma;
> -
> - vma = i915_gem_object_ggtt_pin(entry_obj->obj, NULL, 0,
> -4, 0);
> - if (IS_ERR(vma)) {
> - gvt_err("Cannot pin\n");
> - return;
> - }
> -
> - /* FIXME: we are not tracking our pinned VMA leaving it
> -  * up to the core to fix up the stray pin_count upon
> -  * free.
> -  */
> -
> - /* update the relocate gma with shadow batch buffer*/
> - set_gma_to_bb_cmd(entry_obj,
> -   i915_ggtt_offset(vma),
> -   gmadr_bytes);
> + vma = i915_gem_object_ggtt_pin(entry_obj->obj, NULL, 0, 4, 0);
> + if (IS_ERR(vma)) {
> + gvt_err("Cannot pin\n");
> + return;
>   }
> +
> + /* FIXME: we are not tracking our pinned VMA leaving it
> +  * up to the core to fix up the stray pin_count upon
> +  * free.
> +  */
> +
> + /* update the relocate gma with shadow batch buffer*/
> + entry_obj->bb_start_cmd_va[1] = i915_ggtt_offset(vma);
> + if (gmadr_bytes == 8)
> + entry_obj->bb_start_cmd_va[2] = 0;
>   }
>  }
>  
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.h 
> b/drivers/gpu/drm/i915/gvt/scheduler.h
> index 3b30c28bff51..2833dfa8c9ae 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.h
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.h
> @@ -113

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

[Zhenyu Wang]

On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
> > Alex, I liked to have kvmgt related mdev interface change be merged through
> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> > below fix in your tree? I think in general for possible interface change in
> > future we still need a pull request for i915 to resolve dependence earlier.
> 
> Hi Zhenyu,
> 
> Hopefully this abstraction will help to isolate vendor drivers from
> mdev API changes in the future.  I can certainly roll this patch into
> the original to maintain bisectability.  I want to get these changes in
> for rc3, will a pull request for the i915 changes be sent this week?

Send to Jani who is managing i915 fixes pull.

-- 
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: build failure after merge of the drm-intel-fixes tree

[Zhenyu Wang]

On 2017.01.03 10:42:39 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'intel_vgpu_open':
> drivers/gpu/drm/i915/gvt/kvmgt.c:511:32: error: dereferencing pointer to 
> incomplete type 'struct mdev_device'
>   vfio_unregister_notifier(&mdev->dev, VFIO_GROUP_NOTIFY,
> ^   
> 
> Caused by commit
> 
>   99e3123e3d72 ("vfio-mdev: Make mdev_device private and abstract interfaces")
> 
> from the vfio-fixes tree interacting with commit
> 
>   364fb6b789ff ("drm/i915/gvt/kvmgt: prevent double-release of vgpu")
> 
> from the drm-intel-fixes tree.

Alex, I liked to have kvmgt related mdev interface change be merged through
vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
below fix in your tree? I think in general for possible interface change in
future we still need a pull request for i915 to resolve dependence earlier.

Thanks.

> 
> I applied this merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Tue, 3 Jan 2017 10:38:48 +1100
> Subject: [PATCH] vfio-mdev: fixup for "Make mdev_device private and abstract 
> interfaces"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index c24b665e007b..faaae07ae487 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -508,7 +508,7 @@ static int intel_vgpu_open(struct mdev_device *mdev)
>   return ret;
>  
>  undo_group:
> - vfio_unregister_notifier(&mdev->dev, VFIO_GROUP_NOTIFY,
> + vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
>   &vgpu->vdev.group_notifier);
>  
>  undo_iommu:
> -- 
> 2.10.2
> 
> -- 
> Cheers,
> Stephen Rothwell

-- 
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] [igvt-g-dev] [PATCH 1/1] drm/i915/gvt: verify functions types in new_mmio_info()

[Zhenyu Wang]

On 2016.12.26 14:52:23 +0100, Nicolas Iooss wrote:
> The current prototype of new_mmio_info() uses void* for parameters read
> and write, which are functions with precise calling conventions
> (argument types and return type). Write down these conventions in
> new_mmio_info() definition.
> 
> This has been reported by the following warnings when clang is used to
> build the kernel:
> 
> drivers/gpu/drm/i915/gvt/handlers.c:124:21: error: pointer type
> mismatch ('void *' and 'int (*)(struct intel_vgpu *, unsigned int,
> void *, unsigned int)') [-Werror,-Wpointer-type-mismatch]
> info->read = read ? read : intel_vgpu_default_mmio_read;
>   ^    
> drivers/gpu/drm/i915/gvt/handlers.c:125:23: error: pointer type
> mismatch ('void *' and 'int (*)(struct intel_vgpu *, unsigned int,
> void *, unsigned int)') [-Werror,-Wpointer-type-mismatch]
> info->write = write ? write : intel_vgpu_default_mmio_write;
> ^ ~   ~
> 
> This allows the compiler to detect that sbi_ctl_mmio_write() returns a
> "bool" value instead of an expected "int" one. Fix this.
>

Looks good to me. Will queue this up. Thanks

> Signed-off-by: Nicolas Iooss 
> ---
>  drivers/gpu/drm/i915/gvt/handlers.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 522809710312..052e57124c0a 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -93,7 +93,8 @@ static void write_vreg(struct intel_vgpu *vgpu, unsigned 
> int offset,
>  static int new_mmio_info(struct intel_gvt *gvt,
>   u32 offset, u32 flags, u32 size,
>   u32 addr_mask, u32 ro_mask, u32 device,
> - void *read, void *write)
> + int (*read)(struct intel_vgpu *, unsigned int, void *, unsigned 
> int),
> + int (*write)(struct intel_vgpu *, unsigned int, void *, 
> unsigned int))
>  {
>   struct intel_gvt_mmio_info *info, *p;
>   u32 start, end, i;
> @@ -974,7 +975,7 @@ static int sbi_data_mmio_read(struct intel_vgpu *vgpu, 
> unsigned int offset,
>   return 0;
>  }
>  
> -static bool sbi_ctl_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
> +static int sbi_ctl_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
>   void *p_data, unsigned int bytes)
>  {
>   u32 data;
> -- 
> 2.11.0
> 
> ___
> igvt-g-dev mailing list
> igvt-g-...@lists.01.org
> https://lists.01.org/mailman/listinfo/igvt-g-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] [GIT PULL] GVT-g fixes for 4.10

[Zhenyu Wang]

Hi,

This is current GVT-g device model fixes for 4.10. I need to
base on v4.10-rc1 for merged vfio and KVMGT support.

Thanks. Merry Christmas!
---
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-fixes-2016-12-26

for you to fetch changes up to 4e0203ba11e735694600d7c704d7d56f069f9eb6:

  drm/i915/gvt: fix typo in cfg_space range check (2016-12-26 10:05:11 +0800)


Jike Song (4):
  drm/i915/gvt/kvmgt: dereference the pointer within lock
  drm/i915/gvt/kvmgt: check returned slot for gfn
  drm/i915/gvt/kvmgt: prevent double-release of vgpu
  drm/i915/gvt/kvmgt: trival: code cleanup

Min He (2):
  drm/i915/gvt: fix an error in opregion handling
  drm/i915/gvt: fix an issue in emulating cfg space PCI_COMMAND

Pei Zhang (1):
  drm/i915/gvt: fix typo in cfg_space range check

Ping Gao (1):
  drm/i915/gvt: reset the GGTT entry when vGPU created

 drivers/gpu/drm/i915/gvt/cfg_space.c |  4 +--
 drivers/gpu/drm/i915/gvt/gtt.c   | 55 
 drivers/gpu/drm/i915/gvt/gtt.h   |  4 +++
 drivers/gpu/drm/i915/gvt/gvt.h   |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c | 46 +++---
 drivers/gpu/drm/i915/gvt/opregion.c  |  2 +-
 6 files changed, 99 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

[Intel-gfx] [git pull] GVT-g fixes for 4.10

[Zhenyu Wang]

Hi,

This is currently GVT-g driver fixes for 4.10-rc2.

Thanks.

---

The following changes since commit 0f484e42baaf5a38fc79e99b917caa5431651fb1:

  Merge tag 'kvmgt-vfio-mdev-for-v4.10-rc1' of git://github.com/01org/gvt-linux 
(2016-12-17 16:47:31 -0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-fixes-2016-12-22

for you to fetch changes up to ce5a8438d8f21efa13fdaa3f063832310bddab46:

  drm/i915/gvt: fix an issue in emulating cfg space PCI_COMMAND (2016-12-21 
15:20:10 +0800)


Jike Song (4):
  drm/i915/gvt/kvmgt: dereference the pointer within lock
  drm/i915/gvt/kvmgt: check returned slot for gfn
  drm/i915/gvt/kvmgt: prevent double-release of vgpu
  drm/i915/gvt/kvmgt: trival: code cleanup

Min He (2):
  drm/i915/gvt: fix an error in opregion handling
  drm/i915/gvt: fix an issue in emulating cfg space PCI_COMMAND

Ping Gao (1):
  drm/i915/gvt: reset the GGTT entry when vGPU created

 drivers/gpu/drm/i915/gvt/cfg_space.c |  2 +-
 drivers/gpu/drm/i915/gvt/gtt.c   | 55 
 drivers/gpu/drm/i915/gvt/gtt.h   |  4 +++
 drivers/gpu/drm/i915/gvt/gvt.h   |  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c | 46 +++---
 drivers/gpu/drm/i915/gvt/opregion.c  |  2 +-
 6 files changed, 98 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

Re: [Intel-gfx] [CI 4/7] drm/i915: Simplify releasing context reference

[Zhenyu Wang]

On 2016.12.18 15:37:21 +, Chris Wilson wrote:
> A few users only take the struct_mutex in order to release a reference
> to a context. We can expose a kref_put_mutex() wrapper in order to
> simplify these users, and optimise taking of the mutex to the final
> unref.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  7 +++
>  drivers/gpu/drm/i915/i915_perf.c | 16 
>  2 files changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dec4ddf132f7..6217f01d3c11 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3518,6 +3518,13 @@ static inline void i915_gem_context_put(struct 
> i915_gem_context *ctx)
>   kref_put(&ctx->ref, i915_gem_context_free);
>  }
>  
> +static inline void i915_gem_context_put_unlocked(struct i915_gem_context 
> *ctx)
> +{
> + kref_put_mutex(&ctx->ref,
> +i915_gem_context_free,
> +&ctx->i915->drm.struct_mutex);
> +}
> +

For kref_put_mutex() in final release func should unlock mutex, but I haven't
seen i915_gem_context_free() to handle that?

gvt context close change in this series breaks VM poweroff when destroy vGPU.


>  static inline struct intel_timeline *
>  i915_gem_context_lookup_timeline(struct i915_gem_context *ctx,
>struct intel_engine_cs *engine)
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index da8537cb8136..a1b7eec58be2 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -1555,8 +1555,6 @@ static long i915_perf_ioctl(struct file *file,
>   */
>  static void i915_perf_destroy_locked(struct i915_perf_stream *stream)
>  {
> - struct drm_i915_private *dev_priv = stream->dev_priv;
> -
>   if (stream->enabled)
>   i915_perf_disable_locked(stream);
>  
> @@ -1565,11 +1563,8 @@ static void i915_perf_destroy_locked(struct 
> i915_perf_stream *stream)
>  
>   list_del(&stream->link);
>  
> - if (stream->ctx) {
> - mutex_lock(&dev_priv->drm.struct_mutex);
> - i915_gem_context_put(stream->ctx);
> - mutex_unlock(&dev_priv->drm.struct_mutex);
> - }
> + if (stream->ctx)
> + i915_gem_context_put_unlocked(stream->ctx);
>  
>   kfree(stream);
>  }
> @@ -1738,11 +1733,8 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
> *dev_priv,
>  err_alloc:
>   kfree(stream);
>  err_ctx:
> - if (specific_ctx) {
> - mutex_lock(&dev_priv->drm.struct_mutex);
> - i915_gem_context_put(specific_ctx);
> - mutex_unlock(&dev_priv->drm.struct_mutex);
> - }
> + if (specific_ctx)
> + i915_gem_context_put_unlocked(specific_ctx);
>  err:
>   return ret;
>  }
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] [RESEND][GIT PULL] i915/gvt KVMGT tree for 4.10

[Zhenyu Wang]

Hi, Linus

This is KVMGT pull for 4.10 as explained by Daniel. The last minute
rebase is to appease git pull-request since the diffstat was obvious
bonghits and somehow included vfio/mdev again despite that was merged
already.

Thanks.

The following changes since commit 9439b3710df688d853eb6cb4851256f2c92b1797:

  Merge tag 'drm-for-v4.10' of git://people.freedesktop.org/~airlied/linux 
(2016-12-13 09:35:09 -0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/kvmgt-vfio-mdev-for-v4.10-rc1

for you to fetch changes up to 659643f7d81432189c2c87230e2feee4c75c14c1:

  drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT (2016-12-16 16:55:26 +0800)


kvmgt-vfio-mdev-for-v4.10-rc1

This is KVMGT support depending on VFIO/mdev framework.


Jike Song (3):
  drm/i915/gvt/kvmgt: replace kmalloc() by kzalloc()
  drm/i915/gvt/kvmgt: read/write GPA via KVM API
  drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT

 drivers/gpu/drm/i915/Kconfig  |   1 +
 drivers/gpu/drm/i915/gvt/Makefile |   2 -
 drivers/gpu/drm/i915/gvt/gvt.h|   6 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 975 +++---
 4 files changed, 923 insertions(+), 61 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] Guc parameter Handling

[Zhenyu Wang]

On 2016.12.15 22:36:40 +, Srivatsa, Anusha wrote:
> Hi All,
> 
>  
> 
> I was wondering if we intend to keep -1 and 2 for the enable_guc_submission
> parameter. Since now we are gating guc loads if either guc_submission or
> enable_huc parameter is set, why have a -1(platform default) and 2(forcefully
> load) option? We anyway do not have any special default set per platform. For
> now the default is 0 on all platforms. Moving forward if GuC gets more stable
> and we want to set a default to a certain platform, we can add -1 then.
> 
>  
> 
> Also, why have a 2? We can use enable_guc_submission=1 in order to make sure
> the guc is loaded and guc_submission is enabled and set 
> enable_guc_submission=0
> to make sure guc submission is not used.
> 
>  
> 
> Any thought on this?
> 
>  

For gvt, we need to disable guc submission in guest on current hw.
I just want to send one using current enable_guc_loading but if changed
to guc_submission/enable_huc later, I'll hold till that settle down.

To support HuC for guest, we will need to add extra pvinfo, so won't
allow guest kernel to load huc firmware but tell guest driver that HuC
is ready for use.

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] drm/i915/gvt: fix deadlock in dispatch_workload()'s error path

[Zhenyu Wang]

On 2016.12.04 23:57:18 +, Eric Engestrom wrote:
> 90d27a1 moved the lock before this error path but forgot to add an
> unlock here.
> 
> Fixes: 90d27a1b180e51ef0713 ("drm/i915/gvt: fix deadlock in workload_thread")
> Cc: Pei Zhang 
> Cc: Zhenyu Wang 
> Signed-off-by: Eric Engestrom 
> ---

Hi, this has been fixed on 
https://cgit.freedesktop.org/drm/drm-intel/commit/?h=drm-intel-next-fixes&id=53d6f812c0dbf1c9cad89b1c2118e61c13ca9677

Thanks!

>  drivers/gpu/drm/i915/gvt/scheduler.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index f898df3..cd13c4b 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -177,6 +177,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
>   if (IS_ERR(rq)) {
>   gvt_err("fail to allocate gem request\n");
> + mutex_unlock(&dev_priv->drm.struct_mutex);
>   workload->status = PTR_ERR(rq);
>   return workload->status;
>   }
> -- 
> Cheers,
>   Eric
> 

-- 
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-g device model fix

[Zhenyu Wang]

Hi,

Here's current left GVT-g device model bug fixes for pull.

Thanks.

---

The following changes since commit 53e86ada8e53fcdbe1593f70b7df85549ba70b9a:

  drm/i915/gvt: remove unresolved vfio pin/unpin pages interface dependency 
(2016-11-17 15:51:16 +0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux tags/gvt-next-2016-11-30

for you to fetch changes up to 53d6f812c0dbf1c9cad89b1c2118e61c13ca9677:

  drm/i915/gvt: fix lock not released bug for dispatch_workload() err path 
(2016-11-25 09:18:11 +0800)


gvt-next-2016-11-30

- initialize vgpu as primary for correct cfg space setting
- fix 64 bit bar emulation
- fix un-released lock issue on dispatch workload err path


Du, Changbin (1):
  drm/i915/gvt: fix missing init param.primary

Xiaoguang Chen (1):
  drm/i915/gvt: fix getting 64bit bar size error

Zhenyu Wang (1):
  drm/i915/gvt: fix lock not released bug for dispatch_workload() err path

 drivers/gpu/drm/i915/gvt/gvt.h   |  2 ++
 drivers/gpu/drm/i915/gvt/scheduler.c | 10 ++
 drivers/gpu/drm/i915/gvt/vgpu.c  |  1 +
 3 files changed, 9 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] [igvt-g-dev] [bug report] drm/i915/gvt: fix deadlock in workload_thread

[Zhenyu Wang]

On 2016.11.24 01:17:06 +0300, Dan Carpenter wrote:
> Hello Pei Zhang,
> 
> The patch 90d27a1b180e: "drm/i915/gvt: fix deadlock in
> workload_thread" from Nov 14, 2016, leads to the following static
> checker warning:
> 
>   drivers/gpu/drm/i915/gvt/scheduler.c:217 dispatch_workload()
>   warn: inconsistent returns 'mutex:&dev_priv->drm.struct_mutex'.
> 
> drivers/gpu/drm/i915/gvt/scheduler.c
>161  static int dispatch_workload(struct intel_vgpu_workload *workload)
>162  {
>163  int ring_id = workload->ring_id;
>164  struct i915_gem_context *shadow_ctx = 
> workload->vgpu->shadow_ctx;
>165  struct drm_i915_private *dev_priv = 
> workload->vgpu->gvt->dev_priv;
>166  struct drm_i915_gem_request *rq;
>167  int ret;
>168  
>169  gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
>170  ring_id, workload);
>171  
>172  shadow_ctx->desc_template = 
> workload->ctx_desc.addressing_mode <<
>173  GEN8_CTX_ADDRESSING_MODE_SHIFT;
>174  
>175  mutex_lock(&dev_priv->drm.struct_mutex);
>176  
>177  rq = i915_gem_request_alloc(dev_priv->engine[ring_id], 
> shadow_ctx);
>178  if (IS_ERR(rq)) {
>179  gvt_err("fail to allocate gem request\n");
>180  workload->status = PTR_ERR(rq);
>181  return workload->status;
> 
> We're holding the lock here, which is obviously a bug.  But also should
> we goto out?  I always thought that functions with an "out" label were
> future proof?
>

Thanks, Dan. Yes, missed alloc failure path. How about below one? Pei, is it 
fine for you?

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f898df3..4db2422 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -177,8 +177,8 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
if (IS_ERR(rq)) {
gvt_err("fail to allocate gem request\n");
-   workload->status = PTR_ERR(rq);
-   return workload->status;
+   ret = PTR_ERR(rq);
+   goto out;
}
 
gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
@@ -212,7 +212,8 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
if (ret)
workload->status = ret;
 
-   i915_add_request_no_flush(rq);
+   if (!IS_ERR_OR_NULL(rq))
+   i915_add_request_no_flush(rq);
mutex_unlock(&dev_priv->drm.struct_mutex);
return ret;
 }
@@ -460,7 +461,8 @@ static int workload_thread(void *priv)
 
complete_current_workload(gvt, ring_id);
 
-   i915_gem_request_put(fetch_and_zero(&workload->req));
+   if (workload->req)
+   i915_gem_request_put(fetch_and_zero(&workload->req));
 
if (need_force_wake)
intel_uncore_forcewake_put(gvt->dev_priv,


-- 
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 the release of PT page to the upper caller

[Zhenyu Wang]

On 2016.11.22 14:38:19 +, Chris Wilson wrote:
> On Tue, Nov 22, 2016 at 09:29:40PM +0800, Zhi Wang wrote:
> > Hi guys:
> > Would you mind to have a quick review on this patch? :P The
> > linux guest under GVT-g couldn't boot up without this patch in the
> > newer kernel.
> > 
> > Thanks,
> > Zhi.
> > 
> > On 11/21/16 19:44, Zhi Wang wrote:
> > >a PT page will be released if it doesn't contain any meaningful mappings
> > >during PPGTT page table shrinking. The PT entry in the upper level will
> > >be set to a scratch entry.
> > >
> > >Normally this works nicely, but in virtualization world, the PPGTT page
> > >table is tracked by hypervisor. Releasing the PT page before modifying
> > >the upper level PT entry would cause extra efforts.
> > >
> > >As the tracked page has been returned to OS before losing track from
> > >hypervisor, it could be written in any pattern. Hypervisor has to recognize
> > >if a page is still being used as a PT page by validating these writing
> > >patterns. It's complicated. Better let the guest modify the PT entry in
> > >upper level PT first, then release the PT page.
> > >
> > >Cc: Michał Winiarski 
> > >Cc: Michel Thierry 
> > >Cc: Joonas Lahtinen 
> > >Cc: Chris Wilson 
> > >Cc: Zhenyu Wang 
> > >Cc: Zhiyuan Lv 
> > >Signed-off-by: Zhi Wang 
> 
> The original didn't make it to me, so I just assumed a list issue.
> 
> For the record, I'd like to have some more detail on just when the hv is
> doing the page scanning. It makes it sound like you are actively
> scanning an idle range.
> 
> Reviewed-by: Chris Wilson 

Note that this should be queued for 4.9 fix otherwise 4.9 will be broken
as guest kernel version for GVT-g.

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] [igvt-g-dev] [PULL] GVT-g device model fixes

[Zhenyu Wang]

On 2016.11.17 08:55:26 +0100, Daniel Vetter wrote:
> Just to clarify the process: This week we have the cut-off for feature
> work for 4.10. Bugfixes are of course always welcome. But if you think
> it's serious enough I'm happy to wait.
> 

yeah, I'd like to include those for initial 4.10 merge.

Please help to pull updated gvt tree.

Thanks.

---

The following changes since commit 8be8f4a9a9ce48d545512ef7299da607401f3879:

  Merge tag 'gvt-next-kvmgt-framework' of https://github.com/01org/gvt-linux 
into drm-intel-next-queued (2016-11-10 19:07:30 +0100)

are available in the git repository at:

  https://github.com/01org/gvt-linux tags/gvt-next-2016-11-17

for you to fetch changes up to 53e86ada8e53fcdbe1593f70b7df85549ba70b9a:

  drm/i915/gvt: remove unresolved vfio pin/unpin pages interface dependency 
(2016-11-17 15:51:16 +0800)


gvt-next-2016-11-17

- Fix lock order issue found in guest stress test
- Fix several MMIO handlers to correct behavior
- Fix crash for vgpu execlist reset and memleak
- Fix a possible conflict for unresolved vfio mdev dependency
- other misc fixes


Du, Changbin (2):
  drm/i915/gvt: fix crash in vgpu_reset_execlist
  drm/i915/gvt: fix mem leakage in setup_vgpu_mmio for vgpu reset

Jani Nikula (1):
  drm/i915/gvt: drop checks for early Skylake revisions

Pei Zhang (2):
  drm/i915/gvt: fix deadlock in workload_thread
  drm/i915/gvt: check workload empty before real scan

Ping Gao (2):
  drm/i915/gvt: emulate right behavior for tlb_control
  drm/i915/gvt: add more MMIO regs with command access flag

Xiaoguang Chen (1):
  drm/i915/gvt: clear guest opregion

Zhenyu Wang (2):
  drm/i915/gvt: Fix static checker warning on 
intel_gvt_i2c_handle_aux_ch_write()
  drm/i915/gvt: remove unresolved vfio pin/unpin pages interface dependency

 drivers/gpu/drm/i915/gvt/cmd_parser.c |  3 ++-
 drivers/gpu/drm/i915/gvt/edid.c   |  3 +--
 drivers/gpu/drm/i915/gvt/edid.h   |  2 +-
 drivers/gpu/drm/i915/gvt/execlist.c   | 24 +++
 drivers/gpu/drm/i915/gvt/execlist.h   |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 37 ++-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 16 ++-
 drivers/gpu/drm/i915/gvt/scheduler.c  | 33 ---
 drivers/gpu/drm/i915/gvt/vgpu.c   | 11 ---
 9 files changed, 62 insertions(+), 69 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] [igvt-g-dev] [PULL] GVT-g device model fixes

[Zhenyu Wang]

On 2016.11.16 15:50:27 +0800, Zhenyu Wang wrote:
> 
> Hi,
> 
> Please pull current GVT-g device model fixes.
>

Sorry, pls hold on this as found a possible conflict, as this is
supposed to be last pull before 4.10 merge window, like to include
the fix for that, will send update later.

> Thanks.
> 
> ---
> 
> The following changes since commit 8be8f4a9a9ce48d545512ef7299da607401f3879:
> 
>   Merge tag 'gvt-next-kvmgt-framework' of https://github.com/01org/gvt-linux 
> into drm-intel-next-queued (2016-11-10 19:07:30 +0100)
> 
> are available in the git repository at:
> 
>   https://github.com/01org/gvt-linux tags/gvt-next-2016-11-16
> 
> for you to fetch changes up to 0aaee4cc834261dcfbfb57559442777344ee8cb5:
> 
>   drm/i915/gvt: check workload empty before real scan (2016-11-16 11:45:29 
> +0800)
> 
> 
> gvt-next-2016-11-16
> 
> - Fix lock order issue found in guest stress test
> - Fix several MMIO handlers to correct behavior
> - Fix crash for vgpu execlist reset and memleak
> - other misc fixes
> 
> 
> Du, Changbin (2):
>   drm/i915/gvt: fix crash in vgpu_reset_execlist
>   drm/i915/gvt: fix mem leakage in setup_vgpu_mmio for vgpu reset
> 
> Pei Zhang (2):
>   drm/i915/gvt: fix deadlock in workload_thread
>   drm/i915/gvt: check workload empty before real scan
> 
> Ping Gao (2):
>   drm/i915/gvt: emulate right behavior for tlb_control
>   drm/i915/gvt: add more MMIO regs with command access flag
> 
> Xiaoguang Chen (1):
>   drm/i915/gvt: clear guest opregion
> 
> Zhenyu Wang (1):
>   drm/i915/gvt: Fix static checker warning on 
> intel_gvt_i2c_handle_aux_ch_write()
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  3 ++-
>  drivers/gpu/drm/i915/gvt/edid.c   |  3 +--
>  drivers/gpu/drm/i915/gvt/edid.h   |  2 +-
>  drivers/gpu/drm/i915/gvt/execlist.c   | 24 +++-
>  drivers/gpu/drm/i915/gvt/execlist.h   |  2 +-
>  drivers/gpu/drm/i915/gvt/handlers.c   | 31 +--
>  drivers/gpu/drm/i915/gvt/scheduler.c  | 33 +
>  drivers/gpu/drm/i915/gvt/vgpu.c   | 11 ---
>  8 files changed, 54 insertions(+), 55 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827



> ___
> igvt-g-dev mailing list
> igvt-g-...@lists.01.org
> https://lists.01.org/mailman/listinfo/igvt-g-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] drm/i915: fix the dequeue logic for single_port_submission context

[Zhenyu Wang]

On 2016.11.16 22:05:04 +0800, Min He wrote:
> For a singl_port_submission context, it can only be submitted to port 0,
> and there shouldn't be any other context in port 1 at the same time. This
> is required by GVT-g context to have an opportunity to save/restore some
> non-hw context render registers.
> This patch is to implement the correct logic in execlists_dequeue.
> 
> v2: optimized code by following Chris's advice, and added more comments to
> explain the patch.
> v3: followed the coding style.
> 
> Signed-off-by: Min He 
> Signed-off-by: Zhenyu Wang 
> ---

Hi, Min, like Daniel said not need to add my s-o-b.

>  drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index f50feaa..b2c0d50 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -499,7 +499,8 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>* context (even though a different request) to
>* the second port.
>*/
> - if (ctx_single_port_submission(cursor->ctx))
> + if (ctx_single_port_submission(last->ctx) ||
> + ctx_single_port_submission(cursor->ctx))
>   break;
>  
>   GEM_BUG_ON(last->ctx == cursor->ctx);
> -- 
> 1.9.1
>

Reviewed-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] drm/i915/gvt: drop checks for early Skylake revisions

[Zhenyu Wang]

On 2016.11.16 12:13:59 +0200, Jani Nikula wrote:
> We no longer cater for pre-production revisions of Skylake.
> 
> Fixes: d4362225e8cb ("drm/i915/gvt: update misc ctl regs base on stepping 
> info")
> Cc: Ping Gao 
> Cc: Zhenyu Wang 
> Cc: Zhi Wang 
> Cc: 
> Signed-off-by: Jani Nikula 
> ---

applied, thanks!

>  drivers/gpu/drm/i915/gvt/handlers.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 1b3db0c7a6db..12cd9b2a415c 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -1279,14 +1279,12 @@ static int skl_misc_ctl_write(struct intel_vgpu 
> *vgpu, unsigned int offset,
>   case 0x4ddc:
>   vgpu_vreg(vgpu, offset) = 0x803c;
>   /* WaCompressedResourceSamplerPbeMediaNewHashMode:skl */
> - if (IS_SKL_REVID(dev_priv, SKL_REVID_C0, REVID_FOREVER))
> - I915_WRITE(reg, vgpu_vreg(vgpu, offset));
> + I915_WRITE(reg, vgpu_vreg(vgpu, offset));
>   break;
>   case 0x42080:
>   vgpu_vreg(vgpu, offset) = 0x8000;
>   /* WaCompressedResourceDisplayNewHashMode:skl */
> - if (IS_SKL_REVID(dev_priv, SKL_REVID_E0, REVID_FOREVER))
> - I915_WRITE(reg, vgpu_vreg(vgpu, offset));
> + I915_WRITE(reg, vgpu_vreg(vgpu, offset));
>   break;
>   default:
>   return -EINVAL;
> -- 
> 2.1.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

[Intel-gfx] [PULL] GVT-g device model fixes

[Zhenyu Wang]

Hi,

Please pull current GVT-g device model fixes.

Thanks.

---

The following changes since commit 8be8f4a9a9ce48d545512ef7299da607401f3879:

  Merge tag 'gvt-next-kvmgt-framework' of https://github.com/01org/gvt-linux 
into drm-intel-next-queued (2016-11-10 19:07:30 +0100)

are available in the git repository at:

  https://github.com/01org/gvt-linux tags/gvt-next-2016-11-16

for you to fetch changes up to 0aaee4cc834261dcfbfb57559442777344ee8cb5:

  drm/i915/gvt: check workload empty before real scan (2016-11-16 11:45:29 
+0800)


gvt-next-2016-11-16

- Fix lock order issue found in guest stress test
- Fix several MMIO handlers to correct behavior
- Fix crash for vgpu execlist reset and memleak
- other misc fixes


Du, Changbin (2):
  drm/i915/gvt: fix crash in vgpu_reset_execlist
  drm/i915/gvt: fix mem leakage in setup_vgpu_mmio for vgpu reset

Pei Zhang (2):
  drm/i915/gvt: fix deadlock in workload_thread
  drm/i915/gvt: check workload empty before real scan

Ping Gao (2):
  drm/i915/gvt: emulate right behavior for tlb_control
  drm/i915/gvt: add more MMIO regs with command access flag

Xiaoguang Chen (1):
  drm/i915/gvt: clear guest opregion

Zhenyu Wang (1):
  drm/i915/gvt: Fix static checker warning on 
intel_gvt_i2c_handle_aux_ch_write()

 drivers/gpu/drm/i915/gvt/cmd_parser.c |  3 ++-
 drivers/gpu/drm/i915/gvt/edid.c   |  3 +--
 drivers/gpu/drm/i915/gvt/edid.h   |  2 +-
 drivers/gpu/drm/i915/gvt/execlist.c   | 24 +++-
 drivers/gpu/drm/i915/gvt/execlist.h   |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c   | 31 +--
 drivers/gpu/drm/i915/gvt/scheduler.c  | 33 +
 drivers/gpu/drm/i915/gvt/vgpu.c   | 11 ---
 8 files changed, 54 insertions(+), 55 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] [igvt-g-dev] [bug report] drm/i915/gvt: vGPU display virtualization

[Zhenyu Wang]

On 2016.11.11 08:28:28 +, Chris Wilson wrote:
> On Fri, Nov 11, 2016 at 04:08:58PM +0800, Zhenyu Wang wrote:
> > 
> > On 2016.11.10 15:54:51 +0300, Dan Carpenter wrote:
> > > Hello Zhi Wang,
> > > 
> > > The patch 04d348ae3f0a: "drm/i915/gvt: vGPU display virtualization"
> > > from Apr 25, 2016, leads to the following static checker warning:
> > > 
> > >   drivers/gpu/drm/i915/gvt/edid.c:506 intel_gvt_i2c_handle_aux_ch_write()
> > >   warn: odd binop '0x0 & 0xff'
> > > 
> > > drivers/gpu/drm/i915/gvt/edid.c
> > >501  /* write the return value in AUX_CH_DATA reg which 
> > > includes:
> > >502   * ACK of I2C_WRITE
> > >503   * returned byte if it is READ
> > >504   */
> > >505  
> > >506  aux_data_for_write |= (GVT_AUX_I2C_REPLY_ACK & 0xff) << 
> > > 24;
> > > 
> > > GVT_AUX_I2C_REPLY_ACK is 0 << 6.  Which is weird.  The whole line is a
> > > no-op.
> > 
> > This is from DP spec for AUX i2c ack reply defined as 0 that we emulated
> > to reply. I think it's ok to keep as more explicitly to show reply command.
> 
> The line is confusing though: you imply that REPLY_ACK is > 256 and that
> you only want the low 8bits stuffed into the high 8bits of the dword.
> Sounds very weird for the definition, and you wonder whether it is safe.
> 
>   aux_data_for_write |= GVT_AUX_I2C_REPLY_ACK << 24;
> 
> is still a no-op but should not affend too many sensibilities.

Will change like that. 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] [igvt-g-dev] [bug report] drm/i915/gvt: vGPU display virtualization

[Zhenyu Wang]

On 2016.11.10 15:54:51 +0300, Dan Carpenter wrote:
> Hello Zhi Wang,
> 
> The patch 04d348ae3f0a: "drm/i915/gvt: vGPU display virtualization"
> from Apr 25, 2016, leads to the following static checker warning:
> 
>   drivers/gpu/drm/i915/gvt/edid.c:506 intel_gvt_i2c_handle_aux_ch_write()
>   warn: odd binop '0x0 & 0xff'
> 
> drivers/gpu/drm/i915/gvt/edid.c
>501  /* write the return value in AUX_CH_DATA reg which includes:
>502   * ACK of I2C_WRITE
>503   * returned byte if it is READ
>504   */
>505  
>506  aux_data_for_write |= (GVT_AUX_I2C_REPLY_ACK & 0xff) << 24;
> 
> GVT_AUX_I2C_REPLY_ACK is 0 << 6.  Which is weird.  The whole line is a
> no-op.

This is from DP spec for AUX i2c ack reply defined as 0 that we emulated
to reply. I think it's ok to keep as more explicitly to show reply command.

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-g KVMGT framework

[Zhenyu Wang]

Hi,

This is initial integration work to include KVMGT support which
base on MPT(Mediated Passthrough) interface for GVT-g device model.
Also include vGPU type definitions which means vGPU creation will
be type based to be integrated with future VFIO/mdev framework.

Thanks.

--
The following changes since commit 11840e2fff3fb0f90ab8d56f4ba7d3712a82c08f:

  Merge tag 'for-kvmgt' of git://git.kernel.org/pub/scm/virt/kvm/kvm into 
drm-intel-next-queued (2016-11-10 08:06:47 +0100)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-kvmgt-framework

for you to fetch changes up to f30437c5e7bfa9d8acc18058040efb4f474907c3:

  drm/i915/gvt: add KVMGT support (2016-11-10 15:45:39 +0800)


gvt-next-kvmgt-framework

This adds initial KVMGT framework based on GVT-g MPT(Mediated Passthrough) 
interface.


Bing Niu (1):
  drm/i915/gvt: don't rely on guest PPGTT entry to free old shadow data

Jike Song (5):
  drm/i915/gvt: remove obsolete code for old kvmgt opregion
  drm/i915/gvt: introduce host_init/host_exit to MPT
  drm/i915/gvt: allow several MPT methods to be NULL
  drm/i915/gvt: refactor intel_gvt_io_emulation_ops to be intel_gvt_ops
  drm/i915/gvt: add KVMGT support

Xiaoguang Chen (1):
  drm/i915/gvt: use kmap instead of kmap_atomic around guest memory access

Zhenyu Wang (1):
  drm/i915/gvt: add intel vgpu types support

 drivers/gpu/drm/i915/Kconfig |   9 +
 drivers/gpu/drm/i915/gvt/Makefile|   7 +-
 drivers/gpu/drm/i915/gvt/cfg_space.c |  12 +-
 drivers/gpu/drm/i915/gvt/gtt.c   |  51 +--
 drivers/gpu/drm/i915/gvt/gvt.c   |  29 +-
 drivers/gpu/drm/i915/gvt/gvt.h   |  63 +++-
 drivers/gpu/drm/i915/gvt/hypercall.h |  14 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c | 601 +++
 drivers/gpu/drm/i915/gvt/mmio.c  |   6 +-
 drivers/gpu/drm/i915/gvt/mmio.h  |   9 +-
 drivers/gpu/drm/i915/gvt/mpt.h   |  55 +++-
 drivers/gpu/drm/i915/gvt/opregion.c  |  34 +-
 drivers/gpu/drm/i915/gvt/scheduler.c |  16 +-
 drivers/gpu/drm/i915/gvt/vgpu.c  | 169 --
 14 files changed, 939 insertions(+), 136 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/kvmgt.c


-- 
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 i-g-t 2/4 v5] lib/igt_gvt: Make use of libkmod helpers and fix reading gvt parameter.

[Zhenyu Wang]

On 2016.11.03 18:28:11 +0200, Marius Vlad wrote:
> v2:
> - use igt_sysfs_get_boolean() to get gvt status (Chris Wilson)
> - do not hard-fail when i915 module could not be loaded/unloaded (Chris
> Wilson)
> 
> Signed-off-by: Marius Vlad 

Looks fine to me.

Acked-by: Zhenyu Wang 

> ---
>  lib/igt_gvt.c | 37 ++---
>  tests/gvt_basic.c |  2 +-
>  2 files changed, 19 insertions(+), 20 deletions(-)
> 
> diff --git a/lib/igt_gvt.c b/lib/igt_gvt.c
> index 8bbf9bd..4ab7433 100644
> --- a/lib/igt_gvt.c
> +++ b/lib/igt_gvt.c
> @@ -24,35 +24,30 @@
>  #include "igt.h"
>  #include "igt_gvt.h"
>  #include "igt_sysfs.h"
> +#include "igt_kmod.h"
>  
> +#include 
>  #include 
>  #include 
>  #include 
>  
>  static bool is_gvt_enabled(void)
>  {
> - FILE *file;
> - int value;
>   bool enabled = false;
> + int dir, fd;
>  
> - file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> - if (!file)
> + fd = __drm_open_driver(DRIVER_INTEL);
> + dir = igt_sysfs_open_parameters(fd);
> + if (dir < 0)
>   return false;
>  
> - if (fscanf(file, "%d", &value) == 1)
> - enabled = value;
> - fclose(file);
> + enabled = igt_sysfs_get_boolean(dir, "enable_gvt");
>  
> - errno = 0;
> - return enabled;
> -}
> + close(dir);
> + close(fd);
>  
> -static void unload_i915(void)
> -{
> - kick_fbcon(false);
> - /* pkill alsact */
> + return enabled;
>  
> - igt_ignore_warn(system("/sbin/modprobe -s -r i915"));
>  }
>  
>  bool igt_gvt_load_module(void)
> @@ -60,8 +55,11 @@ bool igt_gvt_load_module(void)
>   if (is_gvt_enabled())
>   return true;
>  
> - unload_i915();
> - igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=1"));
> + if (igt_i915_driver_unload())
> + return false;
> +
> + if (igt_i915_driver_load("enable_gvt=1"))
> + return false;
>  
>   return is_gvt_enabled();
>  }
> @@ -71,8 +69,9 @@ void igt_gvt_unload_module(void)
>   if (!is_gvt_enabled())
>   return;
>  
> - unload_i915();
> - igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=0"));
> + igt_i915_driver_unload();
> +
> + igt_i915_driver_load(NULL);
>  
>   igt_assert(!is_gvt_enabled());
>  }
> diff --git a/tests/gvt_basic.c b/tests/gvt_basic.c
> index 48b853a..4e909a5 100644
> --- a/tests/gvt_basic.c
> +++ b/tests/gvt_basic.c
> @@ -32,7 +32,7 @@ igt_main
>  
>   igt_fixture {
>   igt_require(igt_gvt_load_module());
> - fd = drm_open_driver(DRIVER_INTEL);
> + fd = __drm_open_driver(DRIVER_INTEL);
>   }
>  
>   igt_subtest_f("invalid-placeholder-test");
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: Disable access to stolen memory as a guest

[Zhenyu Wang]

On 2016.11.09 10:39:05 +, Chris Wilson wrote:
> Explicitly disable stolen memory when running as a guest in a virtual
> machine, since the memory is not mediated between clients and reserved
> entirely for the host. The actual size should be reported as zero, but
> like every other quirk we want to tell the user what is happening.
> 
> Signed-off-by: Chris Wilson 
> Cc: Zhenyu Wang 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 154fbb04419f..0f0b37cad63d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -417,6 +417,11 @@ int i915_gem_init_stolen(struct drm_device *dev)
>  
>   mutex_init(&dev_priv->mm.stolen_lock);
>  
> + if (intel_vgpu_active(dev_priv)) {
> + DRM_INFO("iGVT-g active, disabling use of stolen memory\n");
> + return 0;
> + }
> +
>  #ifdef CONFIG_INTEL_IOMMU
>   if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
>   DRM_INFO("DMAR active, disabling use of stolen memory\n");
> -- 
> 2.10.2
>

Reviewed-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] drm/i915/gvt: Disable access to stolen memory as a guest

[Zhenyu Wang]

On 2016.11.09 13:11:11 +0200, Joonas Lahtinen wrote:
> On ke, 2016-11-09 at 10:39 +, Chris Wilson wrote:
> > Explicitly disable stolen memory when running as a guest in a virtual
> > machine, since the memory is not mediated between clients and reserved
> > entirely for the host. 
> 
> I'd kind of expect it to get sliced down just like the aperture, what's
> the plan here?
> 

No plan to do more partition on stolen mem for mediation now.

I had a change to handle GMCH_CTL config which would show no stolen mem
for guest driver, so that could work for all OS gfx drivers. But I think
Chris's change is fine and I would polish GMCH_CTL handling patch.

> 
> > The actual size should be reported as zero, but
> > like every other quirk we want to tell the user what is happening.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Zhenyu Wang 
> > Cc: Joonas Lahtinen 
> -- 
> 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 0/2] extend page_track for external usage

[Zhenyu Wang]

On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote:
> >> Paolo, for this case, do you think it's feasible we pick them through
> >> drm/i915 merge path? As currently initial KVMGT patch sets require these
> >> exported symbols, that's why I ask how we should handle this dependency.
> >
> > Then it's actually a good thing that I dropped from kvm/queue!  You can
> > certainly include these patches, but please do that through a topic branch.
> >
> > I've prepared a branch for you
> > (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
> > Linus processes my outstanding pull request, the branch will only
> > include the three page-tracking patches.  Please pull that topic branch
> > into your own branch, and ensure you have a merge commit when you send
> > the pull request to Daniel.  The merge commit ensures that the workflow
> > was correct; use --no-ff if necessary.
> >
> > You can do the same for Jike's patches for the KVM-VFIO device, when
> > Alex reviews them, and I suppose you'll need a topic branch for mdev
> > too?  I didn't know that KVMGT was planned for 4.10.  In the future,
> > let's synchronize ahead so that we can prepare topic branches for you.
> 
> Ok, back from the useless wifi at plumbers, I can mail again. Zhenyu
> confirmed on irc that the initial code pile only needs this. For the
> cross-maintainer topic tree I prefer a formal pull request with stable
> tag. Please also cc: intel-gfx on that, since I plan to merge that one
> directly into i915.
> 

Paolo, could you help to do this for Daniel? Daniel would like to merge
current KVMGT required change for KVM directly, then I'd base KVMGT change
on that.

p.s, Daniel gave me this example 
https://lists.freedesktop.org/archives/intel-gfx/2015-December/082600.html,
which was for audio change merge.

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-g device model fixes

[Zhenyu Wang]

Hi,

This is current fixes for GVT-g device model part. Most notable is to
fix a regression from e95433c73a11 ("drm/i915: Rearrange
i915_wait_request() accounting with callers") which has stopped our
testing.

As for that regression fix, I have to base this series on top of it
as lacking a tag on dinq for that.

Thanks.

The following changes since commit e95433c73a11759203af1cae5958f998c9673370:

  drm/i915: Rearrange i915_wait_request() accounting with callers (2016-10-28 
20:53:43 +0100)

are available in the git repository at:

  https://github.com/01org/gvt-linux tags/gvt-next-2016-11-07

for you to fetch changes up to 3b6411c2c20525f98b8541b3060c9ed95e31a762:

  drm/i915/gvt: implement scratch page table tree for shadow PPGTT (2016-11-07 
14:17:02 +0800)


gvt-next-2016-11-07

- Fix regression from e95433c73a11
- Some MMIO handler fixes
- Add better handling for guest reset control
- stratch page table tree for shadow ppgtt


Du, Changbin (1):
  drm/i915/gvt: emulate vgpu engine reset control behavior

Ping Gao (5):
  drm/i915/gvt: remove unused variable 'execlist'
  drm/i915/gvt: add write vreg in MMIO DMA_CTRL handler
  drm/i915/gvt: correct the emulation in TLB control handler
  drm/i915/gvt: update misc ctl regs base on stepping info
  drm/i915/gvt: implement scratch page table tree for shadow PPGTT

Zhenyu Wang (2):
  drm/i915/gvt: Fix shift for cmd data size
  drm/i915/gvt: Fix workload status after wait

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |   4 +-
 drivers/gpu/drm/i915/gvt/gtt.c  | 151 +++-
 drivers/gpu/drm/i915/gvt/gtt.h  |  40 -
 drivers/gpu/drm/i915/gvt/handlers.c |  44 --
 drivers/gpu/drm/i915/gvt/render.c   |   2 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |   2 -
 drivers/gpu/drm/i915/gvt/scheduler.c|   2 +
 7 files changed, 172 insertions(+), 73 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 workload status after wait

[Zhenyu Wang]

On 2016.11.02 08:47:52 +0200, Joonas Lahtinen wrote:
> On ke, 2016-11-02 at 13:41 +0800, Zhenyu Wang wrote:
> > From commit e95433c73a11759203af1cae5958f998c9673370, workload status 
> > setting
> > was changed to only capture on error path, but we need to set it properly in
> > normal path too, otherwise we'll fail to complete workload which could lead
> > guest VM vGPU reset.
> > 
> 
> Should have Fixes tag with the above commit.
> 
> > @@ -455,7 +455,8 @@ static int workload_thread(void *priv)
> >     if (lret < 0) {
> >     workload->status = lret;
> >     gvt_err("fail to wait workload, skip\n");
> > -   }
> > +   } else
> > +   workload->status = 0;
> 
> All branches of if-else continuum must use braces if one does, so
> "} else {" here
> 

Thanks for the review. I'll queue this up in gvt-linux tree as it stopped
our testing and will be included in next pull request.

-- 
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 workload status after wait

[Zhenyu Wang]

From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting
was changed to only capture on error path, but we need to set it properly in
normal path too, otherwise we'll fail to complete workload which could lead
guest VM vGPU reset.

v2: uses braces and add Fixes tag.

Fixes: e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting with 
callers")
Cc: Chris Wilson 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 18acb45..843a5de 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -455,6 +455,8 @@ static int workload_thread(void *priv)
if (lret < 0) {
workload->status = lret;
gvt_err("fail to wait workload, skip\n");
+   } else {
+   workload->status = 0;
}
 
 complete:
-- 
2.10.2

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

[Intel-gfx] [PATCH] drm/i915/gvt: Fix workload status after wait

[Zhenyu Wang]

From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting
was changed to only capture on error path, but we need to set it properly in
normal path too, otherwise we'll fail to complete workload which could lead
guest VM vGPU reset.

Cc: Chris Wilson 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 18acb45..bc4c14a 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -455,7 +455,8 @@ static int workload_thread(void *priv)
if (lret < 0) {
workload->status = lret;
gvt_err("fail to wait workload, skip\n");
-   }
+   } else
+   workload->status = 0;
 
 complete:
gvt_dbg_sched("will complete workload %p\n, status: %d\n",
-- 
2.10.2

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

[Intel-gfx] [PULL] GVT-g device model

[Zhenyu Wang]

Hi,

Here's new pull request to address recent build issues reported
and with more cleanup and fixes. Passed VM regression tests.

Thanks.
--

The following changes since commit 19e6393fb5366a89705a62b3276ce42e990d12ce:

  drm/i915/gvt: do not ignore return value of create_scratch_page (2016-10-20 
17:31:36 +0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux tags/gvt-next-2016-10-27

for you to fetch changes up to e45d7b7f47a4849a5d3d55a2cf5802a72924d37b:

  drm/i915/gvt: fix nested sleeping issue (2016-10-27 11:20:42 +0800)


gvt-next-2016-10-27

- Resolve current left build issue with ACPI=n and 32bit kernel
- TLB workaround from Arkadiusz
- vGPU reset fix from Ping
- workload scheduler nesting sleep fix from Changbin
- more misc fixes for sparse warnings and cleanups


Arkadiusz Hiler (1):
  drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

Bing Niu (1):
  drm/i915/gvt: throw error basing on execlist submit result

Du, Changbin (3):
  drm/i915/gvt: use well wrapped set_mask_bits() instead of defining new one
  drm/i915/gvt: get msi cap offset from pdev directly
  drm/i915/gvt: fix nested sleeping issue

Jérémy Lefaure (2):
  drm/i915/gvt: fix bad 32 bit shift in gtt
  drm/i915/gvt: fix an error string format

Min He (1):
  drm/i915/gvt: fix an typo in skl_decode_mi_display_flip

Ping Gao (3):
  drm/i915/gvt: add vreg write for GDRST handler
  drm/i915/gvt: correct the reset logic
  drm/i915/gvt: add full vGPU reset support

Xiaoguang Chen (1):
  drm/i915/gvt: fix detect_host calling logic

Zhenyu Wang (3):
  drm/i915/gvt: Fix failure when ACPI is not enabled
  drm/i915: GVT-g driver depends on 64BIT kernel
  drm/i915/gvt: Fix broken mocs offset

 drivers/gpu/drm/i915/Kconfig  |  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 29 ++---
 drivers/gpu/drm/i915/gvt/gtt.c|  4 ++--
 drivers/gpu/drm/i915/gvt/gvt.c|  8 ++--
 drivers/gpu/drm/i915/gvt/gvt.h|  2 ++
 drivers/gpu/drm/i915/gvt/handlers.c   | 26 ++
 drivers/gpu/drm/i915/gvt/opregion.c   |  6 +++---
 drivers/gpu/drm/i915/gvt/render.c | 21 +++--
 drivers/gpu/drm/i915/gvt/scheduler.c  | 19 ---
 drivers/gpu/drm/i915/gvt/vgpu.c   |  4 ++--
 10 files changed, 83 insertions(+), 37 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] fail to build on 32-bit x86 report

[Zhenyu Wang]

On 2016.10.26 11:14:26 +1000, Dave Airlie wrote:
> http://kisskb.ellerman.id.au/kisskb/buildresult/12840554/
> 
> Since the GVT stuff it looks like some divide should be a do_div.
> 

yeah, we will fix 32bit build later, I plan to send another pull
tomorrow or the day after which will disable 32bit kernel first,
as we didn't support and tested.

sorry for the noise.

-- 
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 0/2] drm/i915/gvt: fix compilation errors in gtt.c

[Zhenyu Wang]

On 2016.10.24 15:33:34 -0400, Jérémy Lefaure wrote:
> On Mon, 24 Oct 2016 10:36:58 +0800
> Zhenyu Wang  wrote:
> 
> > On 2016.10.20 18:05:56 -0400, Jérémy Lefaure wrote:
> > > This series fixes 2 compilations errors in gvt/gtt.c on 32-bits platform:
> > >  [PATCH 1/2] drm/i915/gvt: fix bad 32 bit shift in gtt
> > >  [PATCH 2/2] drm/i915/gvt: fix an error string format
> > > 
> > > The file gtt.c still does not compile because of shifting errors. Should 
> > > the 32
> > > bits architecture be supported ?  
> > 
> > Hi, we don't have 32bit platform support now, so will depend on 64bit 
> > kernel only.
> > 
> Ok, that was I thought. Do my patches are valid anyway ? At least the
> 1st ?
> 

yes, I'll pick up these although not enough for fixing 32bit compiling.

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 0/2] drm/i915/gvt: fix compilation errors in gtt.c

[Zhenyu Wang]

On 2016.10.20 18:05:56 -0400, Jérémy Lefaure wrote:
> This series fixes 2 compilations errors in gvt/gtt.c on 32-bits platform:
>  [PATCH 1/2] drm/i915/gvt: fix bad 32 bit shift in gtt
>  [PATCH 2/2] drm/i915/gvt: fix an error string format
> 
> The file gtt.c still does not compile because of shifting errors. Should the 
> 32
> bits architecture be supported ?

Hi, we don't have 32bit platform support now, so will depend on 64bit kernel 
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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: fix compilation

[Zhenyu Wang]

On 2016.10.21 17:25:50 +0200, Arnd Bergmann wrote:
> Two functions in the newly added gvt render code are obviously
> broken, as they reference a variable without initialization and
> don't reference another variable at all:
> 
> drivers/gpu/drm/i915/gvt/render.c: In function 
> ???intel_gvt_load_render_mmio???:
> drivers/gpu/drm/i915/gvt/render.c:148:13: error: ???offset.reg??? may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/gpu/drm/i915/gvt/render.c: In function 
> ???intel_gvt_restore_render_mmio???:
> drivers/gpu/drm/i915/gvt/render.c:185:13: error: ???offset.reg??? may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This is probably not a correct fix, but it gets us a clean build
> by removing the unused arrays and initializing the offset variable
> to something that potentially might be correct.
> 
> Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch")
> Signed-off-by: Arnd Bergmann 
> ---

I think the correct fix is like

diff --git a/drivers/gpu/drm/i915/gvt/render.c 
b/drivers/gpu/drm/i915/gvt/render.c
index feebb65..cc23c3f 100644
--- a/drivers/gpu/drm/i915/gvt/render.c
+++ b/drivers/gpu/drm/i915/gvt/render.c
@@ -162,6 +162,7 @@ static void load_mocs(struct intel_vgpu *vgpu, int ring_id)
if (!IS_SKYLAKE(dev_priv))
return;
 
+   offset.reg = regs[ring_id];
for (i = 0; i < 64; i++) {
gen9_render_mocs[ring_id][i] = I915_READ(offset);
I915_WRITE(offset, vgpu_vreg(vgpu, offset));
@@ -199,6 +200,7 @@ static void restore_mocs(struct intel_vgpu *vgpu, int 
ring_id)
if (!IS_SKYLAKE(dev_priv))
return;
 
+   offset.reg = regs[ring_id];
for (i = 0; i < 64; i++) {
vgpu_vreg(vgpu, offset) = I915_READ(offset);
I915_WRITE(offset, gen9_render_mocs[ring_id][i]);

Thanks for pointing this out, it's a mistake during our code preparation for 
upstream.
I'll queue this up.

>  drivers/gpu/drm/i915/gvt/render.c | 25 +++--
>  1 file changed, 3 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/render.c 
> b/drivers/gpu/drm/i915/gvt/render.c
> index feebb65ba641..79e112288065 100644
> --- a/drivers/gpu/drm/i915/gvt/render.c
> +++ b/drivers/gpu/drm/i915/gvt/render.c
> @@ -147,29 +147,20 @@ static void load_mocs(struct intel_vgpu *vgpu, int 
> ring_id)
>  {
>   struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
>   i915_reg_t offset, l3_offset;
> - u32 regs[] = {
> - [RCS] = 0xc800,
> - [VCS] = 0xc900,
> - [VCS2] = 0xca00,
> - [BCS] = 0xcc00,
> - [VECS] = 0xcb00,
> - };
>   int i;
>  
> - if (WARN_ON(ring_id >= ARRAY_SIZE(regs)))
> - return;
> -
>   if (!IS_SKYLAKE(dev_priv))
>   return;
>  
>   for (i = 0; i < 64; i++) {
> + offset.reg = i * 4;
>   gen9_render_mocs[ring_id][i] = I915_READ(offset);
>   I915_WRITE(offset, vgpu_vreg(vgpu, offset));
>   POSTING_READ(offset);
> - offset.reg += 4;
>   }
>  
>   if (ring_id == RCS) {
> + offset.reg = 64 * 4;
>   l3_offset.reg = 0xb020;
>   for (i = 0; i < 32; i++) {
>   gen9_render_mocs_L3[i] = I915_READ(l3_offset);
> @@ -184,26 +175,16 @@ static void restore_mocs(struct intel_vgpu *vgpu, int 
> ring_id)
>  {
>   struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
>   i915_reg_t offset, l3_offset;
> - u32 regs[] = {
> - [RCS] = 0xc800,
> - [VCS] = 0xc900,
> - [VCS2] = 0xca00,
> - [BCS] = 0xcc00,
> - [VECS] = 0xcb00,
> - };
>   int i;
>  
> - if (WARN_ON(ring_id >= ARRAY_SIZE(regs)))
> - return;
> -
>   if (!IS_SKYLAKE(dev_priv))
>   return;
>  
>   for (i = 0; i < 64; i++) {
> + offset.reg = i * 4;
>   vgpu_vreg(vgpu, offset) = I915_READ(offset);
>   I915_WRITE(offset, gen9_render_mocs[ring_id][i]);
>   POSTING_READ(offset);
> - offset.reg += 4;
>   }
>  
>   if (ring_id == RCS) {
> -- 
> 2.9.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: add ACPI and 64BIT dependencies

[Zhenyu Wang]

On 2016.10.21 17:25:49 +0200, Arnd Bergmann wrote:
> The newly added gvt code produces lots of serious warnings and errors
> when either built on 32-bit x86, or built with ACPI disabled, e.g.
> 
> drivers/gpu/drm/i915/gvt/gtt.c: In function ???read_pte64???:
> drivers/gpu/drm/i915/gvt/gtt.c:277:2: error: left shift count >= width of 
> type [-Werror]
> drivers/gpu/drm/i915/gvt/gtt.c: In function ???gen8_gtt_get_pfn???:
> drivers/gpu/drm/i915/gvt/gtt.c:360:3: error: left shift count >= width of 
> type [-Werror]
> drivers/gpu/drm/i915/gvt/opregion.c: In function 
> ???intel_gvt_init_opregion???:
> drivers/gpu/drm/i915/gvt/opregion.c:183:2: error: implicit declaration of 
> function ???acpi_os_ioremap??? [-Werror=implicit-function-declaration]
> 
> This avoids the problems by simply disallowing those configurations
> in Kconfig. I'm sure it's possible to make the code more portable
> and support building GVT without those options, but it might not be
> useful to do so.
> 
> Fixes: 4d60c5fd3f87 ("drm/i915/gvt: vGPU PCI configuration space 
> virtualization")
> Signed-off-by: Arnd Bergmann 
> ---
> If the code is meant to work on 32-bit and non-ACPI kernels, please
> treat this as a bug report and disregard the patch.
> ---

Thanks, Arnd. We have to depend on 64bit now and not require for ACPI,
as we used one acpi function for opregion mem map which is not necessary,
so I queued one 64bit dependence and another to remove acpi dependence for 
Daniel.

>  drivers/gpu/drm/i915/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 6d4194288d11..1b9308284dde 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -84,6 +84,7 @@ config DRM_I915_USERPTR
>  config DRM_I915_GVT
>  bool "Enable Intel GVT-g graphics virtualization host support"
>  depends on DRM_I915
> + depends on 64BIT && ACPI
>  default n
>  help
> Choose this option if you want to enable Intel GVT-g graphics
> -- 
> 2.9.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] drm/i915/gvt: cleanup a type issue in submit_context()

[Zhenyu Wang]

On 2016.10.21 13:27:22 +0300, Dan Carpenter wrote:
> On Fri, Oct 21, 2016 at 04:27:38PM +0800, Zhenyu Wang wrote:
> > On 2016.10.21 11:06:01 +0300, Dan Carpenter wrote:
> > > submit_context() should return negative error codes and zero on success
> > > but by mistake we made it a bool.  I've changed it to int.  Also I made
> > > it static because this isn't referenced in any other files.
> > > 
> > > This doesn't affect runtime because the return is eventually propogated
> > > to elsp_mmio_write() where it is ignored.
> > > 
> > > Signed-off-by: Dan Carpenter 
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> > > b/drivers/gpu/drm/i915/gvt/execlist.c
> > > index c50a3d1a5131..bc69ba1842ea 100644
> > > --- a/drivers/gpu/drm/i915/gvt/execlist.c
> > > +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> > > @@ -616,7 +616,7 @@ static int prepare_mm(struct intel_vgpu_workload 
> > > *workload)
> > >   (list_empty(q) ? NULL : container_of(q->prev, \
> > >   struct intel_vgpu_workload, list))
> > >  
> > > -bool submit_context(struct intel_vgpu *vgpu, int ring_id,
> > > +static int submit_context(struct intel_vgpu *vgpu, int ring_id,
> > >   struct execlist_ctx_descriptor_format *desc,
> > >   bool emulate_schedule_in)
> > >  {
> > 
> > Dan, this has been fixed in our recent pull, should hit linux-next very 
> > soon.
> > 
> 
> Could you review elsp_mmio_write() as well?  Should we be doing
> something with that return value?
> 

yeah, ignore return value is not good, will fix that. Thanks!

Zhi, could you double check error path for elsp write?

-- 
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: cleanup a type issue in submit_context()

[Zhenyu Wang]

On 2016.10.21 11:06:01 +0300, Dan Carpenter wrote:
> submit_context() should return negative error codes and zero on success
> but by mistake we made it a bool.  I've changed it to int.  Also I made
> it static because this isn't referenced in any other files.
> 
> This doesn't affect runtime because the return is eventually propogated
> to elsp_mmio_write() where it is ignored.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> b/drivers/gpu/drm/i915/gvt/execlist.c
> index c50a3d1a5131..bc69ba1842ea 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.c
> +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> @@ -616,7 +616,7 @@ static int prepare_mm(struct intel_vgpu_workload 
> *workload)
>   (list_empty(q) ? NULL : container_of(q->prev, \
>   struct intel_vgpu_workload, list))
>  
> -bool submit_context(struct intel_vgpu *vgpu, int ring_id,
> +static int submit_context(struct intel_vgpu *vgpu, int ring_id,
>   struct execlist_ctx_descriptor_format *desc,
>   bool emulate_schedule_in)
>  {

Dan, this has been fixed in our recent pull, should hit linux-next very soon.

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] drm/i915: GVT-g driver depends on 64BIT kernel

[Zhenyu Wang]

On 2016.10.21 09:05:21 +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 12:38:59PM +0800, Zhenyu Wang wrote:
> > We currently don't support GVT-g driver on i386 kernel.
> > Add explicit dependence on 64bit kernel.
> 
> Can we at least get clean compilation on 32bit? That's the only limiting
> factor really...

ok, that would need more extra work, will double check later.

-- 
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-g fixes

[Zhenyu Wang]

Hi,

The following changes since commit 19e6393fb5366a89705a62b3276ce42e990d12ce:

  drm/i915/gvt: do not ignore return value of create_scratch_page (2016-10-20 
17:31:36 +0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-fix-2016-10-21

for you to fetch changes up to eec4277c4001649a4ef0a17403537567ff1a2fad:

  drm/i915: GVT-g driver depends on 64BIT kernel (2016-10-21 14:48:48 +0800)


gvt-next-fix-2016-10-21

- Fix build error when CONFIG_ACPI=n
- Add dependence for 64BIT kernel


Zhenyu Wang (2):
  drm/i915/gvt: Fix failure when ACPI is not enabled
  drm/i915: GVT-g driver depends on 64BIT kernel

 drivers/gpu/drm/i915/Kconfig| 1 +
 drivers/gpu/drm/i915/gvt/opregion.c | 6 +++---
 2 files changed, 4 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] [PATCH] drm/i915: GVT-g driver depends on 64BIT kernel

[Zhenyu Wang]

We currently don't support GVT-g driver on i386 kernel.
Add explicit dependence on 64bit kernel.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 6aedc96..c72b007 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -86,6 +86,7 @@ config DRM_I915_USERPTR
 config DRM_I915_GVT
 bool "Enable Intel GVT-g graphics virtualization host support"
 depends on DRM_I915
+depends on 64BIT
 default n
 help
  Choose this option if you want to enable Intel GVT-g graphics
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

[Zhenyu Wang]

On 2016.10.20 17:20:04 +0200, Arkadiusz Hiler wrote:
> On Thu, Oct 20, 2016 at 05:29:36PM +0300, Mika Kuoppala wrote:
> > Arkadiusz Hiler  writes:
> > 
> > > When invalidating RCS TLB the device can enter RC6 state interrupting
> > > the process, therefore the need for render forcewake for the whole
> > > procedure.
> > >
> > > This WA is needed for all production SKL SKUs.
> > >
> > > References: HSD#2136899, HSD#1404391274
> > > Cc: Mika Kuoppala 
> > > Cc: Zhenyu Wang 
> > > Signed-off-by: Arkadiusz Hiler 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/render.c | 11 +++
> > >  1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/render.c 
> > > b/drivers/gpu/drm/i915/gvt/render.c
> > > index f54ab85..f5000ea 100644
> > > --- a/drivers/gpu/drm/i915/gvt/render.c
> > > +++ b/drivers/gpu/drm/i915/gvt/render.c
> > > @@ -134,11 +134,22 @@ static void handle_tlb_pending_event(struct 
> > > intel_vgpu *vgpu, int ring_id)
> > >  
> > >   reg = _MMIO(regs[ring_id]);
> > >
> > 
> > Ok not so familiar with the gvt side but I assume this is the host
> > side code and thus the vgpu is not active at this stage.
> 
> That's my understanding as well. It's a code that is setting up gvt for
> further use (shadow context to be exact). It's called indirectly from
> intel_gvt_create_vgpu.
> 

yes, it's for host not for vgpu to handle context switch state for vgpu.

> > Then you could avoid some of the implicit fw dancing
> > by:
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/render.c 
> > b/drivers/gpu/drm/i915/gvt/render.c
> > index feebb65..93ba156 100644
> > --- a/drivers/gpu/drm/i915/gvt/render.c
> > +++ b/drivers/gpu/drm/i915/gvt/render.c
> > @@ -118,6 +118,7 @@ static u32 gen9_render_mocs_L3[32];
> >  static void handle_tlb_pending_event(struct intel_vgpu *vgpu, int ring_id)
> >  {
> > struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
> > +   enum forcewake_domains fw;
> > i915_reg_t reg;
> > u32 regs[] = {
> > [RCS] = 0x4260,
> > @@ -135,11 +136,21 @@ static void handle_tlb_pending_event(struct 
> > intel_vgpu *vgpu, int ring_id)
> >  
> > reg = _MMIO(regs[ring_id]);
> >  
> > -   I915_WRITE(reg, 0x1);
> > +   fw = intel_uncore_forcewake_for_reg(dev_priv, reg,
> > +   FW_REG_READ | FW_REG_WRITE);
> >  
> > -   if (wait_for_atomic((I915_READ(reg) == 0), 50))
> > +   if (ring_id == RCS && IS_SKYLAKE(dev_priv))
> > +   fw |= FORCEWAKE_RENDER;
> > +
> > +   intel_uncore_forcewake_get(dev_priv, fw);
> > +
> > +   I915_WRITE_FW(reg, 0x1);
> > +
> > +   if (wait_for_atomic((I915_READ_FW(reg) == 0), 50))
> > gvt_err("timeout in invalidate ring (%d) tlb\n", ring_id);
> >  
> > +   intel_uncore_forcewake_put(dev_priv, fw);
> > +
> > 
> 
> I can go with it, although I do not have strong preference. I think my
> version is a little bit easier to follow, but his is less error prone,
> as you check for the WA SKU only once, during setting the FW.
> 
> Any recommendations?
> 

I like this one to be safer. Would Mika like to send another one or I
just take your commit message?

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] linux-next: Tree for Oct 20 (gpu/drm/i915)

[Zhenyu Wang]

On 2016.10.20 21:25:03 +0300, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Daniel Vetter  wrote:
> > On Thu, Oct 20, 2016 at 7:37 PM, Randy Dunlap  wrote:
> >> On 10/19/16 20:20, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20161019:
> >>>
> >>
> >> on i386: when CONFIG_ACPI is not enabled:
> >
> > Adding Zhenyu. Might be good to have a fix just for this that I
> > directly pick up, since I want to tag the first 4.10 pull for Dave
> > Airlie this w/e.
> 
> How about just this?
>

I'd like to not depend on acpi function any more, so just change that
for memremap. GVT-g driver currently only supports 64BIT kernel so will
fix that dependence. I'll send fix pull for Daniel later.

thanks

> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 6aedc96aa412..94914381e8ef 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -85,7 +85,7 @@ config DRM_I915_USERPTR
>  
>  config DRM_I915_GVT
>  bool "Enable Intel GVT-g graphics virtualization host support"
> -depends on DRM_I915
> +depends on DRM_I915 && ACPI
>  default n
>  help
> Choose this option if you want to enable Intel GVT-g graphics
> 
> 
> 
> > -Daniel
> >
> >> ../drivers/gpu/drm/i915/gvt/opregion.c: In function 
> >> 'intel_gvt_init_opregion':
> >> ../drivers/gpu/drm/i915/gvt/opregion.c:183:2: error: implicit declaration 
> >> of function 'acpi_os_ioremap' [-Werror=implicit-function-declaration]
> >>   gvt->opregion.opregion_va = acpi_os_ioremap(gvt->opregion.opregion_pa,
> >>   ^
> >> ../drivers/gpu/drm/i915/gvt/opregion.c:183:28: warning: assignment makes 
> >> pointer from integer without a cast [enabled by default]
> >>   gvt->opregion.opregion_va = acpi_os_ioremap(gvt->opregion.opregion_pa,
> >> ^
> >> ../drivers/gpu/drm/i915/gvt/gtt.c: In function 'read_pte64':
> >> ../drivers/gpu/drm/i915/gvt/gtt.c:277:2: warning: left shift count >= 
> >> width of type [enabled by default]
> >>   pte |= ioread32(addr + 4) << 32;
> >>   ^
> >> ../drivers/gpu/drm/i915/gvt/gtt.c: In function 'gen8_gtt_get_pfn':
> >> ../drivers/gpu/drm/i915/gvt/gtt.c:360:3: warning: left shift count >= 
> >> width of type [enabled by default]
> >>pfn = (e->val64 & ADDR_4K_MASK) >> 12;
> >>^
> >> ../drivers/gpu/drm/i915/gvt/gtt.c: In function 'gen8_gtt_set_pfn':
> >> ../drivers/gpu/drm/i915/gvt/gtt.c:373:3: warning: left shift count >= 
> >> width of type [enabled by default]
> >>e->val64 &= ~ADDR_4K_MASK;
> >>^
> >> ../drivers/gpu/drm/i915/gvt/gtt.c:374:3: warning: left shift count >= 
> >> width of type [enabled by default]
> >>pfn &= (ADDR_4K_MASK >> 12);
> >>^
> >> ../drivers/gpu/drm/i915/gvt/gtt.c: In function 'gen8_gma_to_pml4_index':
> >> ../drivers/gpu/drm/i915/gvt/gtt.c:436:1: warning: right shift count >= 
> >> width of type [enabled by default]
> >>  DEFINE_PPGTT_GMA_TO_INDEX(gen8, pml4, (gma >> 39 & 0x1ff));
> >>  ^
> >>   CC  drivers/gpu/drm/radeon/si_smc.o
> >> In file included from ../drivers/gpu/drm/i915/i915_drv.h:46:0,
> >>  from ../drivers/gpu/drm/i915/gvt/gtt.c:36:
> >> ../drivers/gpu/drm/i915/gvt/gtt.c: In function 
> >> 'intel_gvt_create_scratch_page':
> >> ../drivers/gpu/drm/i915/gvt/gtt.c:1945:47: warning: cast from pointer to 
> >> integer of different size [-Wpointer-to-int-cast]
> >>gvt_err("fail to translate vaddr:0x%llx\n", (u64)vaddr);
> >>^
> >> ../include/drm/drmP.h:201:43: note: in definition of macro 'DRM_ERROR'
> >>   drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
> >>^
> >> ../drivers/gpu/drm/i915/gvt/gtt.c:1945:3: note: in expansion of macro 
> >> 'gvt_err'
> >>gvt_err("fail to translate vaddr:0x%llx\n", (u64)vaddr);
> >>^
> >>
> >>
> >>
> >> --
> >> ~Randy
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> 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

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

[Zhenyu Wang]

On 2016.10.20 11:01:02 +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 05:42:37PM +0800, Zhenyu Wang wrote:
> > On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote:
> > > On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
> > > > 
> > > > We need to formalize the process between i915 proper and GVT-g a bit
> > > > more, and address some of the current shortcomings and issues in the
> > > > process and GVT-g CI.
> > > > 
> > > > This started off internally as a random list of items, I'm including
> > > > some of the current status as well. Please comment, as some of the stuff
> > > > here are just my opinions.
> > > > 
> > > > * How do we ensure GVT-g patches get the same kind of pre-merge CI
> > > >   coverage as we have for other i915 code? Could we at least make CI run
> > > >   tests on GVT-g pull requests before merging to drm-intel trees?
> > > > 
> > > >   => Work in progress to set up GVT-g CI.
> > > 
> > > Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want
> > > to do that then it's fine, but otherwise I'm leaning towards treating gvt
> > > like a sub-driver, with its own flavour of testing and review standards.
> > >
> > 
> > Normally GVT-g shouldn't impact drm-intel CI. I do like to setup GVT-g 
> > specific
> > CI with fancy multiple VMs auto test available. But it might need some time
> > for QA team to setup that way.
> 
> The problem is that gvt is a consumer of our APIs. When I change those I
> need reassurance that gvt does not break. We also need reassurance that
> when we backmerge from upstream changes to the hva do not break gvt.

yeah, I think that's also a requirement for GVT-g CI. Another side is
similiar nightly branch for gvt will be created to grab drm-intel,
gvt, vfio, kvm and future xen trees to do regression testing and with
more full testings. I hope some part of GVT-g CI could also be put in
drm-intel CI and other part is for GVT-g testing itself e.g VM
related features, etc.

-- 
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-g device model core fixes

[Zhenyu Wang]

Hi,

This is second pull request for GVT-g sub module which contains
fixes for issues within first pull request.

Regression test has been passed combining this new pull request
with unmerged driver facilities to test for VMs.

Thanks.

--
The following changes since commit 1140f9ed051011e06a2a15c73efe57ac0b0cdc8d:

  drm/i915/gvt: Fix build failure after intel_engine_cs change (2016-10-18 
08:24:49 +0200)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-fix-2016-10-20

for you to fetch changes up to 19e6393fb5366a89705a62b3276ce42e990d12ce:

  drm/i915/gvt: do not ignore return value of create_scratch_page (2016-10-20 
17:31:36 +0800)


gvt-next-fix-2016-10-20

This contains fix for first pull request.
- clean up header mess between i915 core and gvt
- new MAINTAINERS item
- new kernel-doc section
- fix compiling warnings
- gvt gem fix series from Chris
- fix for i915 intel_engine_cs change
- some sparse fixes from Changbin


Chris Wilson (10):
  drm/i915/gvt: Add runtime pm around fences
  drm/i915/gvt: i915_gem_object_create() returns an error pointer
  drm/i915/gvt: Use the returned VMA to provide the virtual address
  drm/i915/gvt: Remove dangerous unpin of backing storage of bound GPU 
object
  drm/i915/gvt: Hold a reference on the request
  drm/i915/gvt: Stop checking for impossible interrupts from a kthread
  drm/i915/gvt: Stop waiting whilst holding struct_mutex
  drm/i915/gvt: Use common mapping routines for indirect_ctx object
  drm/i915/gvt: Use common mapping routines for shadow_bb object
  drm/i915/gvt: Remove defunct vmap_batch()

Du, Changbin (4):
  drm/i915/gvt: fix sparse warnings on different address spaces
  drm/i915/gvt: mark symbols static where possible
  drm/i915/gvt: fix spare warnings on odd constant _Bool cast
  drm/i915/gvt: do not ignore return value of create_scratch_page

Zhenyu Wang (5):
  drm/i915/gvt: clean up intel_gvt.h as interface for i915 core
  MAINTAINERS: Add new Intel GVT-g driver maintainer
  drm/i915/gvt: Fix warning on obsolete function usage
  Documentation/gpu: Add section for Intel GVT-g host support
  drm/i915/gvt: properly access enabled intel_engine_cs

 Documentation/gpu/i915.rst  |   9 +++
 MAINTAINERS |  10 +++
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  11 +++
 drivers/gpu/drm/i915/gvt/cfg_space.c|   1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   | 135 +++-
 drivers/gpu/drm/i915/gvt/display.c  |   3 +-
 drivers/gpu/drm/i915/gvt/edid.c |   1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  48 +++-
 drivers/gpu/drm/i915/gvt/firmware.c |  10 ++-
 drivers/gpu/drm/i915/gvt/gtt.c  |  15 ++--
 drivers/gpu/drm/i915/gvt/gvt.c  |  19 +++--
 drivers/gpu/drm/i915/gvt/gvt.h  |   9 ++-
 drivers/gpu/drm/i915/gvt/handlers.c |  13 +--
 drivers/gpu/drm/i915/gvt/interrupt.c|   3 +-
 drivers/gpu/drm/i915/gvt/mmio.c |   1 +
 drivers/gpu/drm/i915/gvt/opregion.c |   3 +-
 drivers/gpu/drm/i915/gvt/render.c   |   1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  15 ++--
 drivers/gpu/drm/i915/gvt/scheduler.c|  62 ---
 drivers/gpu/drm/i915/gvt/vgpu.c |   2 +
 drivers/gpu/drm/i915/i915_drv.h |   4 +-
 drivers/gpu/drm/i915/intel_gvt.c|   8 +-
 drivers/gpu/drm/i915/intel_gvt.h|   3 +-
 23 files changed, 208 insertions(+), 178 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] i915 and GTV-g maintenance, workflows and CI

[Zhenyu Wang]

On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote:
> On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
> > 
> > We need to formalize the process between i915 proper and GVT-g a bit
> > more, and address some of the current shortcomings and issues in the
> > process and GVT-g CI.
> > 
> > This started off internally as a random list of items, I'm including
> > some of the current status as well. Please comment, as some of the stuff
> > here are just my opinions.
> > 
> > * How do we ensure GVT-g patches get the same kind of pre-merge CI
> >   coverage as we have for other i915 code? Could we at least make CI run
> >   tests on GVT-g pull requests before merging to drm-intel trees?
> > 
> >   => Work in progress to set up GVT-g CI.
> 
> Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want
> to do that then it's fine, but otherwise I'm leaning towards treating gvt
> like a sub-driver, with its own flavour of testing and review standards.
>

Normally GVT-g shouldn't impact drm-intel CI. I do like to setup GVT-g specific
CI with fancy multiple VMs auto test available. But it might need some time
for QA team to setup that way.

> Of course anything touching shared code (i.e. outside of the gvt/ subdir),
> or code which can't be disabled with Kconfig needs to follow our
> established review&testing procedures. So submission to intel-gfx, CI by
> patchwork, review per our standards.
> 
> > * How do we handle fixes to GVT-g code? Do all fixes need to go via the
> >   GVT-g mailing lists and review? We're bound to get GVT-g patches on
> >   intel-gfx mailing list too. There's confusion already [1]. Mostly the
> >   GVT-g changes come from GVT-g maintainers as pull requests.
> > 
> >   [1] https://patchwork.freedesktop.org/series/14000/
> 
> Atm the gvt mailing list is closed, and there's no maintainer entry for it
> either. I think Zhenyu just needs to hang out here on intel-gfx to catch
> these, and then pick any gvt/ fixes up himself.
>

We're working with 01.org admin to fix that ASAP. I didn't realize
01.org list has such issue, just thought we have aligned user/dev
igvt-g list on same place, otherwise I'd have considered other way..
But yes, we will still include intel-gfx list in maintainer file and
keep eye on it.

> > * GVT-g related changes to i915 proper must be reviewed on intel-gfx
> >   mailing list, and must either be applied to drm-intel directly, or get
> >   an ack to be merged via GVT-g tree and pull requests.
> 
> Ack.

Agreed.

> 
> > * GVT-g needs to start annotating fixes with the Fixes: tags, preferably
> >   also cc: stable when we get that far, so our fixes plumbing can figure
> >   out which commits to backport.
> > 
> >   => GVT-g maintainers will take care of this.
> 
> Either that, or they need to send -fixes pull requests your way. I think
> we could try out either approach, but yes in the end gvt maintainers need
> to own this. We (i915 team here) won't take care of that.
>

yeah, I think we should follow that way.

> > * Should GVT-g have a MAINTAINERS entry of its own?
> > 
> >   => 
> > https://github.com/01org/gvt-linux/commit/41161c9e9e50a5bad98a0e74ad0878c352bdea40
> > 
> > +INTEL GVT-g DRIVERS (Intel GPU Virtualization)
> > +M:  Zhenyu Wang 
> > +M:  Zhi Wang 
> > +L:  igvt-g-...@lists.01.org
> 
> Need to make sure igvt-g-dev is open to non-subscribers first. Otherwise
> ack.

fixing...

> 
> > +L:  intel-gfx@lists.freedesktop.org
> > +W:  https://01.org/igvt-g
> > +T:  git https://github.com/01org/gvt-linux.git
> > +S:  Supported
> > +F:  drivers/gpu/drm/i915/gvt/
> > 
> >   I think we'll want to keep intel-gfx there, but mostly I think it's
> >   fine for the usual GVT-g development to happen on igvt-g-dev only.
> 
> +1
> 
> > * igvt-g-...@lists.01.org needs to start accepting mails from
> >   non-subscribers.
> > 
> >   => Work in progress.
> 
> Definitely ;-)
> 
> > * GVT-g needs to start paying more attention to compiler and sparse
> >   warnings.
> > 
> >   => GVT-G maintainers will take care of this.
> > 
> > * GVT-g could use some overview documentation under Documentation/gpu.
> 
> Hm, should we have a TODO file in gvt for some of the issues raised? Otoh
> most things are fairly small issues, so should all be fixable before 4.10
> freeze.

Next big merge will be integration work with VFIO/mdev framework. Both VFIO/mdev
and our GVT-g devic

[Intel-gfx] [PATCH v3] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

i915 core should only call functions and structures exposed through
intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h.

Change for internal intel_gvt structure as private handler which
not requires to expose gvt internal structure for i915 core.

v2: Fix per Chris's comment
- carefully handle dev_priv->gvt assignment
- add necessary bracket for macro helper
- forward declartion struct intel_gvt
- keep free operation within same file handling alloc

v3: fix use after free and remove intel_gvt.initialized

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  1 +
 drivers/gpu/drm/i915/gvt/cfg_space.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  2 ++
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  1 +
 drivers/gpu/drm/i915/gvt/firmware.c |  2 ++
 drivers/gpu/drm/i915/gvt/gtt.c  |  2 ++
 drivers/gpu/drm/i915/gvt/gvt.c  | 19 +--
 drivers/gpu/drm/i915/gvt/gvt.h  |  4 ++--
 drivers/gpu/drm/i915/gvt/handlers.c |  2 ++
 drivers/gpu/drm/i915/gvt/interrupt.c|  1 +
 drivers/gpu/drm/i915/gvt/mmio.c |  1 +
 drivers/gpu/drm/i915/gvt/opregion.c |  1 +
 drivers/gpu/drm/i915/gvt/render.c   |  1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  1 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +++--
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_gvt.h|  3 +--
 20 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f8..db503c1 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -35,6 +35,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define MB_TO_BYTES(mb) ((mb) << 20ULL)
 #define BYTES_TO_MB(b) ((b) >> 20ULL)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 16360e4..4c68774 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -32,6 +32,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 enum {
INTEL_GVT_PCI_BAR_GTTMMIO = 0,
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..5b4658f 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -36,6 +36,8 @@
 
 #include 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 #define INVALID_OP(~0U)
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 534000b..d8908d4 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 static int get_edp_pipe(struct intel_vgpu *vgpu)
 {
diff --git a/drivers/gpu/drm/i915/gvt/edid.c b/drivers/gpu/drm/i915/gvt/edid.c
index a07e427..7e1da1c 100644
--- a/drivers/gpu/drm/i915/gvt/edid.c
+++ b/drivers/gpu/drm/i915/gvt/edid.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define GMBUS1_TOTAL_BYTES_SHIFT 16
 #define GMBUS1_TOTAL_BYTES_MASK 0x1ff
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index c50a3d1..b87b4f5 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define _EL_OFFSET_STATUS   0x234
 #define _EL_OFFSET_STATUS_BUF   0x370
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 4578a4d..d068a52 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -32,6 +32,8 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 
 #define FIRMWARE_VERSION (0x0)
 
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 29de179..0722d1e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -34,6 +34,8 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 static bool enable_out_of_sync = false;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index e72e26c..31b59d4 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -35,6 +35,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 struct intel_gvt_host intel_gvt_host;
 
@@ -173,9 +174,9 @@ static int init_service_thread(struct intel_gvt *gvt)
  */
 void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
 {
- 

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

On 2016.10.20 09:12:02 +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 04:02:39PM +0800, Zhenyu Wang wrote:
> >  void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
> >  {
> > -   struct intel_gvt *gvt = &dev_priv->gvt;
> > +   struct intel_gvt *gvt = to_gvt(dev_priv);
> >  
> > if (WARN_ON(!gvt->initialized))
> > return;
> > @@ -188,6 +189,8 @@ void intel_gvt_clean_device(struct drm_i915_private 
> > *dev_priv)
> > intel_gvt_clean_mmio_info(gvt);
> > intel_gvt_free_firmware(gvt);
> >  
> > +   kfree(dev_priv->gvt);
> > +   dev_priv->gvt = NULL;
> > gvt->initialized = false;
> >  }
> 
> Whoops. First a NULL pointer deref then a use-after-free before coffee.
> I need coffee!
> 
> Just remove struct intel_gvt.initialized, it is leading you astray.

oops! sorry about 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

[Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

i915 core should only call functions and structures exposed through
intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h.

Change for internal intel_gvt structure as private handler which
not requires to expose gvt internal structure for i915 core.

v2: Fix per Chris's comment
- carefully handle dev_priv->gvt assignment
- add necessary bracket for macro helper
- forward declartion struct intel_gvt
- keep free operation within same file handling alloc

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  1 +
 drivers/gpu/drm/i915/gvt/cfg_space.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  2 ++
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  1 +
 drivers/gpu/drm/i915/gvt/firmware.c |  2 ++
 drivers/gpu/drm/i915/gvt/gtt.c  |  2 ++
 drivers/gpu/drm/i915/gvt/gvt.c  | 15 ---
 drivers/gpu/drm/i915/gvt/gvt.h  |  2 ++
 drivers/gpu/drm/i915/gvt/handlers.c |  2 ++
 drivers/gpu/drm/i915/gvt/interrupt.c|  1 +
 drivers/gpu/drm/i915/gvt/mmio.c |  1 +
 drivers/gpu/drm/i915/gvt/opregion.c |  1 +
 drivers/gpu/drm/i915/gvt/render.c   |  1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  1 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +++--
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_gvt.h|  3 +--
 20 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f8..db503c1 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -35,6 +35,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define MB_TO_BYTES(mb) ((mb) << 20ULL)
 #define BYTES_TO_MB(b) ((b) >> 20ULL)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 16360e4..4c68774 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -32,6 +32,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 enum {
INTEL_GVT_PCI_BAR_GTTMMIO = 0,
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..5b4658f 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -36,6 +36,8 @@
 
 #include 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 #define INVALID_OP(~0U)
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 534000b..d8908d4 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 static int get_edp_pipe(struct intel_vgpu *vgpu)
 {
diff --git a/drivers/gpu/drm/i915/gvt/edid.c b/drivers/gpu/drm/i915/gvt/edid.c
index a07e427..7e1da1c 100644
--- a/drivers/gpu/drm/i915/gvt/edid.c
+++ b/drivers/gpu/drm/i915/gvt/edid.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define GMBUS1_TOTAL_BYTES_SHIFT 16
 #define GMBUS1_TOTAL_BYTES_MASK 0x1ff
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index c50a3d1..b87b4f5 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define _EL_OFFSET_STATUS   0x234
 #define _EL_OFFSET_STATUS_BUF   0x370
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 4578a4d..d068a52 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -32,6 +32,8 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 
 #define FIRMWARE_VERSION (0x0)
 
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 29de179..0722d1e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -34,6 +34,8 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 static bool enable_out_of_sync = false;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index e72e26c..aee5ceb 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -35,6 +35,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 struct intel_gvt_host intel_gvt_host;
 
@@ -173,7 +174,7 @@ static int init_service_thread(struct intel_gvt *gvt)
  */
 void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
 {
-   struct intel_gvt *gvt = &am

Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

[Zhenyu Wang]

On 2016.10.20 07:52:18 +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 08:22:00AM +0800, Zhenyu Wang wrote:
> > On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> > > The workload took a pointer to the request, and even waited upon,
> > > without holding a reference on the request. Take that reference
> > > explicitly and fix up the error path following request allocation that
> > > missed flushing the request.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
> > >  1 file changed, 13 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> > > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > index b15cdf5978a9..224f19ae61ab 100644
> > > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > @@ -163,6 +163,7 @@ static int dispatch_workload(struct 
> > > intel_vgpu_workload *workload)
> > >   int ring_id = workload->ring_id;
> > >   struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
> > >   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> > > + struct drm_i915_gem_request *rq;
> > >   int ret;
> > >  
> > >   gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> > > @@ -171,17 +172,16 @@ static int dispatch_workload(struct 
> > > intel_vgpu_workload *workload)
> > >   shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
> > >   GEN8_CTX_ADDRESSING_MODE_SHIFT;
> > >  
> > > - workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> > > -shadow_ctx);
> > > - if (IS_ERR_OR_NULL(workload->req)) {
> > > + rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> > > + if (IS_ERR(rq)) {
> > >   gvt_err("fail to allocate gem request\n");
> > > - workload->status = PTR_ERR(workload->req);
> > > - workload->req = NULL;
> > > + workload->status = PTR_ERR(rq);
> > >   return workload->status;
> > >   }
> > >  
> > > - gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> > > - ring_id, workload->req);
> > > + gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> > > +
> > > + workload->req = i915_gem_request_get(rq);
> > >  
> > >   mutex_lock(&gvt->lock);
> > >  
> > > @@ -208,16 +208,16 @@ static int dispatch_workload(struct 
> > > intel_vgpu_workload *workload)
> > >   gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
> > >   ring_id, workload->req);
> > >  
> > > - i915_add_request_no_flush(workload->req);
> > > -
> > > + i915_add_request_no_flush(rq);
> > >   workload->dispatched = true;
> > >   return 0;
> > >  err:
> > >   workload->status = ret;
> > > - if (workload->req)
> > > - workload->req = NULL;
> > > + i915_gem_request_put(fetch_and_zero(&workload->req));
> > >
> > 
> > Looks we don't need put here as in error path from dispatch_workload()
> > we will go with below put path too in main thread.
> 
> If we clear the request pointer, then we need the put. But yes, we don't
> necessarily need to clear the pointer on error for the caller, as the
> caller doesn't distinguish the error path and the no-op request can be
> handled identically to a real request.

Would you refresh this one? So I'd send out next pull request with 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] [PATCH] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

i915 core should only call functions and structures exposed through
intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h.

Change for internal intel_gvt structure as private handler which
not requires to expose gvt internal structure for i915 core.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  1 +
 drivers/gpu/drm/i915/gvt/cfg_space.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  2 ++
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  1 +
 drivers/gpu/drm/i915/gvt/firmware.c |  2 ++
 drivers/gpu/drm/i915/gvt/gtt.c  |  2 ++
 drivers/gpu/drm/i915/gvt/gvt.c  | 14 +++---
 drivers/gpu/drm/i915/gvt/gvt.h  |  2 ++
 drivers/gpu/drm/i915/gvt/handlers.c |  2 ++
 drivers/gpu/drm/i915/gvt/interrupt.c|  1 +
 drivers/gpu/drm/i915/gvt/mmio.c |  1 +
 drivers/gpu/drm/i915/gvt/opregion.c |  1 +
 drivers/gpu/drm/i915/gvt/render.c   |  1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  1 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +++--
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_gvt.c|  1 +
 drivers/gpu/drm/i915/intel_gvt.h|  3 ---
 21 files changed, 39 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f8..db503c1 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -35,6 +35,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define MB_TO_BYTES(mb) ((mb) << 20ULL)
 #define BYTES_TO_MB(b) ((b) >> 20ULL)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 16360e4..4c68774 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -32,6 +32,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 enum {
INTEL_GVT_PCI_BAR_GTTMMIO = 0,
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..5b4658f 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -36,6 +36,8 @@
 
 #include 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 #define INVALID_OP(~0U)
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 534000b..d8908d4 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 static int get_edp_pipe(struct intel_vgpu *vgpu)
 {
diff --git a/drivers/gpu/drm/i915/gvt/edid.c b/drivers/gpu/drm/i915/gvt/edid.c
index a07e427..7e1da1c 100644
--- a/drivers/gpu/drm/i915/gvt/edid.c
+++ b/drivers/gpu/drm/i915/gvt/edid.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define GMBUS1_TOTAL_BYTES_SHIFT 16
 #define GMBUS1_TOTAL_BYTES_MASK 0x1ff
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index c50a3d1..b87b4f5 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define _EL_OFFSET_STATUS   0x234
 #define _EL_OFFSET_STATUS_BUF   0x370
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 4578a4d..d068a52 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -32,6 +32,8 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 
 #define FIRMWARE_VERSION (0x0)
 
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 29de179..0722d1e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -34,6 +34,8 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 static bool enable_out_of_sync = false;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index e72e26c..be9ccc8 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -35,6 +35,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 struct intel_gvt_host intel_gvt_host;
 
@@ -173,7 +174,7 @@ static int init_service_thread(struct intel_gvt *gvt)
  */
 void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
 {
-   struct intel_gvt *gvt = &dev_priv->gvt;
+   struct intel_gvt *gvt = to_gvt(dev_priv);
 
if (WARN_ON(!gvt->initialized))
return;
@@ -204,7 +205,7 @@ void intel_gvt_clean_device(struct dr

[Intel-gfx] [PATCH] Documentation/gpu: Add section for Intel GVT-g host support

[Zhenyu Wang]

Update with brief overview and reference for more detailed
arch design documents.

Add new section for Intel GVT-g host support.

Signed-off-by: Zhenyu Wang 
---
 Documentation/gpu/i915.rst   | 9 +
 drivers/gpu/drm/i915/intel_gvt.c | 8 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 87aaffc..95ce77f 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -49,6 +49,15 @@ Intel GVT-g Guest Support(vGPU)
 .. kernel-doc:: drivers/gpu/drm/i915/i915_vgpu.c
:internal:
 
+Intel GVT-g Host Support(vGPU device model)
+---
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
+   :doc: Intel GVT-g host support
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
+   :internal:
+
 Display Hardware Handling
 =
 
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index bae1a7d..88126b6 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -31,8 +31,12 @@
  * GPU among multiple virtual machines on a time-sharing basis. Each
  * virtual machine is presented a virtual GPU (vGPU), which has equivalent
  * features as the underlying physical GPU (pGPU), so i915 driver can run
- * seamlessly in a virtual machine. This file provides the englightments
- * of GVT and the necessary components used by GVT in i915 driver.
+ * seamlessly in a virtual machine.
+ *
+ * To virtualize GPU resources GVT-g driver depends on hypervisor technology
+ * e.g KVM/VFIO/mdev, Xen, etc. to provide resource access trapping capability
+ * and be virtualized within GVT-g device module. More architectural design
+ * doc is available on https://01.org/group/2230/documentation-list.
  */
 
 static bool is_supported_device(struct drm_i915_private *dev_priv)
-- 
2.9.3

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

Re: [Intel-gfx] gvt gem fixes

[Zhenyu Wang]

On 2016.10.20 09:02:45 +0200, Daniel Vetter wrote:
> Yeah, I think anything that touches i915 code should get merged through
> drm-intel directly with the usual process. Only exception is when gvt has
> a functional depency and it's a small patch, then I think we can sometimes
> merge i915 core patches through gvt, with an ack from Jani or me (and
> still proper review and CI and everything ofc). But that should be the
> rare exception.

That's fair enough for me. One prepared change is to fix gvt header
issue you've listed. As it touches intel_gvt.h in i915, I'll send that
seperately first 
(https://github.com/01org/gvt-linux/commit/b6a1ca7571ae45186394e555dc420481c1a9dba5)

-- 
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] gvt gem fixes

[Zhenyu Wang]

On 2016.10.19 12:02:58 +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote:
> > On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> > > I think this is the set required to bring gvt into line, at least to
> > > unblock myself.
> > 
> > Thanks a lot, Chris. I'd like to merge this in next pull request,
> > or let me know you want to be picked up by drm-intel directly.
> > If 4/12 would be picked up alone, I'll skip that one in gvt tree.
> 
> If you are confident in having the pull ready in the next day or so,
> I'll just preface my series with these and they will evaporate after the
> merge.
>

I'll try to send it today.

> I'll apply 4/12 right now to get that out of the way.

ok, fine.

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 07/12] drm/i915/gvt: Hold a reference on the request

[Zhenyu Wang]

On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> The workload took a pointer to the request, and even waited upon,
> without holding a reference on the request. Take that reference
> explicitly and fix up the error path following request allocation that
> missed flushing the request.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index b15cdf5978a9..224f19ae61ab 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -163,6 +163,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   int ring_id = workload->ring_id;
>   struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
>   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> + struct drm_i915_gem_request *rq;
>   int ret;
>  
>   gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> @@ -171,17 +172,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
>   GEN8_CTX_ADDRESSING_MODE_SHIFT;
>  
> - workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> -shadow_ctx);
> - if (IS_ERR_OR_NULL(workload->req)) {
> + rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> + if (IS_ERR(rq)) {
>   gvt_err("fail to allocate gem request\n");
> - workload->status = PTR_ERR(workload->req);
> - workload->req = NULL;
> + workload->status = PTR_ERR(rq);
>   return workload->status;
>   }
>  
> - gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> - ring_id, workload->req);
> + gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> +
> + workload->req = i915_gem_request_get(rq);
>  
>   mutex_lock(&gvt->lock);
>  
> @@ -208,16 +208,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
>   ring_id, workload->req);
>  
> - i915_add_request_no_flush(workload->req);
> -
> + i915_add_request_no_flush(rq);
>   workload->dispatched = true;
>   return 0;
>  err:
>   workload->status = ret;
> - if (workload->req)
> - workload->req = NULL;
> + i915_gem_request_put(fetch_and_zero(&workload->req));
>

Looks we don't need put here as in error path from dispatch_workload()
we will go with below put path too in main thread.

>   mutex_unlock(&gvt->lock);
> +
> + i915_add_request_no_flush(rq);
>   return ret;
>  }
>  
> @@ -458,6 +458,8 @@ static int workload_thread(void *priv)
>  
>   complete_current_workload(gvt, ring_id);
>  
> + i915_gem_request_put(fetch_and_zero(&workload->req));
> +
>   if (need_force_wake)
>   intel_uncore_forcewake_put(gvt->dev_priv,
>   FORCEWAKE_ALL);


-- 
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 -next] drm/i915/gvt: fix return value check

[Zhenyu Wang]

On 2016.10.19 16:18:03 +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> In case of error, the function i915_gem_object_create() returns
> ERR_PTR() not NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun 

Hi, Yongjun, we've already had this fixed in our queue for next pull request,
will send very soon.

Thanks.

> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 5808ee7..6abb2a6 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -1640,8 +1640,8 @@ static int perform_bb_shadow(struct parser_exec_state 
> *s)
>  
>   entry_obj->obj = i915_gem_object_create(&(s->vgpu->gvt->dev_priv->drm),
>   round_up(bb_size, PAGE_SIZE));
> - if (entry_obj->obj == NULL)
> - return -ENOMEM;
> + if (IS_ERR(entry_obj->obj))
> + return PTR_ERR(entry_obj->obj);
>   entry_obj->len = bb_size;
>   INIT_LIST_HEAD(&entry_obj->list);
>  
> @@ -2712,8 +2712,8 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>  
>   wa_ctx->indirect_ctx.obj = i915_gem_object_create(dev,
>   round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
> - if (wa_ctx->indirect_ctx.obj == NULL)
> - return -ENOMEM;
> + if (IS_ERR(wa_ctx->indirect_ctx.obj))
> + return PTR_ERR(wa_ctx->indirect_ctx.obj);
>  
>   ret = i915_gem_object_get_pages(wa_ctx->indirect_ctx.obj);
>   if (ret)
> 

-- 
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] gvt gem fixes

[Zhenyu Wang]

On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> I think this is the set required to bring gvt into line, at least to
> unblock myself.

Thanks a lot, Chris. I'd like to merge this in next pull request,
or let me know you want to be picked up by drm-intel directly.
If 4/12 would be picked up alone, I'll skip that one in gvt tree.

-- 
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 07/12] drm/i915/gvt: Hold a reference on the request

[Zhenyu Wang]

On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> The workload took a pointer to the request, and even waited upon,
> without holding a reference on the request. Take that reference
> explicitly and fix up the error path following request allocation that
> missed flushing the request.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index b15cdf5978a9..224f19ae61ab 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -163,6 +163,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   int ring_id = workload->ring_id;
>   struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
>   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> + struct drm_i915_gem_request *rq;
>   int ret;
>  
>   gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> @@ -171,17 +172,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
>   GEN8_CTX_ADDRESSING_MODE_SHIFT;
>  
> - workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> -shadow_ctx);
> - if (IS_ERR_OR_NULL(workload->req)) {
> + rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> + if (IS_ERR(rq)) {
>   gvt_err("fail to allocate gem request\n");
> - workload->status = PTR_ERR(workload->req);
> - workload->req = NULL;
> + workload->status = PTR_ERR(rq);
>   return workload->status;
>   }
>  
> - gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> - ring_id, workload->req);
> + gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> +
> + workload->req = i915_gem_request_get(rq);
>  
>   mutex_lock(&gvt->lock);
>  
> @@ -208,16 +208,16 @@ static int dispatch_workload(struct intel_vgpu_workload 
> *workload)
>   gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
>   ring_id, workload->req);
>  
> - i915_add_request_no_flush(workload->req);
> -
> + i915_add_request_no_flush(rq);
>   workload->dispatched = true;
>   return 0;
>  err:
>   workload->status = ret;
> - if (workload->req)
> - workload->req = NULL;
> + i915_gem_request_put(fetch_and_zero(&workload->req));
>  
>   mutex_unlock(&gvt->lock);

Might not need to hold gvt->lock when put request?

> +
> + i915_add_request_no_flush(rq);

Why still add request in error path?

>   return ret;
>  }
>  
> @@ -458,6 +458,8 @@ static int workload_thread(void *priv)
>  
>   complete_current_workload(gvt, ring_id);
>  
> + i915_gem_request_put(fetch_and_zero(&workload->req));
> +
>   if (need_force_wake)
>   intel_uncore_forcewake_put(gvt->dev_priv,
>   FORCEWAKE_ALL);
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 10/12] drm/i915/gvt: Use common mapping routines for indirect_ctx object

[Zhenyu Wang]

On 2016.10.19 11:11:45 +0100, Chris Wilson wrote:
> We have the ability to map an object, so use it rather than opencode it
> badly.
> 
> Signed-off-by: Chris Wilson 

Planned to fix these mapping too, obviously not fast than you..

Reviewed-by: Zhenyu Wang 

> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c | 28 +---
>  drivers/gpu/drm/i915/gvt/execlist.c   |  2 +-
>  2 files changed, 10 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 464fc3c9935b..2b16609b 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -2715,7 +2715,7 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   unsigned long guest_gma = wa_ctx->indirect_ctx.guest_gma;
>   struct drm_i915_gem_object *obj;
>   int ret = 0;
> - void *dest = NULL;
> + void *map;
>  
>   obj = i915_gem_object_create(dev,
>roundup(ctx_size + CACHELINE_BYTES,
> @@ -2723,18 +2723,12 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   if (IS_ERR(obj))
>   return PTR_ERR(obj);
>  
> - ret = i915_gem_object_get_pages(obj);
> - if (ret)
> - goto put_obj;
> -
> - i915_gem_object_pin_pages(obj);
> -
>   /* get the va of the shadow batch buffer */
> - dest = (void *)vmap_batch(obj, 0, ctx_size + CACHELINE_BYTES);
> - if (!dest) {
> + map = i915_gem_object_pin_map(obj, I915_MAP_WB);
> + if (IS_ERR(map)) {
>   gvt_err("failed to vmap shadow indirect ctx\n");
> - ret = -ENOMEM;
> - goto unpin_src;
> + ret = PTR_ERR(map);
> + goto put_obj;
>   }
>  
>   ret = i915_gem_object_set_to_cpu_domain(obj, false);
> @@ -2743,25 +2737,21 @@ static int shadow_indirect_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   goto unmap_src;
>   }
>  
> - wa_ctx->indirect_ctx.shadow_va = dest;
> -
> - memset(dest, 0, round_up(ctx_size + CACHELINE_BYTES, PAGE_SIZE));
> -
>   ret = copy_gma_to_hva(wa_ctx->workload->vgpu,
>   wa_ctx->workload->vgpu->gtt.ggtt_mm,
> - guest_gma, guest_gma + ctx_size, dest);
> + guest_gma, guest_gma + ctx_size,
> + map);
>   if (ret) {
>   gvt_err("fail to copy guest indirect ctx\n");
>   goto unmap_src;
>   }
>  
>   wa_ctx->indirect_ctx.obj = obj;
> + wa_ctx->indirect_ctx.shadow_va = map;
>   return 0;
>  
>  unmap_src:
> - vunmap(dest);
> -unpin_src:
> - i915_gem_object_unpin_pages(wa_ctx->indirect_ctx.obj);
> + i915_gem_object_unpin_map(obj);
>  put_obj:
>   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
>   return ret;
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> b/drivers/gpu/drm/i915/gvt/execlist.c
> index b79d148a4e32..d8a6d6366899 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.c
> +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> @@ -517,8 +517,8 @@ static void release_shadow_wa_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   if (wa_ctx->indirect_ctx.size == 0)
>   return;
>  
> + i915_gem_object_unpin_map(wa_ctx->indirect_ctx.obj);
>   i915_gem_object_put(wa_ctx->indirect_ctx.obj);
> - kvfree(wa_ctx->indirect_ctx.shadow_va);
>  }
>  
>  static int complete_execlist_workload(struct intel_vgpu_workload *workload)
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 v2] drm/i915/gvt: Stop waiting whilst holding struct_mutex

[Zhenyu Wang]

On 2016.10.19 10:14:39 +0100, Chris Wilson wrote:
> For whatever reason, the gvt scheduler runs synchronously. At the very
> least, lets run synchronously without holding the struct_mutex.
> 
> v2: cut'n'paste mutex_lock instead of unlock.
> Replace long hold of struct_mutex with a mutex to serialise the worker
> threads.
> 
> Signed-off-by: Chris Wilson 

This looks ok to me, but let me test it with VM first to ensure
the behavior is expected.

Thanks

> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 4cedd3274da7..55f8ed7d7be5 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -390,6 +390,8 @@ struct workload_thread_param {
>   int ring_id;
>  };
>  
> +static DEFINE_MUTEX(scheduler_mutex);
> +
>  static int workload_thread(void *priv)
>  {
>   struct workload_thread_param *p = (struct workload_thread_param *)priv;
> @@ -414,17 +416,14 @@ static int workload_thread(void *priv)
>   if (kthread_should_stop())
>   break;
>  
> + mutex_lock(&scheduler_mutex);
> +
>   gvt_dbg_sched("ring id %d next workload %p vgpu %d\n",
>   workload->ring_id, workload,
>   workload->vgpu->id);
>  
>   intel_runtime_pm_get(gvt->dev_priv);
>  
> - /*
> -  * Always take i915 big lock first
> -  */
> - mutex_lock(&gvt->dev_priv->drm.struct_mutex);
> -
>   gvt_dbg_sched("ring id %d will dispatch workload %p\n",
>   workload->ring_id, workload);
>  
> @@ -432,7 +431,10 @@ static int workload_thread(void *priv)
>   intel_uncore_forcewake_get(gvt->dev_priv,
>   FORCEWAKE_ALL);
>  
> + mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>   ret = dispatch_workload(workload);
> + mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
> +
>   if (ret) {
>   gvt_err("fail to dispatch workload, skip\n");
>   goto complete;
> @@ -442,8 +444,7 @@ static int workload_thread(void *priv)
>   workload->ring_id, workload);
>  
>   workload->status = i915_wait_request(workload->req,
> -  I915_WAIT_LOCKED,
> -  NULL, NULL);
> +  0, NULL, NULL);
>   if (workload->status != 0)
>   gvt_err("fail to wait workload, skip\n");
>  
> @@ -451,15 +452,18 @@ static int workload_thread(void *priv)
>   gvt_dbg_sched("will complete workload %p\n, status: %d\n",
>   workload, workload->status);
>  
> + mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>   complete_current_workload(gvt, ring_id);
> + mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
>  
>   if (need_force_wake)
>   intel_uncore_forcewake_put(gvt->dev_priv,
>   FORCEWAKE_ALL);
>  
> - mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
> -
>   intel_runtime_pm_put(gvt->dev_priv);
> +
> + mutex_unlock(&scheduler_mutex);
> +
>   }
>   return 0;
>  }
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 2/2] drm/i915/gvt: Stop waiting whilst holding struct_mutex

[Zhenyu Wang]

On 2016.10.19 09:12:28 +0100, Chris Wilson wrote:
> For whatever reason, the gvt scheduler runs synchronously. At the very
> least, lets run synchronously without holding the struct_mutex.
> 
> Signed-off-by: Chris Wilson 

This will break current device model which assume to serve one VM context
on hw at each time but can't switch to another one between for emulation
issue.

This is not good but its current implementation limit we'll address later.

> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 4cedd3274da7..aa83dd3381a3 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -420,10 +420,6 @@ static int workload_thread(void *priv)
>  
>   intel_runtime_pm_get(gvt->dev_priv);
>  
> - /*
> -  * Always take i915 big lock first
> -  */
> - mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  
>   gvt_dbg_sched("ring id %d will dispatch workload %p\n",
>   workload->ring_id, workload);
> @@ -432,7 +428,10 @@ static int workload_thread(void *priv)
>   intel_uncore_forcewake_get(gvt->dev_priv,
>   FORCEWAKE_ALL);
>  
> + mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>   ret = dispatch_workload(workload);
> + mutex_lock(&gvt->dev_priv->drm.struct_mutex);
> +
>   if (ret) {
>   gvt_err("fail to dispatch workload, skip\n");
>   goto complete;
> @@ -442,8 +441,7 @@ static int workload_thread(void *priv)
>   workload->ring_id, workload);
>  
>   workload->status = i915_wait_request(workload->req,
> -  I915_WAIT_LOCKED,
> -  NULL, NULL);
> +  0, NULL, NULL);
>   if (workload->status != 0)
>   gvt_err("fail to wait workload, skip\n");
>  
> @@ -451,13 +449,14 @@ static int workload_thread(void *priv)
>   gvt_dbg_sched("will complete workload %p\n, status: %d\n",
>   workload, workload->status);
>  
> + mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>   complete_current_workload(gvt, ring_id);
> + mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
>  
>   if (need_force_wake)
>   intel_uncore_forcewake_put(gvt->dev_priv,
>   FORCEWAKE_ALL);
>  
> - mutex_unlock(&gvt->dev_priv->drm.struct_mutex);
>  
>   intel_runtime_pm_put(gvt->dev_priv);
>   }
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 2/2] drm/i915/gvt: Use the returned VMA to provide the virtual address

[Zhenyu Wang]

On 2016.10.19 09:03:35 +0100, Chris Wilson wrote:
> The purpose of returning the just-pinned VMA is so that we can use the
> information within, like its address. Also it should be tracked and used
> as the cookie to unpin...
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Zhenyu Wang 

> ---
>  drivers/gpu/drm/i915/gvt/execlist.c | 20 +---
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> b/drivers/gpu/drm/i915/gvt/execlist.c
> index a9d04c378755..cfdd3ae13fb0 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.c
> +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> @@ -385,8 +385,6 @@ static int set_gma_to_bb_cmd(struct intel_shadow_bb_entry 
> *entry_obj,
>  static void prepare_shadow_batch_buffer(struct intel_vgpu_workload *workload)
>  {
>   int gmadr_bytes = workload->vgpu->gvt->device_info.gmadr_bytes_in_cmd;
> - struct i915_vma *vma;
> - unsigned long gma;
>  
>   /* pin the gem object to ggtt */
>   if (!list_empty(&workload->shadow_bb)) {
> @@ -398,8 +396,10 @@ static void prepare_shadow_batch_buffer(struct 
> intel_vgpu_workload *workload)
>  
>   list_for_each_entry_safe(entry_obj, temp, &workload->shadow_bb,
>   list) {
> + struct i915_vma *vma;
> +
>   vma = i915_gem_object_ggtt_pin(entry_obj->obj, NULL, 0,
> - 0, 0);
> +4, 0);
>   if (IS_ERR(vma)) {
>   gvt_err("Cannot pin\n");
>   return;
> @@ -407,9 +407,9 @@ static void prepare_shadow_batch_buffer(struct 
> intel_vgpu_workload *workload)
>   i915_gem_object_unpin_pages(entry_obj->obj);
>  
>   /* update the relocate gma with shadow batch buffer*/
> - gma = i915_gem_object_ggtt_offset(entry_obj->obj, NULL);
> - WARN_ON(!IS_ALIGNED(gma, 4));
> - set_gma_to_bb_cmd(entry_obj, gma, gmadr_bytes);
> + set_gma_to_bb_cmd(entry_obj,
> +   i915_ggtt_offset(vma),
> +   gmadr_bytes);
>   }
>   }
>  }
> @@ -441,7 +441,6 @@ static int update_wa_ctx_2_shadow_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>  static void prepare_shadow_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
>  {
>   struct i915_vma *vma;
> - unsigned long gma;
>   unsigned char *per_ctx_va =
>   (unsigned char *)wa_ctx->indirect_ctx.shadow_va +
>   wa_ctx->indirect_ctx.size;
> @@ -449,16 +448,15 @@ static void prepare_shadow_wa_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   if (wa_ctx->indirect_ctx.size == 0)
>   return;
>  
> - vma = i915_gem_object_ggtt_pin(wa_ctx->indirect_ctx.obj, NULL, 0, 0, 0);
> + vma = i915_gem_object_ggtt_pin(wa_ctx->indirect_ctx.obj, NULL,
> +0, CACHELINE_BYTES, 0);
>   if (IS_ERR(vma)) {
>   gvt_err("Cannot pin indirect ctx obj\n");
>   return;
>   }
>   i915_gem_object_unpin_pages(wa_ctx->indirect_ctx.obj);
>  
> - gma = i915_gem_object_ggtt_offset(wa_ctx->indirect_ctx.obj, NULL);
> - WARN_ON(!IS_ALIGNED(gma, CACHELINE_BYTES));
> - wa_ctx->indirect_ctx.shadow_gma = gma;
> + wa_ctx->indirect_ctx.shadow_gma = i915_ggtt_offset(vma);
>  
>   wa_ctx->per_ctx.shadow_gma = *((unsigned int *)per_ctx_va + 1);
>   memset(per_ctx_va, 0, CACHELINE_BYTES);
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: Stop checking for impossible interrupts from a kthread

[Zhenyu Wang]

On 2016.10.19 09:12:27 +0100, Chris Wilson wrote:
> The kthread will not be interrupted, don't even bother checking.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Zhenyu Wang 

> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index b15cdf5978a9..4cedd3274da7 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -423,12 +423,7 @@ static int workload_thread(void *priv)
>   /*
>* Always take i915 big lock first
>*/
> - ret = i915_mutex_lock_interruptible(&gvt->dev_priv->drm);
> - if (ret < 0) {
> - gvt_err("i915 submission is not available, retry\n");
> - schedule_timeout(1);
> - continue;
> - }
> + mutex_lock(&gvt->dev_priv->drm.struct_mutex);
>  
>   gvt_dbg_sched("ring id %d will dispatch workload %p\n",
>   workload->ring_id, workload);
> @@ -447,7 +442,7 @@ static int workload_thread(void *priv)
>   workload->ring_id, workload);
>  
>   workload->status = i915_wait_request(workload->req,
> -  I915_WAIT_INTERRUPTIBLE | 
> I915_WAIT_LOCKED,
> +  I915_WAIT_LOCKED,
>NULL, NULL);
>   if (workload->status != 0)
>   gvt_err("fail to wait workload, skip\n");
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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-g device model core

[Zhenyu Wang]

On 2016.10.19 08:50:21 +0100, Chris Wilson wrote:
> On Fri, Oct 14, 2016 at 06:30:30PM +0800, Zhenyu Wang wrote:
> > 
> > Hi,
> > 
> > This is first pull request to merge GVT-g device model in i915
> > which contains core GVT-g device model work to virtualize GPU
> > resources. This tries to add feature of Intel GVT-g technology
> > for full GPU virtualization. This version will support KVM based
> > virtualization solution named as KVMGT.
> > 
> > More background is on official project home: https://01.org/igvt-g
> > 
> > To manage mediated device between virtual GPU and physical device it
> > will rely on VFIO/mdev framework, this version has not included GVT-g
> > device model integration work for VFIO/mdev yet as VFIO community is
> > still under work to refine code base. Currently we're basing on
> > VFIO/mdev v8 patch series (http://www.spinics.net/lists/kvm/msg138515.html)
> > and doing more testings on that.
> > 
> > There're also several KVM change dependences. KVM maintainer has
> > merged two and we will ensure left hits KVM tree before sending new
> > pull request to enable that.
> 
> Do you have scripts we can use for running igt under kvm/gvt? (Plus
> interesting tests for both multiple guests and host activity.)

cc: Terrence. We're working on that also 0day people are interested to
add tests like that too.

Our current top priority is to integrate with VFIO/mdev and test for
guest VMs.

-- 
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 2/2] drm/i915/gvt: i915_gem_object_create() returns an error pointer

[Zhenyu Wang]

On 2016.10.19 08:51:33 +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 03:45:19PM +0800, Zhenyu Wang wrote:
> > On 2016.10.19 08:42:50 +0100, Chris Wilson wrote:
> > > On failure from i915_gem_object_create(), we need to check for an error
> > > pointer not NULL.
> > > 
> > > Signed-off-by: Chris Wilson 
> > 
> > Reviewed-by: Zhenyu Wang 
> > 
> > Thanks, Chris. Looks good to me, will put in next pull request.
> 
> Too late, I want it now since this broken code is impacting my work.

ok, plan to send a new pull request today, either someone picks this up
directly or I'd 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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: i915_gem_object_create() returns an error pointer

[Zhenyu Wang]

On 2016.10.19 08:42:50 +0100, Chris Wilson wrote:
> On failure from i915_gem_object_create(), we need to check for an error
> pointer not NULL.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Zhenyu Wang 

Thanks, Chris. Looks good to me, will put in next pull request.

-- 
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: s/drm_gem_object_unreference/i915_gem_object_put/

[Zhenyu Wang]

On 2016.10.19 08:42:49 +0100, Chris Wilson wrote:
> Deprecated functions; it is also not clear whether these are called from
> the right context.
> 
> Signed-off-by: Chris Wilson 

Thanks, Chris.

Already did a same fix on 
https://github.com/01org/gvt-linux/commit/abd8dc57b13cccfa493553b4e64ba175070bbb0c

> ---
>  drivers/gpu/drm/i915/gvt/execlist.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
> b/drivers/gpu/drm/i915/gvt/execlist.c
> index c50a3d1a5131..a9d04c378755 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.c
> +++ b/drivers/gpu/drm/i915/gvt/execlist.c
> @@ -498,7 +498,7 @@ static void release_shadow_batch_buffer(struct 
> intel_vgpu_workload *workload)
>  
>   list_for_each_entry_safe(entry_obj, temp, &workload->shadow_bb,
>list) {
> - drm_gem_object_unreference(&(entry_obj->obj->base));
> + i915_gem_object_put(entry_obj->obj);
>   kvfree(entry_obj->va);
>   list_del(&entry_obj->list);
>   kfree(entry_obj);
> @@ -511,7 +511,7 @@ static void release_shadow_wa_ctx(struct 
> intel_shadow_wa_ctx *wa_ctx)
>   if (wa_ctx->indirect_ctx.size == 0)
>   return;
>  
> - drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
> + i915_gem_object_put(wa_ctx->indirect_ctx.obj);
>   kvfree(wa_ctx->indirect_ctx.shadow_va);
>  }
>  
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: build warnings after merge of the drm-intel tree

[Zhenyu Wang]

On 2016.10.19 10:57:53 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> 
> drivers/gpu/drm/i915/gvt/execlist.c: In function 
> 'release_shadow_batch_buffer':
> drivers/gpu/drm/i915/gvt/execlist.c:501:4: warning: 
> 'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
> drm_gem_object_unreference(&(entry_obj->obj->base));
> ^
> In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
> drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
>  extern void drm_gem_object_unreference(struct drm_gem_object *);
>  ^
> drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_shadow_wa_ctx':
> drivers/gpu/drm/i915/gvt/execlist.c:514:2: warning: 
> 'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
>   drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
>   ^
> In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
> drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
>  extern void drm_gem_object_unreference(struct drm_gem_object *);
>  ^
> 
> Introduced by commit
> 
>   be1da7070aea ("drm/i915/gvt: vGPU command scanner")
> 
> interacting with commit
> 
>   f8c417cdb1b8 ("drm/i915: Rename drm_gem_object_unreference in preparation 
> for lockless free")
> 
> from Linus' tree.
> 

Sorry for this, we will fix that in next pull request to replace old interface.

-- 
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-g device model core

[Zhenyu Wang]

On 2016.10.18 14:59:14 +0300, Jani Nikula wrote:
> On Mon, 17 Oct 2016, Jani Nikula  wrote:
> > On Mon, 17 Oct 2016, Daniel Vetter  wrote:
> >> Ok applied, but a few things to keep in mind before your next pull
> >> request:
> >>
> >> - Dont rebase everything 5 seconds before sending out the pull request.
> >>   That just invalidates all the testing you've done, so not a good idea.
> >>   In general try to avoid rebases as much as possible, and only rebase to
> >>   take out a truly embarassing mistake. And then only rebase up to the
> >>   patch that needs a hotfix, not your entire tree.
> >
> > CONFIG_DRM_I915_GVT=y
> >
> > drivers/gpu/drm/i915/gvt/handlers.c: In function ‘render_mmio_to_ring_id’:
> > drivers/gpu/drm/i915/gvt/handlers.c:137:31: error: request for member 
> > ‘mmio_base’ in something not a structure or union
> >if (gvt->dev_priv->engine[i].mmio_base == reg)
> 
> This is now fixed, thanks, but there's still a load of sparse warnings
> coming from gvt. Please install sparse, and run e.g.
> 
> $ make
> $ rm drivers/gpu/drm/i915/gvt/*.o
> $ make C=1
> 
> Below is a list of current warnings.
> 

yeah, sorry that we ignored sparse step, will address that in next pull request 
too.

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] drm/i915/gvt: Fix build failure after intel_engine_cs change

[Zhenyu Wang]

On 2016.10.18 09:47:56 +0300, Joonas Lahtinen wrote:
> On ti, 2016-10-18 at 09:40 +0800, Zhenyu Wang wrote:
> > @@ -134,7 +134,7 @@ static int render_mmio_to_ring_id(struct intel_gvt 
> > *gvt, unsigned int reg)
> >  
> >     reg &= ~GENMASK(11, 0);
> >     for (i = 0; i < I915_NUM_ENGINES; i++) {
> > -   if (gvt->dev_priv->engine[i].mmio_base == reg)
> > +   if (gvt->dev_priv->engine[i]->mmio_base == reg)
> >     return i;
> >     }
> 
> This loop is bad now that engine[i] might be NULL. Use for_each_engine
> instead.
> 

yes, we're fixing this with newly merged code and testing for VM,
should be fixed in next pull request.

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] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix build failure after intel_engine_cs change

[Zhenyu Wang]

On 2016.10.18 05:39:11 +, Saarinen, Jani wrote:
> > == Series Details ==
> > 
> > Series: drm/i915/gvt: Fix build failure after intel_engine_cs change
> > URL   : https://patchwork.freedesktop.org/series/13910/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 13910v1 drm/i915/gvt: Fix build failure after intel_engine_cs change
> > https://patchwork.freedesktop.org/api/1.0/series/13910/revisions/1/mbox/
> > 
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > incomplete -> DMESG-WARN (fi-byt-n2820)
> Command   /opt/igt/tests/gem_exec_suspend --run-subtest basic-S3
> dmesg 
>  [  363.532729] Suspending console(s) (use no_console_suspend to debug)
> [  363.539402] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [  363.540866] sd 0:0:0:0: [sda] Stopping disk
> [  364.370247] Broke affinity for irq 19
> [  364.370265] Broke affinity for irq 87
> [  364.370272] Broke affinity for irq 88
> [  364.370278] Broke affinity for irq 89
> [  364.388813]  cache: parent cpu1 should not be sleeping
> [  364.638398] [ cut here ]
> [  364.638409] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2729 
> trace_hardirqs_on_caller+0x113/0x1b0
> [  364.638412] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [  364.638440] Modules linked in: snd_hda_intel i915 intel_powerclamp 
> coretemp crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi ghash_clmulni_intel 
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec lpc_ich snd_hwdep 
> snd_hda_core snd_pcm i2c_designware_platform i2c_designware_core r8169 mii 
> sdhci_acpi sdhci i2c_hid mmc_core [last unloaded: i915]
> [  364.638444] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G U  
> 4.9.0-rc1-CI-Patchwork_2740+ #1
> [  364.638446] Hardware name: 
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
>  
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
>  BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
> [  364.638453]  88013fd03d68 8142df05 88013fd03db8 
> 
> [  364.638458]  88013fd03da8 8107e496 0aa93fd03e08 
> 81e249a0
> [  364.638463]  8181d137 82e7e280  
> 0004
> [  364.638464] Call Trace:
> [  364.638472]   
> [  364.638473]  [] dump_stack+0x67/0x92
> [  364.638477]  [] __warn+0xc6/0xe0
> [  364.638483]  [] ? _raw_spin_unlock_irq+0x27/0x50
> [  364.638487]  [] warn_slowpath_fmt+0x4a/0x50
> [  364.638491]  [] ? rtc_handler+0x1d/0xa0
> [  364.638495]  [] trace_hardirqs_on_caller+0x113/0x1b0
> [  364.638499]  [] trace_hardirqs_on+0xd/0x10
> [  364.638502]  [] _raw_spin_unlock_irq+0x27/0x50
> [  364.638505]  [] rtc_handler+0x32/0xa0
> [  364.638509]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> [  364.638513]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> [  364.638517]  [] acpi_irq+0x11/0x2c
> [  364.638521]  [] __handle_irq_event_percpu+0x58/0x370
> [  364.638525]  [] handle_irq_event_percpu+0x1e/0x50
> [  364.638528]  [] handle_irq_event+0x34/0x60
> [  364.638531]  [] handle_fasteoi_irq+0xa6/0x170
> [  364.638536]  [] handle_irq+0x15/0x20
> [  364.638539]  [] do_IRQ+0x68/0x130
> [  364.638542]  [] common_interrupt+0x89/0x89
> [  364.638548]   
> [  364.638548]  [] ? mwait_idle+0x93/0x210
> [  364.638551]  [] ? mwait_idle+0x8a/0x210
> [  364.638555]  [] arch_cpu_idle+0xa/0x10
> [  364.638558]  [] default_idle_call+0x1e/0x30
> [  364.638561]  [] cpu_startup_entry+0x17c/0x1f0
> [  364.638565]  [] start_secondary+0x102/0x120
> [  364.638568] ---[ end trace 302f2b5e754e367a ]---
> 
> > dmesg-warn -> INCOMPLETE (fi-byt-j1900)
> 
> [075/246] skip: 12, pass: 62, fail: 1 -
> running: igt/gem_exec_suspend/basic-s3 
> 
> [075/246] skip: 12, pass: 62, fail: 1 \
> Build timed out (after 18 minutes). Marking the build as aborted.
> 
> > Test vgem_basic:
> > Subgroup unload:
> > skip   -> PASS   (fi-hsw-4770r)
> > pass   -> SKIP   (fi-bdw-5557u)
> > 
> > fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16
> > fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42
> > fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> > fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12
> > fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35
> > fi-hsw-4770  total:246  pass:224  dwarn:0   dfa

Re: [Intel-gfx] [PULL] GVT-g device model core

[Zhenyu Wang]

On 2016.10.17 16:07:50 +0200, Daniel Vetter wrote:
> Yeah might be best to have a new branch with upstreaming stuff (now you
> need to at least split out bugfixes for the already merged stuff) and
> treat that like a mostly stable branch. And the still unmerged features
> (vfio and all that) would then get rebased on top of that.
>

yeah, plan to do so, vfio part hasn't been merged, will rebase on new branch.

> 
> Also I already screwed up the merge, it doesn't even compile :( Sorry
> about that. Can you pls create a quick fixup patch just to make it work
> again and submit to intel-gfx? That way I can apply it directly.
> 

Done. As currently GVT-g code is closed bound to some i915 struct and
interface, any change for i915 interface might be possible to affect
GVT-g. As general rule API changer should cover for us too, but we might
try to capture that earlier, well at least 0day guy will shout out loudly.

-- 
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 build failure after intel_engine_cs change

[Zhenyu Wang]

Change GVT-g code reference for intel_engine_cs from static array to
allocated pointer after commit 3b3f1650b1ca ("drm/i915: Allocate
intel_engine_cs structure only for the enabled engines").

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/execlist.c  | 2 +-
 drivers/gpu/drm/i915/gvt/handlers.c  | 2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index 4a00ee7..c50a3d1 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -39,7 +39,7 @@
 #define _EL_OFFSET_STATUS_PTR   0x3A0
 
 #define execlist_ring_mmio(gvt, ring_id, offset) \
-   (gvt->dev_priv->engine[ring_id].mmio_base + (offset))
+   (gvt->dev_priv->engine[ring_id]->mmio_base + (offset))
 
 #define valid_context(ctx) ((ctx)->valid)
 #define same_context(a, b) (((a)->context_id == (b)->context_id) && \
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index d59a934..e8ec403 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -134,7 +134,7 @@ static int render_mmio_to_ring_id(struct intel_gvt *gvt, 
unsigned int reg)
 
reg &= ~GENMASK(11, 0);
for (i = 0; i < I915_NUM_ENGINES; i++) {
-   if (gvt->dev_priv->engine[i].mmio_base == reg)
+   if (gvt->dev_priv->engine[i]->mmio_base == reg)
return i;
}
return -1;
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 732672b..b15cdf5 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -68,7 +68,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
workload->ctx_desc.lrca);
 
context_page_num = intel_lr_context_size(
-   &gvt->dev_priv->engine[ring_id]);
+   gvt->dev_priv->engine[ring_id]);
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
@@ -171,7 +171,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
 
-   workload->req = i915_gem_request_alloc(&dev_priv->engine[ring_id],
+   workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
   shadow_ctx);
if (IS_ERR_OR_NULL(workload->req)) {
gvt_err("fail to allocate gem request\n");
@@ -298,7 +298,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
workload->ctx_desc.lrca);
 
context_page_num = intel_lr_context_size(
-   &gvt->dev_priv->engine[ring_id]);
+   gvt->dev_priv->engine[ring_id]);
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
-- 
2.9.3

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

Re: [Intel-gfx] [PULL] GVT-g device model core

[Zhenyu Wang]

On 2016.10.17 09:33:19 +0200, Daniel Vetter wrote:
> On Mon, Oct 17, 2016 at 09:30:45AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 14, 2016 at 06:30:30PM +0800, Zhenyu Wang wrote:
> > > 
> > > Hi,
> > > 
> > > This is first pull request to merge GVT-g device model in i915
> > > which contains core GVT-g device model work to virtualize GPU
> > > resources. This tries to add feature of Intel GVT-g technology
> > > for full GPU virtualization. This version will support KVM based
> > > virtualization solution named as KVMGT.
> > > 
> > > More background is on official project home: https://01.org/igvt-g
> > > 
> > > To manage mediated device between virtual GPU and physical device it
> > > will rely on VFIO/mdev framework, this version has not included GVT-g
> > > device model integration work for VFIO/mdev yet as VFIO community is
> > > still under work to refine code base. Currently we're basing on
> > > VFIO/mdev v8 patch series 
> > > (http://www.spinics.net/lists/kvm/msg138515.html)
> > > and doing more testings on that.
> > > 
> > > There're also several KVM change dependences. KVM maintainer has
> > > merged two and we will ensure left hits KVM tree before sending new
> > > pull request to enable that.
> > > 
> > > p.s, There would require some coordinate work for VFIO/mdev. We will
> > > send device model work for that after Alex merged mdev framework in
> > > VFIO tree. Alex has promised to merge that in early of Nov.
> > > 
> > > Let me know if there's any issue with this our first pull request.
> > 
> > Ok applied, but a few things to keep in mind before your next pull
> > request:
> > 
> > - Dont rebase everything 5 seconds before sending out the pull request.
> >   That just invalidates all the testing you've done, so not a good idea.
> >   In general try to avoid rebases as much as possible, and only rebase to
> >   take out a truly embarassing mistake. And then only rebase up to the
> >   patch that needs a hotfix, not your entire tree.
> > 
> > - Similar, don't base your pull requests upon a random commit of the day
> >   (that's why I noticed you rebased). Instead pick something meaningful,
> >   like a tag I (or Dave Airlie or Linus Torvalds) push out. Or another
> >   good option is to base it right on top of the last merge commit from
> >   gvt. Once you've picked a baseline, don't change it (except when you
> >   have a good reason). And if you need a patch from upstream also don't
> >   rebase, just send out a pull request with your current patch pile, and
> >   then continue applying more stuff on top once I merged that.
> >

Sorry for that although we liked to include only core GVT-g device
model in first pull request, we do have continual testing internally
to cover GVT-g features. Will do as you said.

> > - One technical nit on the integration: My idea was that i915 core code
> >   only calls a few specific functions and structures exposed through
> >   intel_gvt.h. But that file now seems to include gvt-internal headers,
> >   which is a bit a mess. Please clean that up in the next pull request:
> > 
> >   * Anything that core i915 code or headers needs must be moved into
> > intel_gvt.h.
> >   * Everything else, including the 2 gvt includes we now have (gvt/gvt.h
> > and i915_pvinfo.h) should only be included from code in
> > drm/i915/gvt.h. So either sprinkle include directives over your source
> > files for everything, or make gvt/gvt.h the main gvt header that pulls
> > in everything.
> > 
> >   The idea here is similar to drm core vs. i915: drm core headers never
> >   pull in i915 headers, and all communication happens through the
> >   well-defined interfaces in drm core header files. I think our goal with
> >   gvt should be similar, with all the interfaces being in intel_gvt.h.
> >   Otherwise I fear the submaintainer model will be a bit painful, if we
> >   don't aim for strict separation here.
> >

yeah, that's a little messy, we will try to clean it up.

> > - There's not yet a MAINTAINERS entry for i915/gvt with gvt mailing lists,
> >   git repos and your name on it. Please fix that in the next pull request,
> >   too.

Will add that.

> > 
> > - gvt seems to lack kernel-doc entirely. I think we need at least an
> >   overview file and interface documentation for the stuff in
> >   intel_gvt.[hc]. Please run
> > 
> > $ make hmtldocs
> >

[Intel-gfx] [PULL] GVT-g device model core

[Zhenyu Wang]

Hi,

This is first pull request to merge GVT-g device model in i915
which contains core GVT-g device model work to virtualize GPU
resources. This tries to add feature of Intel GVT-g technology
for full GPU virtualization. This version will support KVM based
virtualization solution named as KVMGT.

More background is on official project home: https://01.org/igvt-g

To manage mediated device between virtual GPU and physical device it
will rely on VFIO/mdev framework, this version has not included GVT-g
device model integration work for VFIO/mdev yet as VFIO community is
still under work to refine code base. Currently we're basing on
VFIO/mdev v8 patch series (http://www.spinics.net/lists/kvm/msg138515.html)
and doing more testings on that.

There're also several KVM change dependences. KVM maintainer has
merged two and we will ensure left hits KVM tree before sending new
pull request to enable that.

p.s, There would require some coordinate work for VFIO/mdev. We will
send device model work for that after Alex merged mdev framework in
VFIO tree. Alex has promised to merge that in early of Nov.

Let me know if there's any issue with this our first pull request.

Thanks!

--
The following changes since commit 86e83e35d190a9b553384e0e711091a4e9643998:

  drm/i915: Merge duplicate gen4 and vlv/chv enable vblank callbacks 
(2016-10-13 21:58:52 +0100)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-2016-10-14

for you to fetch changes up to 21196a81c2d8bc9d79e1cbd896f668106da4f75d:

  drm/i915/gvt: Support GVT-g on Skylake (2016-10-14 18:15:36 +0800)


Zhi Wang (17):
  drm/i915/gvt: vGPU HW resource management
  drm/i915/gvt: Introduce a framework for tracking HW registers.
  drm/i915/gvt: golden virtual HW state management
  drm/i915/gvt: Introduce basic vGPU life cycle management
  drm/i915/gvt: trace stub
  drm/i915/gvt: vGPU interrupt virtualization.
  drm/i915/gvt: vGPU graphics memory virtualization
  drm/i915/gvt: vGPU PCI configuration space virtualization
  drm/i915/gvt: vGPU MMIO virtualization
  drm/i915/gvt: vGPU display virtualization
  drm/i915/gvt: vGPU execlist virtualization
  drm/i915/gvt: vGPU workload submission
  drm/i915/gvt: vGPU workload scheduler
  drm/i915/gvt: vGPU schedule policy framework
  drm/i915/gvt: vGPU context switch
  drm/i915/gvt: vGPU command scanner
  drm/i915/gvt: Support GVT-g on Skylake

 drivers/gpu/drm/i915/gvt/Makefile   |4 +-
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  341 
 drivers/gpu/drm/i915/gvt/cfg_space.c|  287 +++
 drivers/gpu/drm/i915/gvt/cmd_parser.c   | 2878 +++
 drivers/gpu/drm/i915/gvt/cmd_parser.h   |   49 +
 drivers/gpu/drm/i915/gvt/debug.h|   29 +-
 drivers/gpu/drm/i915/gvt/display.c  |  329 
 drivers/gpu/drm/i915/gvt/display.h  |  163 ++
 drivers/gpu/drm/i915/gvt/edid.c |  531 ++
 drivers/gpu/drm/i915/gvt/edid.h |  150 ++
 drivers/gpu/drm/i915/gvt/execlist.c |  852 +
 drivers/gpu/drm/i915/gvt/execlist.h |  188 ++
 drivers/gpu/drm/i915/gvt/firmware.c |  308 
 drivers/gpu/drm/i915/gvt/gtt.c  | 2231 
 drivers/gpu/drm/i915/gvt/gtt.h  |  270 +++
 drivers/gpu/drm/i915/gvt/gvt.c  |  153 +-
 drivers/gpu/drm/i915/gvt/gvt.h  |  318 +++-
 drivers/gpu/drm/i915/gvt/handlers.c | 2794 ++
 drivers/gpu/drm/i915/gvt/hypercall.h|   34 +
 drivers/gpu/drm/i915/gvt/interrupt.c|  740 
 drivers/gpu/drm/i915/gvt/interrupt.h|  233 +++
 drivers/gpu/drm/i915/gvt/mmio.c |  305 
 drivers/gpu/drm/i915/gvt/mmio.h |  105 ++
 drivers/gpu/drm/i915/gvt/mpt.h  |  220 +++
 drivers/gpu/drm/i915/gvt/opregion.c |  343 
 drivers/gpu/drm/i915/gvt/reg.h  |   80 +
 drivers/gpu/drm/i915/gvt/render.c   |  290 
 drivers/gpu/drm/i915/gvt/render.h   |   43 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  291 
 drivers/gpu/drm/i915/gvt/sched_policy.h |   58 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  572 ++
 drivers/gpu/drm/i915/gvt/scheduler.h|  139 ++
 drivers/gpu/drm/i915/gvt/trace.h|  286 +++
 drivers/gpu/drm/i915/gvt/trace_points.c |   36 +
 drivers/gpu/drm/i915/gvt/vgpu.c |  272 +++
 drivers/gpu/drm/i915/intel_gvt.c|2 +
 drivers/gpu/drm/i915/intel_gvt.h|1 +
 37 files changed, 15913 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/aperture_gm.c
 create mode 100644 drivers/gpu/drm/i915/gvt/cfg_space.c
 create mode 100644 drivers/gpu/drm/i915/gvt/cmd_parser.c
 create mode 100644 drivers/gpu/drm/i915/gvt/cmd_parser.h
 create mode 100644 drivers/gpu/drm/i915/gvt/display.c
 create mode 100644 drivers/gpu/drm/i915/gvt/display.h
 create mode 100644 drivers/gpu/drm/i915/gvt/edid.c
 c

Re: [Intel-gfx] [PATCH 0/2] GVT-g guest patch for 4.8

[Zhenyu Wang]

On 2016.09.06 11:33:57 +0300, Jani Nikula wrote:
> On Tue, 06 Sep 2016, Chris Wilson  wrote:
> > On Tue, Sep 06, 2016 at 12:04:10PM +0800, Zhenyu Wang wrote:
> >> Hi,
> >> 
> >> Here're two patches for GVT-g guest to fix run against future GVT-g
> >> host driver, which try to ensure 4.8 will be ready to use for VM.
> >> 
> >> thanks.
> >> 
> >> Ping Gao (1):
> >>   drm/i915: enable vGPU detection for all
> >> 
> >> Zhi Wang (1):
> >>   drm/i915: disable 48bit full PPGTT when vGPU is active
> >> 
> >>  drivers/gpu/drm/i915/i915_gem_gtt.c | 9 ++---
> >>  drivers/gpu/drm/i915/i915_vgpu.c| 3 ---
> >>  2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > Acked-by: Chris Wilson 
> > -Chris
> 
> So these are needed for 4.8?
> 

Yeah, we'd like to support any distribution that will base on 4.8 kernel
for guest VM. So would require these changes.

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] [PATCH 2/2] drm/i915: disable 48bit full PPGTT when vGPU is active

[Zhenyu Wang]

From: Zhi Wang 

Disable 48bit full PPGTT on vGPU too for now.

Signed-off-by: Zhi Wang 
Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 570e731..e16c380 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -124,8 +124,11 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private 
*dev_priv,
has_full_48bit_ppgtt =
IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9;
 
-   if (intel_vgpu_active(dev_priv))
-   has_full_ppgtt = false; /* emulation is too hard */
+   if (intel_vgpu_active(dev_priv)) {
+   /* emulation is too hard */
+   has_full_ppgtt = false;
+   has_full_48bit_ppgtt = false;
+   }
 
if (!has_aliasing_ppgtt)
return 0;
@@ -160,7 +163,7 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private 
*dev_priv,
return 0;
}
 
-   if (INTEL_GEN(dev_priv) >= 8 && i915.enable_execlists)
+   if (INTEL_GEN(dev_priv) >= 8 && i915.enable_execlists && has_full_ppgtt)
return has_full_48bit_ppgtt ? 3 : 2;
else
return has_aliasing_ppgtt ? 1 : 0;
-- 
2.9.3

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