On Wed, 07 Sep 2016 14:42:58 +0800 Jike Song <jike.song@xxxxxxxxx> wrote: > On 09/07/2016 11:38 AM, Neo Jia wrote: > > On Wed, Sep 07, 2016 at 10:22:26AM +0800, Jike Song wrote: > >> On 09/02/2016 11:03 PM, Alex Williamson wrote: > >>> On Fri, 2 Sep 2016 16:16:08 +0800 > >>> Jike Song <jike.song@xxxxxxxxx> wrote: > >>> > >>>> This patchset is based on NVidia's "Add Mediated device support" series, version 6: > >>>> > >>>> http://www.spinics.net/lists/kvm/msg136472.html > >>> > >>> > >>> Hi Jike, > >>> > >>> I'm thrilled by your active participation here, but I'm confused which > >>> versions I should be reviewing and where the primary development is > >>> going. Kirti sent v7 a week ago, so I would have expected a revision > >>> based on that rather than a re-write based on v6 plus incorporation of a > >>> few of Kirti's patches directly. > >> > >> Hi Alex, > >> > >> [Sorry! replied this on Monday but it was silently dropped by the our firewall] > >> > >> > >> > >> The v1 of this patchset was send as incremental ones, basing on Nvidia's v6, to > >> demonstrate how is it possible and beneficial to: > >> > >> 1, Introduce an independent device between physical and mdev; > >> 2, Simplify vfio-mdev and make it the most flexible for vendor drivers; > >> > >> Unfortunately neither was understood or adopted in v7: > >> > >> http://www.spinics.net/lists/kvm/msg137081.html > >> > >> So here came the v2, as a standalone series, to give a whole and straight > >> demonstration. The reason of still basing on v6: > >> > >> - Addressed all v6 comments (except the iommu part); > >> - There is no comments yet for v7 (except the sysfs ones); > >> > >> > >> > >>> I liked the last version of these > >>> changes a lot, but we need to figure out how to combine development > >>> because we do not have infinite cycles for review available :-\ Thanks! > >> > >> Fully understand. > >> > >> Here is the dilemma: v6 is an obsolete version to work upon, v7 is still not > >> at the direction we prefer. > > > > Hi Jike, > > > > I wish I could meet you in person in KVM forum couple weeks ago so we can have a > > better discussion. > > I wish I could have that opportunity, too! > > > We are trying our best to accommodate almost all requirements / comments from > > use cases and code reviews while keeping little (or none) architectural changes > > between revisions. > > Yes I saw that, there was little architectural change from v6 to v7, > that's what I will argue for :) > > >> We would be highly glad and thankful if Neo/Kirti > >> would adopt the code in their next version, which will certainly form a > >> more simple and consolidated base for future co-development; otherwise > >> and we could at least discuss the concerns, in case of any. > >> > > > > As I have said in my previous response to you, if you have any questions about > > adopting the framework that we have developed, you are very welcome to > > comment/speak out on the code review thread like others. And if it is reasonable > > request and won't break other vendors' use case, we will adopt it (one example > > is the online file and removing the mdev pci dependency). > > > > Not limited to having questions about adoption, right? :) > > We do think the framework itself had too much unnecessary logic and > imposed limitations to vendor drivers, also it's clearly possible to be > simplified. > > > Just some update for you regarding the v7 patches, currently we are very > > actively trying to lock down the sysfs and management interfaces discussion. > > > > So, if you would like to make the upstream happen sooner, please join us in the > > v7 and following patch discussion instead of rewriting them. > > > > So as you said, I would comment on the v7 series to propose both architectural > and implementation changes, hoping this will help more. Please do, I definitely like where you're heading and I want to see Kirti and Neo include your ideas. The challenge is to try to focus our efforts into a single development stream. Please continue to comment and even submit patches, but let's consider NVIDIA's latest patches to be the main development stream and request changes against that. As you would do upstream, propose changes in small increments where we can evaluate each step. It's very difficult for Neo and Kirti to incorporate bulk rewrites. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
