From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jike Song Subject: Re: [RFC v2 0/4] adding mdev bus and vfio support Date: Thu, 08 Sep 2016 16:00:10 +0800 Message-ID: <57D11A8A.1060008@intel.com> References: <1472804172-25542-1-git-send-email-jike.song@intel.com> <20160902090352.53afdab1@t450s.home> <57CF79E2.5060902@intel.com> <20160907033832.GA12741@nvidia.com> <57CFB6F2.9030108@intel.com> <20160907105635.102a8daf@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Neo Jia , kwankhede@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, bjsdjshi@linux.vnet.ibm.com, kevin.tian@intel.com, guangrong.xiao@linux.intel.com, zhenyuw@linux.intel.com, zhiyuan.lv@intel.com, pbonzini@redhat.com, kraxel@redhat.com To: Alex Williamson Return-path: Received: from mga06.intel.com ([134.134.136.31]:43687 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933295AbcIHIB5 (ORCPT ); Thu, 8 Sep 2016 04:01:57 -0400 In-Reply-To: <20160907105635.102a8daf@t450s.home> Sender: kvm-owner@vger.kernel.org List-ID: On 09/08/2016 12:56 AM, Alex Williamson wrote: > On Wed, 07 Sep 2016 14:42:58 +0800 > Jike Song 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 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, > Thanks - We'll try our best to meet that! -- Thanks, Jike From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhuHc-0007Ub-94 for qemu-devel@nongnu.org; Thu, 08 Sep 2016 04:02:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhuHW-0004b5-DZ for qemu-devel@nongnu.org; Thu, 08 Sep 2016 04:02:03 -0400 Received: from mga07.intel.com ([134.134.136.100]:36658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhuHW-0004au-1p for qemu-devel@nongnu.org; Thu, 08 Sep 2016 04:01:58 -0400 Message-ID: <57D11A8A.1060008@intel.com> Date: Thu, 08 Sep 2016 16:00:10 +0800 From: Jike Song MIME-Version: 1.0 References: <1472804172-25542-1-git-send-email-jike.song@intel.com> <20160902090352.53afdab1@t450s.home> <57CF79E2.5060902@intel.com> <20160907033832.GA12741@nvidia.com> <57CFB6F2.9030108@intel.com> <20160907105635.102a8daf@t450s.home> In-Reply-To: <20160907105635.102a8daf@t450s.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 0/4] adding mdev bus and vfio support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Neo Jia , kwankhede@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, bjsdjshi@linux.vnet.ibm.com, kevin.tian@intel.com, guangrong.xiao@linux.intel.com, zhenyuw@linux.intel.com, zhiyuan.lv@intel.com, pbonzini@redhat.com, kraxel@redhat.com On 09/08/2016 12:56 AM, Alex Williamson wrote: > On Wed, 07 Sep 2016 14:42:58 +0800 > Jike Song 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 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, > Thanks - We'll try our best to meet that! -- Thanks, Jike