[PULL] more gvt-next for 4.16

[PULL] more gvt-next for 4.16

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 2596 bytes --]


Hi,

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

thanks
--
The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:

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

are available in the Git repository at:

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

for you to fetch changes up to 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7:

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

----------------------------------------------------------------
gvt-next-2017-12-22:

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

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

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

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

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


-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PULL] more gvt-next for 4.16

[Rodrigo Vivi]

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

dim apply-pull drm-intel-next-queued

https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
From https://github.com/intel/gvt-linux
 * tag                         gvt-next-2017-12-22 -> FETCH_HEAD
dim: ERROR: 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7 is lacking mandatory review, aborting

> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c   |  39 +-
>  drivers/gpu/drm/i915/gvt/display.c      |  81 ++--
>  drivers/gpu/drm/i915/gvt/edid.c         |  22 +-
>  drivers/gpu/drm/i915/gvt/fb_decoder.c   |  30 +-
>  drivers/gpu/drm/i915/gvt/gtt.c          |  37 +-
>  drivers/gpu/drm/i915/gvt/gtt.h          |   3 +
>  drivers/gpu/drm/i915/gvt/gvt.c          |   1 +
>  drivers/gpu/drm/i915/gvt/gvt.h          |  33 +-
>  drivers/gpu/drm/i915/gvt/handlers.c     | 750 ++++++++++++++++----------------
>  drivers/gpu/drm/i915/gvt/kvmgt.c        |   4 +-
>  drivers/gpu/drm/i915/gvt/mmio.c         |  57 +--
>  drivers/gpu/drm/i915/gvt/mmio.h         |   7 -
>  drivers/gpu/drm/i915/gvt/mmio_context.c | 238 +++++-----
>  drivers/gpu/drm/i915/gvt/trace.h        |  15 +-
>  drivers/gpu/drm/i915/gvt/vgpu.c         |  24 +-
>  15 files changed, 675 insertions(+), 666 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

Re: [PULL] more gvt-next for 4.16

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 2618 bytes --]

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

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

-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PULL] more gvt-next for 4.16

[Jani Nikula]

On Fri, 22 Dec 2017, Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> On 2017.12.21 19:07:07 -0800, Rodrigo Vivi wrote:
>> On Fri, Dec 22, 2017 at 02:43:06AM +0000, Zhenyu Wang wrote:
>> dim apply-pull drm-intel-next-queued
>> 
>> https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
>> From https://github.com/intel/gvt-linux
>>  * tag                         gvt-next-2017-12-22 -> FETCH_HEAD
>> dim: ERROR: 6660c07ab5d3a1388b07af55b2503dd7b2cc61f7 is lacking mandatory review, aborting
>>
>
> Looks dim doesn't allow committer == author without ack or r-b? Is
> this really mandatory required?

Yes. We want a minimum of two people looking at each patch. It's pretty
much irrelevant if the committer/maintainer is the author or not. 2*sob
or sob+rb or sob+ack, or more for more complicated things.

It's unfortunately common that the "obviously correct and trivial" patch
quickly committed by the author without anyone else looking at it is
actually buggy...

> If yes, I will apply this rule for gvt tree as well and encourage gvt
> developer to send a-b/r-b mail as looks people more like to use IM to
> exchange review comment..

We don't have a strict rule to always send acks or rb by mail. IRC or IM
is fine too for simple things. But we want to record the acks and rb in
the commit regardless. When I push patches that got IRC review, I add
the tags, and typically reply with something along the lines of, "Pushed
with J. Random Hacker's IRC review".

That said, I do encourage explicit ack/rb messages on the lists for
non-trivial things in the interest of open development and transparency.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PULL] more gvt-next for 4.16

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 3592 bytes --]

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

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

thanks
--
The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:

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

are available in the Git repository at:

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

for you to fetch changes up to 4fafba2d73fcaf1b433c26e753a98ad4b231754a:

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

----------------------------------------------------------------
gvt-next-2017-12-22:

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

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

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

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

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


-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PULL] more gvt-next for 4.16

[Rodrigo Vivi]

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

Thanks a lot for the quick action on this.

Pulled to dinq.

> 
> thanks
> --
> The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee:
> 
>   drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-22
> 
> for you to fetch changes up to 4fafba2d73fcaf1b433c26e753a98ad4b231754a:
> 
>   drm/i915/gvt: move write protect handler out of mmio emulation function (2017-12-22 16:33:50 +0800)
> 
> ----------------------------------------------------------------
> gvt-next-2017-12-22:
> 
> - more mmio switch optimization (Weinan)
> - cleanup i915_reg_t vs. offset usage (Zhenyu)
> - move write protect handler out of mmio handler (Zhenyu)
> 
> ----------------------------------------------------------------
> Weinan Li (4):
>       drm/i915/gvt: refine trace_render_mmio
>       drm/i915/gvt: optimize for vGPU mmio switch
>       drm/i915/gvt: refine mocs save restore policy
>       drm/i915/gvt: load host render mocs once in mocs switch
> 
> Xiaolin Zhang (1):
>       drm/i915/gvt: Fix pipe A enable as default for vgpu
> 
> Zhenyu Wang (4):
>       Merge tag 'drm-intel-next-2017-12-14' into gvt-next
>       drm/i915/gvt: always use i915_reg_t for MMIO handler definition
>       drm/i915/gvt: cleanup usage for typed mmio reg vs. offset
>       drm/i915/gvt: move write protect handler out of mmio emulation function
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c   |  39 +-
>  drivers/gpu/drm/i915/gvt/display.c      |  81 ++--
>  drivers/gpu/drm/i915/gvt/edid.c         |  22 +-
>  drivers/gpu/drm/i915/gvt/fb_decoder.c   |  30 +-
>  drivers/gpu/drm/i915/gvt/gtt.c          |  37 +-
>  drivers/gpu/drm/i915/gvt/gtt.h          |   3 +
>  drivers/gpu/drm/i915/gvt/gvt.c          |   1 +
>  drivers/gpu/drm/i915/gvt/gvt.h          |  33 +-
>  drivers/gpu/drm/i915/gvt/handlers.c     | 750 ++++++++++++++++----------------
>  drivers/gpu/drm/i915/gvt/kvmgt.c        |   4 +-
>  drivers/gpu/drm/i915/gvt/mmio.c         |  57 +--
>  drivers/gpu/drm/i915/gvt/mmio.h         |   7 -
>  drivers/gpu/drm/i915/gvt/mmio_context.c | 238 +++++-----
>  drivers/gpu/drm/i915/gvt/trace.h        |  15 +-
>  drivers/gpu/drm/i915/gvt/vgpu.c         |  24 +-
>  15 files changed, 675 insertions(+), 666 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[PULL] gvt-next-fixes for 4.16

[Zhi Wang]

Hi guys:
     Here are the latest gvt-next-fixes pull. It contains vGPU reset 
enhancement, which refines vGPU reset flow and the support of virtual 
aperture read/write when x-no-mmap=on is set in KVM, which is required 
by a test case from Redhat and also another fix for virtual OpRegion.

Thanks,
Zhi.

The following changes since commit 751b01cb07ebf0dbbe4a4fbfeaa509388e4a2b0a:

   drm/i915/ppgtt: Pin page directories before allocation (2018-02-01 
07:33:04 -0800)

are available in the git repository at:

   http://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-02-04

for you to fetch changes up to 47419494f216812b42f5d1c5a2984cd46253b4cc:

   drm/i915/gvt: Use KVM r/w to access guest opregion (2018-02-06 
13:14:47 +0800)

----------------------------------------------------------------
- vGPU reset refinement. (Weinan)
- Support aperture read/write emulation when x-no-mmap=on. (Changbin)
- Use guest memory read/write in GVT MPT to access OpRegion. (Tina)

----------------------------------------------------------------
Changbin Du (1):
       drm/i915/gvt: Fix aperture read/write emulation when enable 
x-no-mmap=on

Tina Zhang (1):
       drm/i915/gvt: Use KVM r/w to access guest opregion

Weinan Li (2):
       drm/i915/gvt: refine intel_vgpu_submission_ops as per engine ops
       drm/i915/gvt: only reset execlist state of one engine during VM 
engine reset

  drivers/gpu/drm/i915/gvt/cfg_space.c    | 15 +----
  drivers/gpu/drm/i915/gvt/execlist.c     | 22 ++++----
  drivers/gpu/drm/i915/gvt/gvt.h          |  6 +-
  drivers/gpu/drm/i915/gvt/handlers.c     |  7 +--
  drivers/gpu/drm/i915/gvt/kvmgt.c        | 36 +++++++++++-
  drivers/gpu/drm/i915/gvt/mmio.c         | 42 --------------
  drivers/gpu/drm/i915/gvt/opregion.c     | 98 
+++++++++++++++++++++++----------
  drivers/gpu/drm/i915/gvt/sched_policy.c | 14 ++++-
  drivers/gpu/drm/i915/gvt/scheduler.c    | 19 ++++---
  drivers/gpu/drm/i915/gvt/scheduler.h    |  1 +
  drivers/gpu/drm/i915/gvt/vgpu.c         |  3 +-
  11 files changed, 144 insertions(+), 119 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Rodrigo Vivi]

Hi Zhi,

Daniel asked few weeks ago about the scripts that you run there,
but I didn't see any follow-up.

I don't understand why yet, but apparently gvt pull request
is not going to patchwork so dim is not able to add the "Link:"
hence end up without mandatory patchwork links.

Last round I by-pass dim and move forward even without the "Link:"
if the solution is easier I'd like to do the right thing this time.

Although I'm open to by-pass again,
I'd like to know if we are in sync to understand what is happening
again and get that fixed for next time

Cc: Daniel in case he know a quick fix or can at least provide more
    info there on what could be failing.

Thanks,
Rodrigo.


On Tue, Feb 06, 2018 at 08:36:49AM +0000, Zhi Wang wrote:
> Hi guys:
>     Here are the latest gvt-next-fixes pull. It contains vGPU reset
> enhancement, which refines vGPU reset flow and the support of virtual
> aperture read/write when x-no-mmap=on is set in KVM, which is required by a
> test case from Redhat and also another fix for virtual OpRegion.
> 
> Thanks,
> Zhi.
> 
> The following changes since commit 751b01cb07ebf0dbbe4a4fbfeaa509388e4a2b0a:
> 
>   drm/i915/ppgtt: Pin page directories before allocation (2018-02-01
> 07:33:04 -0800)
> 
> are available in the git repository at:
> 
>   http://github.com/intel/gvt-linux.git tags/gvt-next-fixes-2018-02-04
> 
> for you to fetch changes up to 47419494f216812b42f5d1c5a2984cd46253b4cc:
> 
>   drm/i915/gvt: Use KVM r/w to access guest opregion (2018-02-06 13:14:47
> +0800)
> 
> ----------------------------------------------------------------
> - vGPU reset refinement. (Weinan)
> - Support aperture read/write emulation when x-no-mmap=on. (Changbin)
> - Use guest memory read/write in GVT MPT to access OpRegion. (Tina)
> 
> ----------------------------------------------------------------
> Changbin Du (1):
>       drm/i915/gvt: Fix aperture read/write emulation when enable
> x-no-mmap=on
> 
> Tina Zhang (1):
>       drm/i915/gvt: Use KVM r/w to access guest opregion
> 
> Weinan Li (2):
>       drm/i915/gvt: refine intel_vgpu_submission_ops as per engine ops
>       drm/i915/gvt: only reset execlist state of one engine during VM engine
> reset
> 
>  drivers/gpu/drm/i915/gvt/cfg_space.c    | 15 +----
>  drivers/gpu/drm/i915/gvt/execlist.c     | 22 ++++----
>  drivers/gpu/drm/i915/gvt/gvt.h          |  6 +-
>  drivers/gpu/drm/i915/gvt/handlers.c     |  7 +--
>  drivers/gpu/drm/i915/gvt/kvmgt.c        | 36 +++++++++++-
>  drivers/gpu/drm/i915/gvt/mmio.c         | 42 --------------
>  drivers/gpu/drm/i915/gvt/opregion.c     | 98
> +++++++++++++++++++++++----------
>  drivers/gpu/drm/i915/gvt/sched_policy.c | 14 ++++-
>  drivers/gpu/drm/i915/gvt/scheduler.c    | 19 ++++---
>  drivers/gpu/drm/i915/gvt/scheduler.h    |  1 +
>  drivers/gpu/drm/i915/gvt/vgpu.c         |  3 +-
>  11 files changed, 144 insertions(+), 119 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1378 bytes --]

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

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

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

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

thanks

-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

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

[Rodrigo Vivi]

Zhenyu Wang <zhenyuw@linux.intel.com> writes:

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

Hmm... That's strange.
I'm basing my comments on this reply from Daniel:
https://www.spinics.net/lists/intel-gfx/msg149862.html (4.15)

I don't believe Daniel or Jani ever bypassed the dim like I'm doing.
But also on 4.14 fixes I dind't have to bypass dim, so something is
strange but I don't fully understand because I lack on the previous
history here.

> To have patchwork set up for gvt would be
> good, as our QA's current infrastruture doesn't require that, so I
> didn't push the request for it. Who may we contact to setup for us
> now? Or open a fd.o bug?
>
>> 
>> Although I'm open to by-pass again,
>> I'd like to know if we are in sync to understand what is happening
>> again and get that fixed for next time
>> 
>> Cc: Daniel in case he know a quick fix or can at least provide more
>>     info there on what could be failing.
>
> As we'd like to make those stable fixes in upstream soon, maybe better
> bypass for lacking Link tag at this time, we'll try to fix that from
> next pull. Sorry for any inconvenience.

No worries. Let's just try to understand and find the solution
for the next pull. For now I by pass and merged on dinf.
Now it is time to fix the drm-tip conflicts and wait for CI
to run. So, luckly, tomorrow morning I send out the pull request.

>
> thanks

thanks you!

>
> -- 
> Open Source Technology Center, Intel ltd.
>
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PULL] more gvt-next for 4.16

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 2564 bytes --]


Hi,

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

thanks
--
The following changes since commit 1603660b3342269c95fcafee1945790342a8c28e:

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

are available in the Git repository at:

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

for you to fetch changes up to 461bd6227ede277138bf33c2156b6ebd1fba04c2:

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

----------------------------------------------------------------
gvt-next-2017-12-14:

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

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

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

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

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

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

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

-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

Re: [PULL] more gvt-next for 4.16

[Rodrigo Vivi]

Hi Zhenyu,

Applied to dinq. Thanks for sending this sooner.

So, regarding your question about vacations on previous email,
I will be out only coupe days... probably 26 and 27.

My next proper vacation is only in May.

Thanks,
Rodrigo.

On Thu, Dec 14, 2017 at 03:34:34AM +0000, Zhenyu Wang wrote:
> 
> Hi,
> 
> Please pull more gvt-next updates for 4.16. Mostly on code and
> regression fixes for last two gvt-next pulls and more refinement.
> Details below.
> 
> thanks
> --
> The following changes since commit 1603660b3342269c95fcafee1945790342a8c28e:
> 
>   drm/i915/gvt: set max priority for gvt context (2017-12-04 11:24:35 +0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-14
> 
> for you to fetch changes up to 461bd6227ede277138bf33c2156b6ebd1fba04c2:
> 
>   drm/i915/gvt/fb_decoder: Fix out-of-bounds read (2017-12-11 17:18:39 +0800)
> 
> ----------------------------------------------------------------
> gvt-next-2017-12-14:
> 
> - fixes for two coverity scan errors (Colin)
> - mmio switch code refine (Changbin)
> - more virtual display dmabuf fixes (Tina/Gustavo)
> - misc cleanups (Pei)
> 
> ----------------------------------------------------------------
> Changbin Du (4):
>       drm/i915/gvt: Refine the ring mmio list definition
>       drm/i915/gvt: Select appropriate mmio list at initialization time
>       drm/i915/gvt: Remove MMIO barrier in MMIO switch
>       drm/i915/gvt: Rename file render.{c, h} to mmio_context.{c, h}
> 
> Colin Ian King (2):
>       drm/i915/gvt: Add missing breaks in switch statement
>       drm/i915/gvt: fix off-by-one comparison of ring_id
> 
> Gustavo A. R. Silva (1):
>       drm/i915/gvt/fb_decoder: Fix out-of-bounds read
> 
> Pei Zhang (2):
>       drm/i915/gvt/kvmgt: fill info for ROM/VGA region
>       drm/i915/gvt: refine function emulate_mmio_read/write
> 
> Tina Zhang (1):
>       drm/i915/gvt: Refine dmabuf_obj cleanup process
> 
>  drivers/gpu/drm/i915/gvt/Makefile                  |   2 +-
>  drivers/gpu/drm/i915/gvt/dmabuf.c                  |  15 +-
>  drivers/gpu/drm/i915/gvt/fb_decoder.c              |   6 +
>  drivers/gpu/drm/i915/gvt/gvt.c                     |   2 +
>  drivers/gpu/drm/i915/gvt/gvt.h                     |   4 +-
>  drivers/gpu/drm/i915/gvt/handlers.c                |   6 +-
>  drivers/gpu/drm/i915/gvt/kvmgt.c                   |   6 +-
>  drivers/gpu/drm/i915/gvt/mmio.c                    |  36 ++-
>  .../gpu/drm/i915/gvt/{render.c => mmio_context.c}  | 262 ++++++++++-----------
>  .../gpu/drm/i915/gvt/{render.h => mmio_context.h}  |   9 +
>  10 files changed, 181 insertions(+), 167 deletions(-)
>  rename drivers/gpu/drm/i915/gvt/{render.c => mmio_context.c} (53%)
>  rename drivers/gpu/drm/i915/gvt/{render.h => mmio_context.h} (91%)
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827



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

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