public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jike Song <jike.song@intel.com>
To: Neo Jia <cjia@nvidia.com>
Cc: Alex Williamson <alex.williamson@redhat.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, 07 Sep 2016 14:42:58 +0800	[thread overview]
Message-ID: <57CFB6F2.9030108@intel.com> (raw)
In-Reply-To: <20160907033832.GA12741@nvidia.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 <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.


--
Thanks,
Jike

  reply	other threads:[~2016-09-07  6:44 UTC|newest]

Thread overview: 14+ 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 ` [RFC v2 1/4] Mediated device Core driver 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 ` [RFC v2 3/4] vfio iommu: Add support for mediated devices Jike Song
2016-09-02  8:16 ` [RFC v2 4/4] docs: Add Documentation for Mediated devices Jike Song
2016-09-02 22:09   ` [Qemu-devel] " Eric Blake
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 20:05   ` Neo Jia
2016-09-07  2:22   ` Jike Song
2016-09-07  3:38     ` Neo Jia
2016-09-07  6:42       ` Jike Song [this message]
2016-09-07 16:56         ` Alex Williamson
2016-09-08  8:00           ` 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=57CFB6F2.9030108@intel.com \
    --to=jike.song@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=cjia@nvidia.com \
    --cc=guangrong.xiao@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox