linux-kernel - Re: [git pull] drm tree for 4.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20161213084717.6e006382@t450s.home>
Date:   Tue, 13 Dec 2016 08:47:17 -0700
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Dave Airlie <airlied@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm tree for 4.10

On Tue, 13 Dec 2016 09:59:58 +0100
Daniel Vetter <daniel@...ll.ch> wrote:

> On Tue, Dec 13, 2016 at 03:20:07PM +1000, Dave Airlie wrote:
> > Hi Linus,
> > 
> > This is the main drm pull request for the 4.10. Posting it early as I'm probably
> > on holidays for next few days.
> > 
> > Items of note:
> > There is a big chunk of AMD register headers in here that bumps the
> > size quite a bit.
> > Renaming the dma-buf fence to dma_fence which is a more apt naming.
> > drm-misc (tree below me) has moved to group committer model, I'm for
> > now not part of the group to maintain a level of abstraction.
> > i915 has merged a lot of the GVT device support (virtualised i915) -
> > don't think it's all there yet.
> > but there are some kvm changes from the GVT code, I think you may get
> > these via another tree, so feel free to hold this pull request, I'm
> > sure I was told they were on a stable base.  
> 
> Yeah they're all proper cross-subsystem pulls/merges of a stable topic
> branch with just the bits needed for gvt. Unfortunately there's a few more
> vfio patches, and for those Alex refused to do a proper topic branch,
> instead telling me that the right way to resolve that is within the merge
> window. Well amusing after a room full of maintainers told me I surely
> don't know how to do topic branches to handle deps, but it means you'll
> get another late gvt pull with (iirc) 3 patches, once the vfio stuff has
> landed. Since Dave is already in vacation mode I think I'll just forward
> that pull thru to you directly.

Let me see if I can explain.  The new mediated device support added to
vfio for v4.10 intends to allow software defined virtual devices to be
exposed through the vfio API to userspace.  Intel KVM-GT is only one of
three initial immediate users.  Also, while I value the input that
Intel engineers provided in the course of development of this feature,
Intel is not the primary developer.  We specifically scheduled
development of this feature in order to provide multiple weeks of
exposure and testing in linux-next prior to the v4.10 merge window.
Thus, when Intel asked that I send a pull request to Daniel
_immediately_ upon my acceptance of the patch series, with an
outstanding interface specifically for KVM-GT still pending and zero
exposure to the testing performed externally on linux-next, I felt the
prudent choice was to refuse.  I lose some degree of control in the
future of my own space by prematurely sending pull requests to other
maintainers, which I didn't feel was justified here.

I have already sent a pull request to Linus for the vfio changes, I sent
it last week, just prior to the merge window opening.  I would very
much like to have KVM-GT support for v4.10, but I still don't think it
was a reasonable request to ask me to discard the time that we had
planned into the vfio schedule for testing and upstream feedback, such
that I could hand off the changes with a focus only on this one use
case.  Thanks,

Alex