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

[Daniel Vetter]

On Thu, Oct 20, 2016 at 06:13:25PM +0800, Zhenyu Wang wrote:
> 
> 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.

Pulled, thanks. Quick one: I think it'd be good to also pull in the
intel_gvt.h header into the kerneldocs, and document shared structs a bit.
But that's probably better done after the header cleanup has landed.
-Daniel

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



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

[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] [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] [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: [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] [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: [Intel-gfx] [PULL] GVT-g device model core

[Jani Nikula]

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.

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] 
*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] *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] *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] 
*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] *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] *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] *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] *
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] 
*
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] 
*
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] *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] 
*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 
(fff4 becomes 1)

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

Re: [Intel-gfx] [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 

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

[Jani Nikula]

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)

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: [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
> > 
> >   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
>   

Re: [Intel-gfx] [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: [Intel-gfx] [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

[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