On Tue, 13 Dec 2016 09:59:58 +0100 Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
