Re: [PATCH v14 00/22] Add Mediated device support

[Alex Williamson]

On Fri, 18 Nov 2016 17:09:59 +0100
Daniel Vetter <daniel@xxxxxxxx> wrote:

> On Fri, Nov 18, 2016 at 4:40 PM, Alex Williamson
> <alex.williamson@xxxxxxxxxx> wrote:
> >> Alex, could you do a pull request of mdev for Daniel's drm-intel tree?
> >> We need to send KVMGT mdev support pull base on that.  
> >
> > No, this is not how I intend or prefer to merge this.  This is a large
> > change for vfio and it is not exclusive to KVMGT.  We have linux-next
> > to facilitate handling dependencies between subsystems during
> > development and a two week merge window to allow managing how these
> > changes enter the mainline tree.  If I were to have this pulled into
> > drm-intel it ties my hands as to how I can manage changes within my
> > functional area.  I want these two weeks of linux-next exposure for
> > vetting the changes and resolving any remaining issues.  I'm not going
> > to compromise my ability to react to such issues.  linux-next inclusion
> > should be sufficient for you to coordinate through the drm tree, though
> > Daniel will need to be made aware of the dependency.  I will however
> > plan to send my pull request to Linus early in the merge window to
> > accommodate dependent changes also being included for v4.10. Hope
> > you understand, thanks,  
> 
> My understanding was that the mdev changes are needed to be able to
> apply the kvmgt stuff, and otherwise it won't build. For that I need a
> stable git tag&pull request (can be specific topic branch, which means
> subsystems can land in any order, or the full subsystem tree, which
> means depencies need to be tracked correctly). I am not going to
> resolve that in the merge window, since in drm we want everything
> lined up _before_ that opens (the feature cutoff is this w/e, but
> there's some wiggle room ofc).
> 
> Sounds like there's just not enough time to line all the things up in
> time for 4.10, and the i915/kmvgt stuff needs to be postponed to 4.11.

My only alternate suggestion is that perhaps the KVMGT code can be
sufficiently partitioned off with #ifdefs that could be removed later,
allowing mdev and KVMGT to be merged independently.  We have only just
added mdev to linux-next, my intention is that the next two weeks are
for finding and correcting issues.  There are still outstanding API
changes, specifically for KVMGT being proposed by Intel included with
that. Thanks,

Alex