summary of current vfio mdev upstreaming status

summary of current vfio mdev upstreaming status

[Jike Song]

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.



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


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


PART 6: Documentation

	[task]
		-	clearly document the architecture and interfaces
		-	coding example for vendor drivers

	[status]
		-	N/A


What I'm curious here is 'PART 4', which is needed by other parts to
perform further steps, is it possible to accelerate the process somehow? :-)


--
Thanks,
Jike

[Qemu-devel] summary of current vfio mdev upstreaming status

[Jike Song]

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.



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


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


PART 6: Documentation

	[task]
		-	clearly document the architecture and interfaces
		-	coding example for vendor drivers

	[status]
		-	N/A


What I'm curious here is 'PART 4', which is needed by other parts to
perform further steps, is it possible to accelerate the process somehow? :-)


--
Thanks,
Jike

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Xiao Guangrong]

On 09/29/2016 04:55 PM, 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.

I think what Jike want to suggest is how about partially push/develop the
mdev. As jike listed, there are some parts can be independent and they have
mostly been agreed.

Such development plan can make the discussion be much efficient in the
community. Also it make the possibility that Intel, Nvdia, IBM can focus
on different parts and co-develop it.

The maintainer can hold these development patches in local branch before
pushing the full-functionality version to upstream.

Thanks!

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Neo Jia]

On Thu, Sep 29, 2016 at 05:05:47PM +0800, Xiao Guangrong wrote:
> 
> 
> On 09/29/2016 04:55 PM, 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.
> 
> I think what Jike want to suggest is how about partially push/develop the
> mdev. As jike listed, there are some parts can be independent and they have
> mostly been agreed.
> 
> Such development plan can make the discussion be much efficient in the
> community. Also it make the possibility that Intel, Nvdia, IBM can focus
> on different parts and co-develop it.

Hi Guangrong,

JFYI. we are preparing v8 patches to accommodate most comments we have discussed
so far and we will also include several things that we have decided on sysfs.

I definitely would like to see more interactive discussions especially on the
sysfs class front from intel folks.

Regarding the patch development and given the current status, especially where
we are and what we have been through, I am very confident that we should be able
to fully handle this ourselves, but thanks for offering help anyway!

We should be able to react as fast as possible based on the public mailing list
discussions, so again I don't think that part is an issue.

Thanks,
Neo

> 
> The maintainer can hold these development patches in local branch before
> pushing the full-functionality version to upstream.
> 
> Thanks!
> 
> 

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Xiao Guangrong]

On 09/29/2016 05:36 PM, Neo Jia wrote:
> On Thu, Sep 29, 2016 at 05:05:47PM +0800, Xiao Guangrong wrote:
>>
>>
>> On 09/29/2016 04:55 PM, 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.
>>
>> I think what Jike want to suggest is how about partially push/develop the
>> mdev. As jike listed, there are some parts can be independent and they have
>> mostly been agreed.
>>
>> Such development plan can make the discussion be much efficient in the
>> community. Also it make the possibility that Intel, Nvdia, IBM can focus
>> on different parts and co-develop it.
>
> Hi Guangrong,
>
> JFYI. we are preparing v8 patches to accommodate most comments we have discussed
> so far and we will also include several things that we have decided on sysfs.
>
> I definitely would like to see more interactive discussions especially on the
> sysfs class front from intel folks.
>
> Regarding the patch development and given the current status, especially where
> we are and what we have been through, I am very confident that we should be able
> to fully handle this ourselves, but thanks for offering help anyway!
>
> We should be able to react as fast as possible based on the public mailing list
> discussions, so again I don't think that part is an issue.

We understand the progress goes okay. However, splitting such big patchset
into small parts is a better way to push large code to upstream - it is
better for review and validation and we can quickly iterate the code if
there are new issues exposed during the review of new version.

Particularly, based on the current situation that the sysfs interfaces are
far from the way to be decided, it is definitely a good idea to push the
basic infrastructure first, later let's focal on the ABI part - sysfs
interface design.

Thanks!

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Kirti Wankhede]

On 9/29/2016 3:16 PM, Xiao Guangrong wrote:
> 
> 
> On 09/29/2016 05:36 PM, Neo Jia wrote:
>> On Thu, Sep 29, 2016 at 05:05:47PM +0800, Xiao Guangrong wrote:
>>>
>>>
>>> On 09/29/2016 04:55 PM, 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.
>>>
>>> I think what Jike want to suggest is how about partially push/develop
>>> the
>>> mdev. As jike listed, there are some parts can be independent and
>>> they have
>>> mostly been agreed.
>>>
>>> Such development plan can make the discussion be much efficient in the
>>> community. Also it make the possibility that Intel, Nvdia, IBM can focus
>>> on different parts and co-develop it.
>>
>> Hi Guangrong,
>>
>> JFYI. we are preparing v8 patches to accommodate most comments we have
>> discussed
>> so far and we will also include several things that we have decided on
>> sysfs.
>>
>> I definitely would like to see more interactive discussions especially
>> on the
>> sysfs class front from intel folks.
>>
>> Regarding the patch development and given the current status,
>> especially where
>> we are and what we have been through, I am very confident that we
>> should be able
>> to fully handle this ourselves, but thanks for offering help anyway!
>>
>> We should be able to react as fast as possible based on the public
>> mailing list
>> discussions, so again I don't think that part is an issue.
> 
> We understand the progress goes okay. However, splitting such big patchset
> into small parts is a better way to push large code to upstream - it is
> better for review and validation and we can quickly iterate the code if
> there are new issues exposed during the review of new version.
> 
> Particularly, based on the current situation that the sysfs interfaces are
> far from the way to be decided, it is definitely a good idea to push the
> basic infrastructure first, later let's focal on the ABI part - sysfs
> interface design.
> 

Yes, we will have v8 series soon out for review even if sysfs interface
discussion is not settled down to get other pieces reviewed and tested.
In this patch set, we will have basic set of sysfs interface which we
all have agreed on until now like 'create' and 'remove'.

Thanks,
Kirti

Re: summary of current vfio mdev upstreaming status

[Neo Jia]

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.

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.

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.

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
> 
> 
> 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
> 
> 
> PART 6: Documentation
> 
> 	[task]
> 		-	clearly document the architecture and interfaces
> 		-	coding example for vendor drivers
> 
> 	[status]
> 		-	N/A
> 
> 
> What I'm curious here is 'PART 4', which is needed by other parts to
> perform further steps, is it possible to accelerate the process somehow? :-)
> 
> 
> --
> Thanks,
> Jike
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Neo Jia]

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.

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.

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.

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
> 
> 
> 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
> 
> 
> PART 6: Documentation
> 
> 	[task]
> 		-	clearly document the architecture and interfaces
> 		-	coding example for vendor drivers
> 
> 	[status]
> 		-	N/A
> 
> 
> What I'm curious here is 'PART 4', which is needed by other parts to
> perform further steps, is it possible to accelerate the process somehow? :-)
> 
> 
> --
> Thanks,
> Jike
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: summary of current vfio mdev upstreaming status

[Kirti Wankhede]

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.

> 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.
> 
> 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.

>> 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.

Thanks,
Kirti

>>
>> What I'm curious here is 'PART 4', which is needed by other parts to
>> perform further steps, is it possible to accelerate the process somehow? :-)
>>
>>
>> --
>> Thanks,
>> Jike
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Kirti Wankhede]

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.

> 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.
> 
> 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.

>> 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.

Thanks,
Kirti

>>
>> What I'm curious here is 'PART 4', which is needed by other parts to
>> perform further steps, is it possible to accelerate the process somehow? :-)
>>
>>
>> --
>> Thanks,
>> Jike
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: summary of current vfio mdev upstreaming status

[Jike Song]

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

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Jike Song]

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

RE: summary of current vfio mdev upstreaming status

[Tian, Kevin]

> From: Neo Jia [mailto:cjia@nvidia.com]
> Sent: Thursday, September 29, 2016 5:17 PM
> 
> 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.
> 
> 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.
> 
> 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.
> 

I have replied to Daniel that Intel doesn't plan to support those attributes. 
We think default mdev attributes are enough for our requirements. You
may put them into 'description' attribute for informative purpose...

If both sides agree this assumption, along with Kirti's reply that you don't
require grouping mdev any more, it'd be more promising of pushing whole
mdev bits to upstream then. :-)

Thanks
Kevin

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Tian, Kevin]

> From: Neo Jia [mailto:cjia@nvidia.com]
> Sent: Thursday, September 29, 2016 5:17 PM
> 
> 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.
> 
> 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.
> 
> 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.
> 

I have replied to Daniel that Intel doesn't plan to support those attributes. 
We think default mdev attributes are enough for our requirements. You
may put them into 'description' attribute for informative purpose...

If both sides agree this assumption, along with Kirti's reply that you don't
require grouping mdev any more, it'd be more promising of pushing whole
mdev bits to upstream then. :-)

Thanks
Kevin

Re: summary of current vfio mdev upstreaming status

[Daniel P. Berrange]

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.
> 
> 
> 
> 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
> 
> 
> 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
> 
> 
> PART 6: Documentation
> 
> 	[task]
> 		-	clearly document the architecture and interfaces
> 		-	coding example for vendor drivers
> 
> 	[status]
> 		-	N/A
>

IMHO documentation should really be near the front as that's spelling out
the design. The implementation patches are then reviewed in reference to
the design documentation.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

[Daniel P. Berrange]

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.
> 
> 
> 
> 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
> 
> 
> 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
> 
> 
> PART 6: Documentation
> 
> 	[task]
> 		-	clearly document the architecture and interfaces
> 		-	coding example for vendor drivers
> 
> 	[status]
> 		-	N/A
>

IMHO documentation should really be near the front as that's spelling out
the design. The implementation patches are then reviewed in reference to
the design documentation.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|