From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baS0X-0007qS-FW for qemu-devel@nongnu.org; Thu, 18 Aug 2016 14:25:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1baS0T-0007Ae-9P for qemu-devel@nongnu.org; Thu, 18 Aug 2016 14:25:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1baS0T-0007AQ-1E for qemu-devel@nongnu.org; Thu, 18 Aug 2016 14:25:33 -0400 Date: Thu, 18 Aug 2016 12:25:30 -0600 From: Alex Williamson Message-ID: <20160818122530.06c6b39f@t450s.home> In-Reply-To: <20160818164214.62400f83@oc7835276234> References: <1471335257-6226-1-git-send-email-jike.song@intel.com> <20160817165814.531c8823@oc7835276234> <20160817100910.GA1459@nvidia.com> <20160818164214.62400f83@oc7835276234> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v6-based v1 0/5] refine mdev framework List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dong Jia Cc: Neo Jia , Jike Song , kwankhede@nvidia.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com, guangrong.xiao@linux.intel.com, zhenyuw@linux.intel.com, pbonzini@redhat.com, kraxel@redhat.com On Thu, 18 Aug 2016 16:42:14 +0800 Dong Jia wrote: > On Wed, 17 Aug 2016 03:09:10 -0700 > Neo Jia wrote: > > > On Wed, Aug 17, 2016 at 04:58:14PM +0800, Dong Jia wrote: > > > On Tue, 16 Aug 2016 16:14:12 +0800 > > > Jike Song wrote: > > > > > > > > > > > This patchset is based on NVidia's "Add Mediated device support" series, version 6: > > > > > > > > http://www.spinics.net/lists/kvm/msg136472.html > > > > > > > > > > > > Background: > > > > > > > > The patchset from NVidia introduced the Mediated Device support to > > > > Linux/VFIO. With that series, one can create virtual devices (supporting > > > > by underlying physical device and vendor driver), and assign them to > > > > userspace like QEMU/KVM, in the same way as device assignment via VFIO. > > > > > > > > Based on that, NVidia and Intel implemented their vGPU solutions, IBM > > > > implemented its CCW pass-through. However, there are limitations > > > > imposed by current (v6 in particular) mdev framework: the mdev must be > > > > represented as a PCI device, several vfio capabilities such as > > > > sparse mmap are not possible, and so forth. > > > > > > > > This series aims to address above limitations and simplify the implementation. > > > > > > > > > > > > Key Changes: > > > > > > > > - An independent "struct device" was introduced to parent_device, thus > > > > a hierarchy in driver core is formed with physical device, parent device > > > > and mdev device; > > > > > > > > - Leveraging the mechanism and APIs provided by Linux driver core, it > > > > is now safe to remove all refcnts and locks; > > > > > > > > - vfio_mpci (later renamed to vfio_mdev) was made BUS-agnostic: all > > > > PCI-specific logic was removed, accesses from userspace are now > > > > passed to vendor driver directly, thus guaranteed that full VFIO > > > > capabilities provided: e.g. dynamic regions, sparse mmap, etc.; > > > > > > > > With vfio_mdev being BUS-agnostic, it is enough to have only one > > > > driver for all mdev devices; > > > > > > Hi Jike: > > > > > > I don't know what happened, but finding out which direction this will > > > likely go seems my first priority now... > > > > Hi Dong, > > > > Just want to let you know that we are preparing the v7 patches to incorporate > > the latest review comments from Intel folks and Alex, for some changes in this > > patch set also mentioned in the recent review are already queued up in the new > > version. > Hi Neo, > > Good to know this. :> > > > > > > > > > I'd say, either with only the original mdev v6, or patched this series, > > > vfio-ccw could live. But this series saves my work of mimicing the > > > vfio-mpci code in my vfio-mccw driver. I like this incremental patches. > > > > Thanks for sharing your progress and good to know our current v6 solution works > > for you. We are still evaluating the vfio_mdev changes here as I still prefer to > > share general VFIO pci handling inside a common VFIO PCI driver, and the > > modularization will reduce the impact of future changes and potential regressions > > cross architectures - between PCI and CCW. > If this is something that Alex and the Intel folks are fine with, I have > no problem with this too. Thanks, Overall, I like this a lot. Creating a proper device hierarchy and letting the driver core manage the references makes a lot of sense and the reduction in code volume and complexity speaks for itself. I like how the PCI mdev layer goes away, we're not imposing arbitrary restrictions on the vendor driver in an attempt to insert a common layer. We can add helpers for things that do end up being common as we go. Using devices rather than uuids for functions is a big improvement. I hope that Neo and Kirti will incorporate many of these changes in their next revision. Thanks for stepping in with this, Alex