qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v6-based v1 0/5] refine mdev framework


From: Neo Jia
Subject: Re: [Qemu-devel] [RFC v6-based v1 0/5] refine mdev framework
Date: Wed, 17 Aug 2016 03:09:10 -0700
User-agent: Mutt/1.6.2 (2016-07-01)

On Wed, Aug 17, 2016 at 04:58:14PM +0800, Dong Jia wrote:
> On Tue, 16 Aug 2016 16:14:12 +0800
> Jike Song <address@hidden> 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.

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

Thanks,
Neo

> 
> I'm wondering if Alex and the Nvidia folks have some comments for this
> from their point of views. And I'm really looking forward on their
> feedback.
> 
> Thanks!
> 
> > 
> >     - UUID was removed from the interface between mdev and vendor driver;
> > 
> > 
> > TODO
> > 
> >     remove mdev stuff from vfio.h
> >     update doc
> > 
> 
> 
> --------
> Dong Jia
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]