i915 and GTV-g maintenance, workflows and CI

i915 and GTV-g maintenance, workflows and CI

[Jani Nikula]

We need to formalize the process between i915 proper and GVT-g a bit
more, and address some of the current shortcomings and issues in the
process and GVT-g CI.

This started off internally as a random list of items, I'm including
some of the current status as well. Please comment, as some of the stuff
here are just my opinions.

* How do we ensure GVT-g patches get the same kind of pre-merge CI
  coverage as we have for other i915 code? Could we at least make CI run
  tests on GVT-g pull requests before merging to drm-intel trees?

  => Work in progress to set up GVT-g CI.

* How do we handle fixes to GVT-g code? Do all fixes need to go via the
  GVT-g mailing lists and review? We're bound to get GVT-g patches on
  intel-gfx mailing list too. There's confusion already [1]. Mostly the
  GVT-g changes come from GVT-g maintainers as pull requests.

  [1] https://patchwork.freedesktop.org/series/14000/

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

* GVT-g needs to start annotating fixes with the Fixes: tags, preferably
  also cc: stable when we get that far, so our fixes plumbing can figure
  out which commits to backport.

  => GVT-g maintainers will take care of this.

* Should GVT-g have a MAINTAINERS entry of its own?

  => https://github.com/01org/gvt-linux/commit/41161c9e9e50a5bad98a0e74ad0878c352bdea40

	+INTEL GVT-g DRIVERS (Intel GPU Virtualization)
	+M:      Zhenyu Wang <zhenyuw@linux.intel.com>
	+M:      Zhi Wang <zhi.a.wang@intel.com>
	+L:      igvt-g-dev@lists.01.org
	+L:      intel-gfx@lists.freedesktop.org
	+W:      https://01.org/igvt-g
	+T:      git https://github.com/01org/gvt-linux.git
	+S:      Supported
	+F:      drivers/gpu/drm/i915/gvt/

  I think we'll want to keep intel-gfx there, but mostly I think it's
  fine for the usual GVT-g development to happen on igvt-g-dev only.

* igvt-g-dev@lists.01.org needs to start accepting mails from
  non-subscribers.

  => Work in progress.

* GVT-g needs to start paying more attention to compiler and sparse
  warnings.

  => GVT-G maintainers will take care of this.

* GVT-g could use some overview documentation under Documentation/gpu.

* GVT-g bug management. Do you have something set up already? Would be
  great to be able to use https://bugs.freedesktop.org so we could
  reassign between i915 and GVT-g.

What did I forget/overlook?

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: i915 and GTV-g maintenance, workflows and CI

[Daniel Vetter]

On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
> 
> We need to formalize the process between i915 proper and GVT-g a bit
> more, and address some of the current shortcomings and issues in the
> process and GVT-g CI.
> 
> This started off internally as a random list of items, I'm including
> some of the current status as well. Please comment, as some of the stuff
> here are just my opinions.
> 
> * How do we ensure GVT-g patches get the same kind of pre-merge CI
>   coverage as we have for other i915 code? Could we at least make CI run
>   tests on GVT-g pull requests before merging to drm-intel trees?
> 
>   => Work in progress to set up GVT-g CI.

Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want
to do that then it's fine, but otherwise I'm leaning towards treating gvt
like a sub-driver, with its own flavour of testing and review standards.

Of course anything touching shared code (i.e. outside of the gvt/ subdir),
or code which can't be disabled with Kconfig needs to follow our
established review&testing procedures. So submission to intel-gfx, CI by
patchwork, review per our standards.

> * How do we handle fixes to GVT-g code? Do all fixes need to go via the
>   GVT-g mailing lists and review? We're bound to get GVT-g patches on
>   intel-gfx mailing list too. There's confusion already [1]. Mostly the
>   GVT-g changes come from GVT-g maintainers as pull requests.
> 
>   [1] https://patchwork.freedesktop.org/series/14000/

Atm the gvt mailing list is closed, and there's no maintainer entry for it
either. I think Zhenyu just needs to hang out here on intel-gfx to catch
these, and then pick any gvt/ fixes up himself.

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

Ack.

> * GVT-g needs to start annotating fixes with the Fixes: tags, preferably
>   also cc: stable when we get that far, so our fixes plumbing can figure
>   out which commits to backport.
> 
>   => GVT-g maintainers will take care of this.

Either that, or they need to send -fixes pull requests your way. I think
we could try out either approach, but yes in the end gvt maintainers need
to own this. We (i915 team here) won't take care of that.

> * Should GVT-g have a MAINTAINERS entry of its own?
> 
>   => https://github.com/01org/gvt-linux/commit/41161c9e9e50a5bad98a0e74ad0878c352bdea40
> 
> 	+INTEL GVT-g DRIVERS (Intel GPU Virtualization)
> 	+M:      Zhenyu Wang <zhenyuw@linux.intel.com>
> 	+M:      Zhi Wang <zhi.a.wang@intel.com>
> 	+L:      igvt-g-dev@lists.01.org

Need to make sure igvt-g-dev is open to non-subscribers first. Otherwise
ack.

> 	+L:      intel-gfx@lists.freedesktop.org
> 	+W:      https://01.org/igvt-g
> 	+T:      git https://github.com/01org/gvt-linux.git
> 	+S:      Supported
> 	+F:      drivers/gpu/drm/i915/gvt/
> 
>   I think we'll want to keep intel-gfx there, but mostly I think it's
>   fine for the usual GVT-g development to happen on igvt-g-dev only.

+1

> * igvt-g-dev@lists.01.org needs to start accepting mails from
>   non-subscribers.
> 
>   => Work in progress.

Definitely ;-)

> * GVT-g needs to start paying more attention to compiler and sparse
>   warnings.
> 
>   => GVT-G maintainers will take care of this.
> 
> * GVT-g could use some overview documentation under Documentation/gpu.

Hm, should we have a TODO file in gvt for some of the issues raised? Otoh
most things are fairly small issues, so should all be fixable before 4.10
freeze.

> * GVT-g bug management. Do you have something set up already? Would be
>   great to be able to use https://bugs.freedesktop.org so we could
>   reassign between i915 and GVT-g.

+1.

> What did I forget/overlook?

Nothing else crosses my mind, but I'm sure we'll discover more ;-)
-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: i915 and GTV-g maintenance, workflows and CI

[Zhenyu Wang]

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

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

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

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

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

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

Agreed.

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

yeah, I think we should follow that way.

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

fixing...

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

Next big merge will be integration work with VFIO/mdev framework. Both VFIO/mdev
and our GVT-g device model work are for 4.10. Currently we already have working
patch sets internally based on newest VFIO/mdev v9 series. We'd like to put
a topic branch this week to be reviewed by VFIO community to make sure everything
work as designed.

I think a TODO file might help us to track left issues, will consider that.

> 
> > * GVT-g bug management. Do you have something set up already? Would be
> >   great to be able to use https://bugs.freedesktop.org so we could
> >   reassign between i915 and GVT-g.
> 
> +1.

yeah, that's also in our plan, will create new category for GVT-g driver.
Our QA team will handle that.

> 
> > What did I forget/overlook?
> 
> Nothing else crosses my mind, but I'm sure we'll discover more ;-)

Thanks to summarize this! Really help to clarify for other people.

-- 
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: i915 and GTV-g maintenance, workflows and CI

[Chris Wilson]

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

The problem is that gvt is a consumer of our APIs. When I change those I
need reassurance that gvt does not break. We also need reassurance that
when we backmerge from upstream changes to the hva do not break gvt.
-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: i915 and GTV-g maintenance, workflows and CI

[Zhenyu Wang]

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

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

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

-- 
Open Source Technology Center, Intel ltd.

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

[-- 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: i915 and GTV-g maintenance, workflows and CI

[Jani Nikula]

On Thu, 20 Oct 2016, Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote:
>> On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
>> > * GVT-g bug management. Do you have something set up already? Would be
>> >   great to be able to use https://bugs.freedesktop.org so we could
>> >   reassign between i915 and GVT-g.
>> 
>> +1.
>
> yeah, that's also in our plan, will create new category for GVT-g driver.
> Our QA team will handle that.

Please connect them with Martin Peres (CC'd) who'll be able to get this
done.

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