[RFC PATCH 3/7] vfio: add spimdev support

Kenneth Lee liguozhu at hisilicon.com
Thu Aug 2 17:34:40 AEST 2018

On Thu, Aug 02, 2018 at 04:24:22AM +0000, Tian, Kevin wrote:
> Date: Thu, 2 Aug 2018 04:24:22 +0000
> From: "Tian, Kevin" <kevin.tian at intel.com>
> To: Kenneth Lee <liguozhu at hisilicon.com>
> CC: Kenneth Lee <nek.in.cn at gmail.com>, Jonathan Corbet <corbet at lwn.net>,
>  Herbert Xu <herbert at gondor.apana.org.au>, "David S . Miller"
>  <davem at davemloft.net>, Joerg Roedel <joro at 8bytes.org>, Alex Williamson
>  <alex.williamson at redhat.com>, Hao Fang <fanghao11 at huawei.com>, Zhou Wang
>  <wangzhou1 at hisilicon.com>, Zaibo Xu <xuzaibo at huawei.com>, Philippe
>  Ombredanne <pombredanne at nexb.com>, Greg Kroah-Hartman
>  <gregkh at linuxfoundation.org>, Thomas Gleixner <tglx at linutronix.de>,
>  "linux-doc at vger.kernel.org" <linux-doc at vger.kernel.org>,
>  "linux-kernel at vger.kernel.org" <linux-kernel at vger.kernel.org>,
>  "linux-crypto at vger.kernel.org" <linux-crypto at vger.kernel.org>,
>  "iommu at lists.linux-foundation.org" <iommu at lists.linux-foundation.org>,
>  "kvm at vger.kernel.org" <kvm at vger.kernel.org>,
>  "linux-accelerators at lists.ozlabs.org"
>  <linux-accelerators at lists.ozlabs.org>, Lu Baolu
>  <baolu.lu at linux.intel.com>, "Kumar, Sanjay K" <sanjay.k.kumar at intel.com>,
>  "linuxarm at huawei.com" <linuxarm at huawei.com>
> Subject: RE: [RFC PATCH 3/7] vfio: add spimdev support
> Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19129102C at SHSMSX101.ccr.corp.intel.com>
> > From: Kenneth Lee [mailto:liguozhu at hisilicon.com]
> > Sent: Thursday, August 2, 2018 11:47 AM
> > 
> > >
> > > > From: Kenneth Lee
> > > > Sent: Wednesday, August 1, 2018 6:22 PM
> > > >
> > > > From: Kenneth Lee <liguozhu at hisilicon.com>
> > > >
> > > > SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ
> > from
> > > > the general vfio-mdev:
> > > >
> > > > 1. It shares its parent's IOMMU.
> > > > 2. There is no hardware resource attached to the mdev is created. The
> > > > hardware resource (A `queue') is allocated only when the mdev is
> > > > opened.
> > >
> > > Alex has concern on doing so, as pointed out in:
> > >
> > > 	https://www.spinics.net/lists/kvm/msg172652.html
> > >
> > > resource allocation should be reserved at creation time.
> > 
> > Yes. That is why I keep telling that SPIMDEV is not for "VM", it is for "many
> > processes", it is just an access point to the process. Not a device to VM. I
> > hope
> > Alex can accept it:)
> > 
> VFIO is just about assigning device resource to user space. It doesn't care
> whether it's native processes or VM using the device so far. Along the direction
> which you described, looks VFIO needs to support the configuration that
> some mdevs are used for native process only, while others can be used
> for both native and VM. I'm not sure whether there is a clean way to
> enforce it...

I had the same idea at the beginning. But finally I found that the life cycle
of the virtual device for VM and process were different. Consider you create
some mdevs for VM use, you will give all those mdevs to lib-virt, which
distribute those mdev to VMs or containers. If the VM or container exits, the
mdev is returned to the lib-virt and used for next allocation. It is the
administrator who controlled every mdev's allocation.

But for process, it is different. There is no lib-virt in control. The
administrator's intension is to grant some type of application to access the
hardware. The application can get a handle of the hardware, send request and get
the result. That's all. He/She dose not care which mdev is allocated to that
application. If it crashes, it should be the kernel's responsibility to withdraw
the resource, the system administrator does not want to do it by hand.

> Let's hear from Alex's thought.


> Thanks
> Kevin


This e-mail and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed above.
Any use of the 
information contained herein in any way (including, but not limited to, total or
partial disclosure, reproduction, or dissemination) by persons other than the
recipient(s) is prohibited. If you receive this e-mail in error, please notify
the sender by phone or email immediately and delete it!

More information about the Linux-accelerators mailing list