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

[Cornelia Huck]

On Thu, 2 Aug 2018 15:34:40 +0800
Kenneth Lee <liguozhu at hisilicon.com> wrote:

> On Thu, Aug 02, 2018 at 04:24:22AM +0000, Tian, Kevin wrote:

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

I don't think that you should distinguish the cases by the presence of
a management application. How can the mdev driver know what the
intention behind using the device is?

Would it make more sense to use a different mechanism to enforce that
applications only use those handles they are supposed to use? Maybe
cgroups? I don't think it's a good idea to push usage policy into the
kernel.

[I have not read the documentation, so I may be totally off on the
intended use of this.]