[PULL] GVT-g device model core

[PULL] GVT-g device model core

[Zhenyu Wang]

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


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
 create mode 100644 drivers/gpu/drm/i915/gvt/edid.h
 create mode 100644 drivers/gpu/drm/i915/gvt/execlist.c
 create mode 100644 drivers/gpu/drm/i915/gvt/execlist.h
 create mode 100644 drivers/gpu/drm/i915/gvt/firmware.c
 create mode 100644 drivers/gpu/drm/i915/gvt/gtt.c
 create mode 100644 drivers/gpu/drm/i915/gvt/gtt.h
 create mode 100644 drivers/gpu/drm/i915/gvt/handlers.c
 create mode 100644 drivers/gpu/drm/i915/gvt/interrupt.c
 create mode 100644 drivers/gpu/drm/i915/gvt/interrupt.h
 create mode 100644 drivers/gpu/drm/i915/gvt/mmio.c
 create mode 100644 drivers/gpu/drm/i915/gvt/mmio.h
 create mode 100644 drivers/gpu/drm/i915/gvt/opregion.c
 create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
 create mode 100644 drivers/gpu/drm/i915/gvt/render.c
 create mode 100644 drivers/gpu/drm/i915/gvt/render.h
 create mode 100644 drivers/gpu/drm/i915/gvt/sched_policy.c
 create mode 100644 drivers/gpu/drm/i915/gvt/sched_policy.h
 create mode 100644 drivers/gpu/drm/i915/gvt/scheduler.c
 create mode 100644 drivers/gpu/drm/i915/gvt/scheduler.h
 create mode 100644 drivers/gpu/drm/i915/gvt/trace.h
 create mode 100644 drivers/gpu/drm/i915/gvt/trace_points.c
 create mode 100644 drivers/gpu/drm/i915/gvt/vgpu.c

-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 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-g device model core

[Daniel Vetter]

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.

- 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.

- 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.

- 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

  to make sure it all looks pretty (you need to add stanzas in
  Documenation/gpu/i915.rst to include things). Another item for the next
  pull request please.

Also, this is the first time ever I've taken a pull request, so some
learning involved on my side too. Please bear with me ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PULL] GVT-g device model core

[Daniel Vetter]

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.
> 
> - 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.
> 
> - 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.
> 
> - 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
> 
>   to make sure it all looks pretty (you need to add stanzas in
>   Documenation/gpu/i915.rst to include things). Another item for the next
>   pull request please.

Quick addition: Since this will be a patch touching i915 core code pls
submit it to intel-gfx for review. You can then apply it to your tree once
it's reviewed (or Joonas or someone can commit directly to
drm-intel-next-queued).

And another item:
- Please add me to the moderation whitelist of igt-g-dev, I don't want to
  be spammed by moderation mails every time I reply to your pull requests
  ;-)

Cheers, Daniel

> 
> Also, this is the first time ever I've taken a pull request, so some
> learning involved on my side too. Please bear with me ;-)
> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PULL] GVT-g device model core

[Zhenyu Wang]

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

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
> > 
> >   to make sure it all looks pretty (you need to add stanzas in
> >   Documenation/gpu/i915.rst to include things). Another item for the next
> >   pull request please.
> 
> Quick addition: Since this will be a patch touching i915 core code pls
> submit it to intel-gfx for review. You can then apply it to your tree once
> it's reviewed (or Joonas or someone can commit directly to
> drm-intel-next-queued).
>

Will fix kernel-doc too.

> And another item:
> - Please add me to the moderation whitelist of igt-g-dev, I don't want to
>   be spammed by moderation mails every time I reply to your pull requests
>   ;-)
> 

Will ping 01.org admin for that.

> > Also, this is the first time ever I've taken a pull request, so some
> > learning involved on my side too. Please bear with me ;-)
> > 

It's new thing for us to learn obviously. Thanks for the advice!

-- 
Open Source Technology Center, Intel ltd.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 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-g device model core

[Jani Nikula]

On Mon, 17 Oct 2016, Daniel Vetter <daniel@ffwll.ch> 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)

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

[Daniel Vetter]

On Mon, Oct 17, 2016 at 03:45:47PM +0800, Zhenyu Wang wrote:
> 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.

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.

> > > - 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
> > > 
> > >   to make sure it all looks pretty (you need to add stanzas in
> > >   Documenation/gpu/i915.rst to include things). Another item for the next
> > >   pull request please.
> > 
> > Quick addition: Since this will be a patch touching i915 core code pls
> > submit it to intel-gfx for review. You can then apply it to your tree once
> > it's reviewed (or Joonas or someone can commit directly to
> > drm-intel-next-queued).
> >
> 
> Will fix kernel-doc too.
> 
> > And another item:
> > - Please add me to the moderation whitelist of igt-g-dev, I don't want to
> >   be spammed by moderation mails every time I reply to your pull requests
> >   ;-)
> > 
> 
> Will ping 01.org admin for that.

Just noticed that my mail was outright rejected. If you want to keep the
list on 01.org as the official one, you need to switch to moderating for
non-subscribers. Otherwise it's way too hard for external people to submit
a quick bug report for your patches.

> > > Also, this is the first time ever I've taken a pull request, so some
> > > learning involved on my side too. Please bear with me ;-)
> > > 
> 
> It's new thing for us to learn obviously. Thanks for the advice!

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.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PULL] GVT-g device model core

[Zhenyu Wang]

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

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 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-g device model core

[Jani Nikula]

On Mon, 17 Oct 2016, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Mon, 17 Oct 2016, Daniel Vetter <daniel@ffwll.ch> 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.

BR,
Jani.


  CHECK   drivers/gpu/drm/i915/gvt/firmware.c
drivers/gpu/drm/i915/gvt/firmware.c:54:9: warning: incorrect type in argument 2 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:54:9:    expected void volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/firmware.c:54:9:    got void *
drivers/gpu/drm/i915/gvt/firmware.c:56:9: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:56:9:    expected void const volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/firmware.c:56:9:    got void *
drivers/gpu/drm/i915/gvt/firmware.c:58:13: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:58:13:    expected void const volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/firmware.c:58:13:    got void *
drivers/gpu/drm/i915/gvt/firmware.c:61:9: warning: incorrect type in argument 2 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:61:9:    expected void volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/firmware.c:61:9:    got void *
drivers/gpu/drm/i915/gvt/firmware.c:63:13: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:63:13:    expected void const volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/firmware.c:63:13:    got void *
drivers/gpu/drm/i915/gvt/firmware.c:66:13: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:66:13:    expected void const volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/firmware.c:66:13:    got void *
drivers/gpu/drm/i915/gvt/firmware.c:132:56: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:132:56:    expected void const volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/firmware.c:132:56:    got void *
drivers/gpu/drm/i915/gvt/firmware.c:259:14: warning: incorrect type in assignment (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:259:14:    expected void *mmio
drivers/gpu/drm/i915/gvt/firmware.c:259:14:    got void [noderef] <asn:2>*
drivers/gpu/drm/i915/gvt/firmware.c:299:27: warning: incorrect type in argument 2 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:299:27:    expected void [noderef] <asn:2>*<noident>
drivers/gpu/drm/i915/gvt/firmware.c:299:27:    got void *mmio
drivers/gpu/drm/i915/gvt/firmware.c:306:27: warning: incorrect type in argument 2 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:306:27:    expected void [noderef] <asn:2>*<noident>
drivers/gpu/drm/i915/gvt/firmware.c:306:27:    got void *mmio
  CC [M]  drivers/gpu/drm/i915/gvt/firmware.o
  CHECK   drivers/gpu/drm/i915/gvt/interrupt.c
drivers/gpu/drm/i915/gvt/interrupt.c:52:12: warning: symbol 'irq_name' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/gvt/interrupt.o
  CHECK   drivers/gpu/drm/i915/gvt/gtt.c
drivers/gpu/drm/i915/gvt/gtt.c:270:23: warning: cast removes address space of expression
drivers/gpu/drm/i915/gvt/gtt.c:274:21: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/gvt/gtt.c:274:21:    expected void const volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/gtt.c:274:21:    got void *addr
drivers/gpu/drm/i915/gvt/gtt.c:285:23: warning: cast removes address space of expression
drivers/gpu/drm/i915/gvt/gtt.c:288:21: warning: incorrect type in argument 2 (different address spaces)
drivers/gpu/drm/i915/gvt/gtt.c:288:21:    expected void volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/gtt.c:288:21:    got void *addr
drivers/gpu/drm/i915/gvt/gtt.c:1922:6: warning: symbol 'intel_gvt_create_scratch_page' was not declared. Should it be static?
drivers/gpu/drm/i915/gvt/gtt.c:1956:6: warning: symbol 'intel_gvt_release_scratch_page' was not declared. Should it be static?
drivers/gpu/drm/i915/gvt/gtt.c:1932:24: warning: odd constant _Bool cast (fffffffffffffff4 becomes 1)
drivers/gpu/drm/i915/gvt/gtt.c:1948:24: warning: odd constant _Bool cast (fffffffffffffffa becomes 1)
  CC [M]  drivers/gpu/drm/i915/gvt/gtt.o
  CHECK   drivers/gpu/drm/i915/gvt/cfg_space.c
  CC [M]  drivers/gpu/drm/i915/gvt/cfg_space.o
  CHECK   drivers/gpu/drm/i915/gvt/opregion.c
drivers/gpu/drm/i915/gvt/opregion.c:45:48: warning: incorrect type in argument 2 (different address spaces)
drivers/gpu/drm/i915/gvt/opregion.c:45:48:    expected void const volatile [noderef] <asn:2>*src
drivers/gpu/drm/i915/gvt/opregion.c:45:48:    got void *host_va
drivers/gpu/drm/i915/gvt/opregion.c:165:30: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/gvt/opregion.c:165:30:    expected void volatile [noderef] <asn:2>*addr
drivers/gpu/drm/i915/gvt/opregion.c:165:30:    got void *opregion_va
drivers/gpu/drm/i915/gvt/opregion.c:183:35: warning: incorrect type in assignment (different address spaces)
drivers/gpu/drm/i915/gvt/opregion.c:183:35:    expected void *opregion_va
drivers/gpu/drm/i915/gvt/opregion.c:183:35:    got void [noderef] <asn:2>*
  CC [M]  drivers/gpu/drm/i915/gvt/opregion.o
  CHECK   drivers/gpu/drm/i915/gvt/mmio.c
  CC [M]  drivers/gpu/drm/i915/gvt/mmio.o
  CHECK   drivers/gpu/drm/i915/gvt/display.c
drivers/gpu/drm/i915/gvt/display.c:122:4: warning: symbol 'dpcd_fix_data' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/gvt/display.o
  CHECK   drivers/gpu/drm/i915/gvt/edid.c
  CC [M]  drivers/gpu/drm/i915/gvt/edid.o
  CHECK   drivers/gpu/drm/i915/gvt/execlist.c
drivers/gpu/drm/i915/gvt/execlist.c:619:6: warning: symbol 'submit_context' was not declared. Should it be static?
drivers/gpu/drm/i915/gvt/execlist.c:634:24: warning: odd constant _Bool cast (ffffffffffffffea becomes 1)
drivers/gpu/drm/i915/gvt/execlist.c:661:24: warning: odd constant _Bool cast (fffffffffffffff4 becomes 1)
  CC [M]  drivers/gpu/drm/i915/gvt/execlist.o
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 (declared at drivers/gpu/drm/i915/i915_drv.h:2344) [-Wdeprecated-declarations]
    drm_gem_object_unreference(&(entry_obj->obj->base));
    ^
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 (declared at drivers/gpu/drm/i915/i915_drv.h:2344) [-Wdeprecated-declarations]
  drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
  ^
  CHECK   drivers/gpu/drm/i915/gvt/scheduler.c
drivers/gpu/drm/i915/gvt/scheduler.c:43:6: warning: symbol 'set_context_pdp_root_pointer' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/gvt/scheduler.o
  CHECK   drivers/gpu/drm/i915/gvt/sched_policy.c
drivers/gpu/drm/i915/gvt/sched_policy.c:236:35: warning: symbol 'tbs_schedule_ops' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/gvt/sched_policy.o
  CHECK   drivers/gpu/drm/i915/gvt/render.c
  CC [M]  drivers/gpu/drm/i915/gvt/render.o
  CHECK   drivers/gpu/drm/i915/gvt/cmd_parser.c
drivers/gpu/drm/i915/gvt/cmd_parser.c:481:15: warning: symbol 'bypass_scan_mask' was not declared. Should it be static?
drivers/gpu/drm/i915/gvt/cmd_parser.c:482:6: warning: symbol 'bypass_batch_buffer_scan' was not declared. Should it be static?
drivers/gpu/drm/i915/gvt/cmd_parser.c:961:28: warning: symbol 'cmd_interrupt_events' was not declared. Should it be static?




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

[Chris Wilson]

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.

The fence stealing code is broken wrt runtime pm.

The command parser duplicated dead code, the whole shadow copy needs to
be rewritten from scratch to remove the duplicated bugs.

VMA insertion is incorrect and will cause random corruption (cut'n'paste
bugs for the win).

VMA pinning is broken and will cause corruption on memory pressure, or
worse allow exploitation of a read/write to reallocated system pages.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PULL] GVT-g device model core

[Zhenyu Wang]

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

On 2016.10.18 14:59:14 +0300, Jani Nikula wrote:
> On Mon, 17 Oct 2016, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Mon, 17 Oct 2016, Daniel Vetter <daniel@ffwll.ch> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 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-g device model core

[Chris Wilson]

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.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PULL] GVT-g device model core

[Zhenyu Wang]

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

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 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