From: Jike Song <jike.song@intel.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: Neo Jia <cjia@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
qemu-devel <qemu-devel@nongnu.org>,
"libvir-list@redhat.com" <libvir-list@redhat.com>,
"bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Xiao, Guangrong" <guangrong.xiao@intel.com>,
"Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: summary of current vfio mdev upstreaming status
Date: Fri, 30 Sep 2016 10:30:28 +0800 [thread overview]
Message-ID: <57EDCE44.5000704@intel.com> (raw)
In-Reply-To: <e61b3fa5-f7dc-04ff-08a8-a229812ee8af@nvidia.com>
On 09/29/2016 06:58 PM, Kirti Wankhede wrote:
>
>
> On 9/29/2016 2:47 PM, Neo Jia wrote:
>> On Thu, Sep 29, 2016 at 04:55:39PM +0800, Jike Song wrote:
>>> Hi all,
>>>
>>> In order to have a clear understanding about the VFIO mdev upstreaming
>>> status, I'd like to summarize it. Please share your opinions on this,
>>> and correct my misunderstandings.
>>>
>>> The whole vfio mdev series can be logically divided into several parts,
>>> they work together to provide the mdev support.
>>
>
> Thanks Jike for summarizing. We already have separate patch for each of
> these logical parts. I had maintained patch sequence in incremental
> depending order.
>
>> Hi Jike,
>>
>> Thanks for summarizing this, but I will defer to Kirti to comment on the actual
>> upstream status of her patches, couples things to note though:
>>
>> 1) iommu type1 patches have been extensively reviewed by Alex already and we
>> have one action item left to implement which is already queued up in v8 patchset.
>>
>
> That's right Neo.
>
I'm talking about v7. Sure before that Alex gave full reviews..
>> 2) regarding the sysfs interface and libvirt discussion, I would like to hear
>> what kind of attributes Intel folks are having so far as Daniel is
>> asking about adding a class "gpu" which will pull several attributes as mandatory.
>>
As Kevin said, no.
>> Thanks,
>> Neo
>>
>>>
>>>
>>>
>>> PART 1: mdev core driver
>>>
>>> [task]
>>> - the mdev bus/device support
>>> - the utilities of mdev lifecycle management
>>> - the physical device register/unregister interfaces
>>>
>>> [status]
>>> - basically agreed by community
>>>
>>>
>>> PART 2: vfio bus driver for mdev
>>>
>>> [task]
>>> - interfaces with vendor drivers
>>> - the vfio bus implementation
>>>
>>> [status]
>>>
>>> - basically agreed by community
>>>
>
> I'm working on v8 version for above patches based on previous discussions.
>
>>>
>>> PART 3: iommu support for mdev
>>>
>>> [task]
>>> - iommu support for mdev
>>>
>>> [status]
>>> - Kirti's v7 implementation, not yet fully reviewed
>>>
>>>
>>> PART 4: sysfs interfaces for mdev
>>>
>>> [task]
>>> - define the hierarchy of minimal sysfs directories/files
>>> - check the validity from vendor drivers, init/de-init them
>>> [status]
>>> - interfaces are in discussion
>>>
>>>
>
> From coding perspective, this is part of mdev core module. I think we
> can't completely separate this part from mdev core module while coding
> it. Yes, this interface is still in discussion and we need to settle
> down on that soon.
>
I Still think it's possible to separate them, but hey, looking forward to
your implementation :)
>>> PART 6: Documentation
>>>
>>> [task]
>>> - clearly document the architecture and interfaces
>>> - coding example for vendor drivers
>>>
>>> [status]
>>> - N/A
>>>
>
> I had tried to maintain the document as per changes going on in above
> patches from v6 onward and will continue to update it for each version
> accordingly.
>
> I had sent out patch with sample driver few hours back wrt v7 patchset.
> And henceforth I'll keep on updating sample driver as per changes in
> mdev modules and add it in my patch series.
Good to know that.
>
> Thanks,
> Kirti
>
--
Thanks,
Jike
WARNING: multiple messages have this Message-ID (diff)
From: Jike Song <jike.song@intel.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: Neo Jia <cjia@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
qemu-devel <qemu-devel@nongnu.org>,
"libvir-list@redhat.com" <libvir-list@redhat.com>,
"bjsdjshi@linux.vnet.ibm.com" <bjsdjshi@linux.vnet.ibm.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"Xiao, Guangrong" <guangrong.xiao@intel.com>,
"Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [Qemu-devel] summary of current vfio mdev upstreaming status
Date: Fri, 30 Sep 2016 10:30:28 +0800 [thread overview]
Message-ID: <57EDCE44.5000704@intel.com> (raw)
In-Reply-To: <e61b3fa5-f7dc-04ff-08a8-a229812ee8af@nvidia.com>
On 09/29/2016 06:58 PM, Kirti Wankhede wrote:
>
>
> On 9/29/2016 2:47 PM, Neo Jia wrote:
>> On Thu, Sep 29, 2016 at 04:55:39PM +0800, Jike Song wrote:
>>> Hi all,
>>>
>>> In order to have a clear understanding about the VFIO mdev upstreaming
>>> status, I'd like to summarize it. Please share your opinions on this,
>>> and correct my misunderstandings.
>>>
>>> The whole vfio mdev series can be logically divided into several parts,
>>> they work together to provide the mdev support.
>>
>
> Thanks Jike for summarizing. We already have separate patch for each of
> these logical parts. I had maintained patch sequence in incremental
> depending order.
>
>> Hi Jike,
>>
>> Thanks for summarizing this, but I will defer to Kirti to comment on the actual
>> upstream status of her patches, couples things to note though:
>>
>> 1) iommu type1 patches have been extensively reviewed by Alex already and we
>> have one action item left to implement which is already queued up in v8 patchset.
>>
>
> That's right Neo.
>
I'm talking about v7. Sure before that Alex gave full reviews..
>> 2) regarding the sysfs interface and libvirt discussion, I would like to hear
>> what kind of attributes Intel folks are having so far as Daniel is
>> asking about adding a class "gpu" which will pull several attributes as mandatory.
>>
As Kevin said, no.
>> Thanks,
>> Neo
>>
>>>
>>>
>>>
>>> PART 1: mdev core driver
>>>
>>> [task]
>>> - the mdev bus/device support
>>> - the utilities of mdev lifecycle management
>>> - the physical device register/unregister interfaces
>>>
>>> [status]
>>> - basically agreed by community
>>>
>>>
>>> PART 2: vfio bus driver for mdev
>>>
>>> [task]
>>> - interfaces with vendor drivers
>>> - the vfio bus implementation
>>>
>>> [status]
>>>
>>> - basically agreed by community
>>>
>
> I'm working on v8 version for above patches based on previous discussions.
>
>>>
>>> PART 3: iommu support for mdev
>>>
>>> [task]
>>> - iommu support for mdev
>>>
>>> [status]
>>> - Kirti's v7 implementation, not yet fully reviewed
>>>
>>>
>>> PART 4: sysfs interfaces for mdev
>>>
>>> [task]
>>> - define the hierarchy of minimal sysfs directories/files
>>> - check the validity from vendor drivers, init/de-init them
>>> [status]
>>> - interfaces are in discussion
>>>
>>>
>
> From coding perspective, this is part of mdev core module. I think we
> can't completely separate this part from mdev core module while coding
> it. Yes, this interface is still in discussion and we need to settle
> down on that soon.
>
I Still think it's possible to separate them, but hey, looking forward to
your implementation :)
>>> PART 6: Documentation
>>>
>>> [task]
>>> - clearly document the architecture and interfaces
>>> - coding example for vendor drivers
>>>
>>> [status]
>>> - N/A
>>>
>
> I had tried to maintain the document as per changes going on in above
> patches from v6 onward and will continue to update it for each version
> accordingly.
>
> I had sent out patch with sample driver few hours back wrt v7 patchset.
> And henceforth I'll keep on updating sample driver as per changes in
> mdev modules and add it in my patch series.
Good to know that.
>
> Thanks,
> Kirti
>
--
Thanks,
Jike
next prev parent reply other threads:[~2016-09-30 2:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 8:55 summary of current vfio mdev upstreaming status Jike Song
2016-09-29 8:55 ` [Qemu-devel] " Jike Song
2016-09-29 9:05 ` Xiao Guangrong
2016-09-29 9:36 ` Neo Jia
2016-09-29 9:46 ` Xiao Guangrong
2016-09-29 11:06 ` Kirti Wankhede
2016-09-29 9:17 ` Neo Jia
2016-09-29 9:17 ` [Qemu-devel] " Neo Jia
2016-09-29 10:58 ` Kirti Wankhede
2016-09-29 10:58 ` [Qemu-devel] " Kirti Wankhede
2016-09-30 2:30 ` Jike Song [this message]
2016-09-30 2:30 ` Jike Song
2016-09-29 14:43 ` Tian, Kevin
2016-09-29 14:43 ` [Qemu-devel] " Tian, Kevin
2016-09-29 11:16 ` Daniel P. Berrange
2016-09-29 11:16 ` [Qemu-devel] " Daniel P. Berrange
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=57EDCE44.5000704@intel.com \
--to=jike.song@intel.com \
--cc=alex.williamson@redhat.com \
--cc=berrange@redhat.com \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=cjia@nvidia.com \
--cc=guangrong.xiao@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=libvir-list@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.