Message-ID: <20171207113719.76c731ba@t450s.home>
Date:   Thu, 7 Dec 2017 11:37:19 -0700
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Pierre Morel <pmorel@...ux.vnet.ibm.com>
Cc:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>
Subject: Re: [RFC] vfio/type1: Add IOVA_RANGE capability support

On Thu, 7 Dec 2017 13:55:33 +0100
Pierre Morel <pmorel@...ux.vnet.ibm.com> wrote:

> On 06/12/2017 17:15, Shameerali Kolothum Thodi wrote:
> > Hi Pierre,
> >   
> >> -----Original Message-----
> >> From: Shameerali Kolothum Thodi
> >> Sent: Wednesday, December 06, 2017 4:08 PM
> >> To: alex.williamson@...hat.com; eric.auger@...hat.com;
> >> pmorel@...ux.vnet.ibm.com
> >> Cc: kvm@...r.kernel.org; linux-kernel@...r.kernel.org; Linuxarm
> >> <linuxarm@...wei.com>; Shameerali Kolothum Thodi
> >> <shameerali.kolothum.thodi@...wei.com>
> >> Subject: [RFC] vfio/type1: Add IOVA_RANGE capability support
> >>
> >> This patch allows the user-space to retrieve the supported
> >> IOVA range(s), excluding any reserved regions. The implementation
> >> is based on capability chains, added to the VFIO_IOMMU_GET_INFO ioctl.
> >>
> >> This is following the discussions here[1] and is based on the RFC patch[2].
> >>
> >> ToDo:
> >>   - This currently derives the default supported iova range from the first
> >>     iommu domain. This needs to be changed to go through the domain_list
> >>     instead.
> >>   - Sync with Pierre's patch[3].  
> > 
> > Thanks to Eric[1], came to know that you have posted a patch to retrieve the
> > iommu aperture info. This RFC does a similar thing but try to take care of
> > any reserved regions and adds to the capability chain.
> > 
> > Please take a look and if there is a possibility to sync up your next revision
> > and this, please let me know.  
> 
> Hi Shameer,
> 
> Indeed it is close to what I was developing.
> 
> I have a single concern, the aperture is strongly hardware related while 
> reserved areas are much more flexible.
> 
> As a consequence, I think it would be better if they were handled in 
> separate capabilities and let the user space decide if it wants to know 
> about one or the other.
> 
> For my immediate needs, this patch would be OK since we (s390x) do not 
> use reserved regions.
> 
> @Alex: what do you prefer
> If we need two capabilities, I will send the patch serie I made on the 
> aperture capability for VFIO IOMMU.
> If not I will use Shameer's patch.

I think your suggestion boils down to mirroring the IOMMU API of
exposing base geometry and reserved ranges more directly to userspace.
I don't think that creates a stable user API.  Users would need to be
updated in lockstep for new types of reserved ranges in order to
exclude them from the base geometry.  The vfio kernel code (proposed
in this patch) can be updated in lockstep as it is part of the kernel.
Therefore the idea here is that this capability exposes only apertures
which are available for standard IOVA map and unmap requests.  It's
vfio in the host kernel that's responsible for pruning out new reserved
types.

Beyond that, we can certainly add new capabilities that identify
certain types of reserved areas within the IOVA gaps of the above
capability.  This allows the vfio API to be extended in a compatible
way for users, the IOVA ranges capability accounts for all types of
special ranges that aren't available for standard IOVA mappings and
address limitations of the IOMMU itself, then new capabilities can be
added if there's a need to expose specific types of excluded ranges to
the user.  Thanks,

Alex

Powered by blists - more mailing lists