From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jike Song Subject: summary of current vfio mdev upstreaming status Date: Thu, 29 Sep 2016 16:55:39 +0800 Message-ID: <57ECD70B.1080205@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , "kvm@vger.kernel.org" , qemu-devel , "libvir-list@redhat.com" , "bjsdjshi@linux.vnet.ibm.com" , "Tian, Kevin" , "Xiao, Guangrong" , "Daniel P. Berrange" To: Alex Williamson , Neo Jia , Kirti Wankhede Return-path: Received: from mga09.intel.com ([134.134.136.24]:3893 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932380AbcI2I6F (ORCPT ); Thu, 29 Sep 2016 04:58:05 -0400 Sender: kvm-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpXAU-0005kn-Lt for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:58:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpXAL-0005a8-9I for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:58:09 -0400 Received: from mga04.intel.com ([192.55.52.120]:39832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpXAL-0005a3-36 for qemu-devel@nongnu.org; Thu, 29 Sep 2016 04:58:05 -0400 Message-ID: <57ECD70B.1080205@intel.com> Date: Thu, 29 Sep 2016 16:55:39 +0800 From: Jike Song MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] summary of current vfio mdev upstreaming status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson , Neo Jia , Kirti Wankhede Cc: Paolo Bonzini , "kvm@vger.kernel.org" , qemu-devel , "libvir-list@redhat.com" , "bjsdjshi@linux.vnet.ibm.com" , "Tian, Kevin" , "Xiao, Guangrong" , "Daniel P. Berrange" 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