* i915 and GTV-g maintenance, workflows and CI @ 2016-10-20 9:02 Jani Nikula 2016-10-20 9:24 ` Daniel Vetter 0 siblings, 1 reply; 6+ messages in thread From: Jani Nikula @ 2016-10-20 9:02 UTC (permalink / raw) To: intel-gfx, igvt-g-dev, Zhenyu Wang, Zhi Wang, Daniel Vetter Cc: Xu, Terrence, Nikkanen, Kimmo, Lv, Zhiyuan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i915 and GTV-g maintenance, workflows and CI 2016-10-20 9:02 i915 and GTV-g maintenance, workflows and CI Jani Nikula @ 2016-10-20 9:24 ` Daniel Vetter 2016-10-20 9:42 ` Zhenyu Wang 0 siblings, 1 reply; 6+ messages in thread From: Daniel Vetter @ 2016-10-20 9:24 UTC (permalink / raw) To: Jani Nikula Cc: Nikkanen, Kimmo, intel-gfx, Xu, Terrence, igvt-g-dev, Daniel Vetter, Lv, Zhiyuan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i915 and GTV-g maintenance, workflows and CI 2016-10-20 9:24 ` Daniel Vetter @ 2016-10-20 9:42 ` Zhenyu Wang 2016-10-20 10:01 ` Chris Wilson 2016-10-20 10:55 ` Jani Nikula 0 siblings, 2 replies; 6+ messages in thread From: Zhenyu Wang @ 2016-10-20 9:42 UTC (permalink / raw) To: Daniel Vetter Cc: Nikkanen, Kimmo, Jani Nikula, intel-gfx, Xu, Terrence, igvt-g-dev, Daniel Vetter, Lv, Zhiyuan [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i915 and GTV-g maintenance, workflows and CI 2016-10-20 9:42 ` Zhenyu Wang @ 2016-10-20 10:01 ` Chris Wilson 2016-10-20 10:34 ` Zhenyu Wang 2016-10-20 10:55 ` Jani Nikula 1 sibling, 1 reply; 6+ messages in thread From: Chris Wilson @ 2016-10-20 10:01 UTC (permalink / raw) To: Zhenyu Wang Cc: Nikkanen, Kimmo, Jani Nikula, intel-gfx, Xu, Terrence, igvt-g-dev, Daniel Vetter, Lv, Zhiyuan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i915 and GTV-g maintenance, workflows and CI 2016-10-20 10:01 ` Chris Wilson @ 2016-10-20 10:34 ` Zhenyu Wang 0 siblings, 0 replies; 6+ messages in thread From: Zhenyu Wang @ 2016-10-20 10:34 UTC (permalink / raw) To: Chris Wilson, Zhenyu Wang, Daniel Vetter, Nikkanen, Kimmo, Jani Nikula, intel-gfx, Xu, Terrence, igvt-g-dev, Daniel Vetter, Lv, Zhiyuan [-- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: i915 and GTV-g maintenance, workflows and CI 2016-10-20 9:42 ` Zhenyu Wang 2016-10-20 10:01 ` Chris Wilson @ 2016-10-20 10:55 ` Jani Nikula 1 sibling, 0 replies; 6+ messages in thread From: Jani Nikula @ 2016-10-20 10:55 UTC (permalink / raw) To: Zhenyu Wang, Daniel Vetter Cc: Nikkanen, Kimmo, intel-gfx, Xu, Terrence, igvt-g-dev, Daniel Vetter, Lv, Zhiyuan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-20 10:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-20 9:02 i915 and GTV-g maintenance, workflows and CI Jani Nikula 2016-10-20 9:24 ` Daniel Vetter 2016-10-20 9:42 ` Zhenyu Wang 2016-10-20 10:01 ` Chris Wilson 2016-10-20 10:34 ` Zhenyu Wang 2016-10-20 10:55 ` Jani Nikula
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox