On Thu, 7 Dec 2017 13:55:33 +0100 Pierre Morel <pmo...@linux.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.william...@redhat.com; eric.au...@redhat.com; > >> pmo...@linux.vnet.ibm.com > >> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm > >> <linux...@huawei.com>; Shameerali Kolothum Thodi > >> <shameerali.kolothum.th...@huawei.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
