All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Jike Song <jike.song@intel.com>
Cc: Neo Jia <cjia@nvidia.com>,
	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
Subject: Re: [RFC v2 0/4] adding mdev bus and vfio support
Date: Wed, 7 Sep 2016 10:56:35 -0600	[thread overview]
Message-ID: <20160907105635.102a8daf@t450s.home> (raw)
In-Reply-To: <57CFB6F2.9030108@intel.com>

On Wed, 07 Sep 2016 14:42:58 +0800
Jike Song <jike.song@intel.com> 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@intel.com> 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

WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Jike Song <jike.song@intel.com>
Cc: Neo Jia <cjia@nvidia.com>,
	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
Subject: Re: [Qemu-devel] [RFC v2 0/4] adding mdev bus and vfio support
Date: Wed, 7 Sep 2016 10:56:35 -0600	[thread overview]
Message-ID: <20160907105635.102a8daf@t450s.home> (raw)
In-Reply-To: <57CFB6F2.9030108@intel.com>

On Wed, 07 Sep 2016 14:42:58 +0800
Jike Song <jike.song@intel.com> 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@intel.com> 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

  reply	other threads:[~2016-09-07 16:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02  8:16 [RFC v2 0/4] adding mdev bus and vfio support Jike Song
2016-09-02  8:16 ` [Qemu-devel] " Jike Song
2016-09-02  8:16 ` [RFC v2 1/4] Mediated device Core driver Jike Song
2016-09-02  8:16   ` [Qemu-devel] " Jike Song
2016-09-02  8:16 ` [RFC v2 2/4] vfio: VFIO bus driver for MDEV devices Jike Song
2016-09-02  8:16   ` [Qemu-devel] " Jike Song
2016-09-02  8:16 ` [RFC v2 3/4] vfio iommu: Add support for mediated devices Jike Song
2016-09-02  8:16   ` [Qemu-devel] " Jike Song
2016-09-02  8:16 ` [RFC v2 4/4] docs: Add Documentation for Mediated devices Jike Song
2016-09-02  8:16   ` [Qemu-devel] " Jike Song
2016-09-02 22:09   ` Eric Blake
2016-09-02 22:09     ` Eric Blake
2016-09-02 23:30     ` Neo Jia
2016-09-02 23:30       ` Neo Jia
2016-09-02 15:03 ` [RFC v2 0/4] adding mdev bus and vfio support Alex Williamson
2016-09-02 15:03   ` [Qemu-devel] " Alex Williamson
2016-09-02 20:05   ` Neo Jia
2016-09-02 20:05     ` [Qemu-devel] " Neo Jia
2016-09-07  2:22   ` Jike Song
2016-09-07  2:22     ` [Qemu-devel] " Jike Song
2016-09-07  3:38     ` Neo Jia
2016-09-07  3:38       ` [Qemu-devel] " Neo Jia
2016-09-07  6:42       ` Jike Song
2016-09-07  6:42         ` [Qemu-devel] " Jike Song
2016-09-07 16:56         ` Alex Williamson [this message]
2016-09-07 16:56           ` Alex Williamson
2016-09-08  8:00           ` Jike Song
2016-09-08  8:00             ` [Qemu-devel] " Jike Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160907105635.102a8daf@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=cjia@nvidia.com \
    --cc=guangrong.xiao@linux.intel.com \
    --cc=jike.song@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhiyuan.lv@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.