All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Jike Song <jike.song@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Neo Jia <cjia@nvidia.com>, Kirti Wankhede <kwankhede@nvidia.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>
Subject: Re: summary of current vfio mdev upstreaming status
Date: Thu, 29 Sep 2016 12:16:31 +0100	[thread overview]
Message-ID: <20160929111631.GO5312@redhat.com> (raw)
In-Reply-To: <57ECD70B.1080205@intel.com>

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/ :|

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Jike Song <jike.song@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Neo Jia <cjia@nvidia.com>, Kirti Wankhede <kwankhede@nvidia.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>
Subject: Re: [Qemu-devel] summary of current vfio mdev upstreaming status
Date: Thu, 29 Sep 2016 12:16:31 +0100	[thread overview]
Message-ID: <20160929111631.GO5312@redhat.com> (raw)
In-Reply-To: <57ECD70B.1080205@intel.com>

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/ :|

  parent reply	other threads:[~2016-09-29 11:16 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
2016-09-30  2:30       ` [Qemu-devel] " 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 [this message]
2016-09-29 11:16   ` 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=20160929111631.GO5312@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=cjia@nvidia.com \
    --cc=guangrong.xiao@intel.com \
    --cc=jike.song@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.