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: Wed, 07 Sep 2016 14:42:58 +0800 Message-ID: <57CFB6F2.9030108@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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alex Williamson , 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: Neo Jia Return-path: Received: from mga14.intel.com ([192.55.52.115]:9956 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932402AbcIGGon (ORCPT ); Wed, 7 Sep 2016 02:44:43 -0400 In-Reply-To: <20160907033832.GA12741@nvidia.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- Thanks, Jike From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhWbH-0004E8-Ik for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:44:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhWbE-0001uD-AP for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:44:47 -0400 Received: from mga14.intel.com ([192.55.52.115]:64218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhWbE-0001u1-0Q for qemu-devel@nongnu.org; Wed, 07 Sep 2016 02:44:44 -0400 Message-ID: <57CFB6F2.9030108@intel.com> Date: Wed, 07 Sep 2016 14:42:58 +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> In-Reply-To: <20160907033832.GA12741@nvidia.com> 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: Neo Jia Cc: Alex Williamson , 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/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. -- Thanks, Jike