[lkml]   [2018]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH v4 0/6] vfio/type1: Add support for valid iova list management
This series introduces an iova list associated with a vfio 
iommu. The list is kept updated taking care of iommu apertures,
and reserved regions. Also this series adds checks for any conflict
with existing dma mappings whenever a new device group is attached to
the domain.

User-space can retrieve valid iova ranges using VFIO_IOMMU_GET_INFO
ioctl capability chains. Any dma map request outside the valid iova
range will be rejected.

v3 --> v4
Addressed comments received for v3.
-dma_addr_t instead of phys_addr_t
-LIST_HEAD() usage.
-Free up iova_copy list in case of error.
-updated logic in filling the iova caps info(patch #5)

RFCv2 --> v3
Removed RFC tag.
Addressed comments from Alex and Eric:
- Added comments to make iova list management logic more clear.
- Use of iova list copy so that original is not altered in
case of failure.

RFCv1 --> RFCv2
Addressed comments from Alex:
-Introduced IOVA list management and added checks for conflicts with
existing dma map entries during attach/detach.

Shameer Kolothum (6):
vfio/type1: Introduce iova list and add iommu aperture validity check
vfio/type1: Check reserve region conflict and update iova list
vfio/type1: Update iova list on detach
vfio/type1: check dma map request is within a valid iova range
vfio/type1: Add IOVA range capability support
vfio/type1: remove duplicate retrieval of reserved regions.

drivers/vfio/vfio_iommu_type1.c | 489 +++++++++++++++++++++++++++++++++++++++-
include/uapi/linux/vfio.h | 23 ++
2 files changed, 500 insertions(+), 12 deletions(-)


 \ /
  Last update: 2018-02-21 13:26    [W:0.146 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site