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: Dong Jia
Subject: Re: [Qemu-devel] [RFC v6-based v1 0/5] refine mdev framework
Date: Thu, 18 Aug 2016 16:42:14 +0800

On Wed, 17 Aug 2016 03:09:10 -0700
Neo Jia <address@hidden> 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 <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.
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,

> 
> Thanks,
> Neo

[...]

--------
Dong Jia




reply via email to

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