Skip to content

Commit 7a7bba1

Browse files
jpemartinsjgunthorpe
authored andcommitted
iommufd/iova_bitmap: Dynamic pinning on iova_bitmap_set()
Today zerocopy iova bitmaps use a static iteration scheme where it walks the bitmap data in a max iteration size of 2M of bitmap of data at a time. That translates to a fixed window of IOVA space that can span up to 64G (e.g. base pages, x86). Here 'window' refers to the IOVA space represented by the bitmap data it is iterating. This static scheme is the ideal one where the reported page-size is the same as the one behind the dirty tracker. However, problems start to appear when the dirty tracker may dirty in many PTE sizes beyond or unaligned at the boundaries of the iteration window. Such is the case for the IOMMU and commit 2780025 ("iommufd/iova_bitmap: Handle recording beyond the mapped pages") tried to fix the problem by handling the PTEs that get dirty which surprass the end of the iteration. But the fix was incomplete and it didn't handle all the data structure issues namely: 1) when there's nothing to dirty but the end of the iteration IOVA range is a IOMMU hugepage PTE that crosses iterations, when it goes to the next iteration it finds the other end of the said hugepage but don't account that it had checked for that IOPTE already. iommu driver then walk the IOVA space as if it is a new page without accounting that it is past the start of a bigger page which ends up setting (future) dirty bits slightly offset-ed. Note that the partial ranges here are self induced due as a result of the fixed 'window' scheme being unaligned to this hugepage IOPTE. 2) on the same line of thinking between pinning pages of different iterations it could allow DMA to mark PTEs as dirty on the second part of this previously mentioned partial hugepage. This leads to marking part of the hugepage as dirty but still clearing IOPTE leading to missed dirty data. So to fix these problems more fundamentally and avoid future ones: instead of iterating the whole bitmap in fixed chunks, instead only pin the bitmap pages when it has dirty bits to set. The logic is simple in iova_bitmap_set(): check where the current iova range to be marked as dirty is pinned and pin the bitmap pages where to-be-recorded @iova starts if it's not. If it's partially mapped out of the whole set, continue pinning it and set bits until the whole dirty-size is covered. The latter is more relevant with AMD iommu pgtable v1 format where you can have up 64G/128G/256G page sizes and thus you can set 64G at a time. Code also gets simpler and easier to follow. Fixing this without changing this iteration scheme means changing iommu drivers to ignore any partial pages and not clear dirty bits, which is a bit hacky. Though getting to walk only part of a IOMMU hugepage is a self-induced due to this iteration scheme as it doesn't (and can't) align the iteration boundary to the huge IOPTE at the end. Thus it can't know what the hugepage size the iteration should align to until it walks the begin/end. Dynamically pinning adds some comparisons inside iova_bitmap_set() to check if something needs to be pinned if the IOVA range is out of range. Though it has the benefit that non-dirty IOVA ranges only walk page tables without needing to pin any bitmap pages. This dynamic scheme should be better for IOMMUs where upper layers don't need or know what PTE sizes IOVAs map into (and there could be more than one PTE size[*]) until they walk the IOMMU page tables. A follow-up change will remove the iteration logic. [*] Specially on AMD v1 iommu pgtable format where most powers of two are supported as page-size. Link: https://lore.kernel.org/linux-iommu/[email protected]/ Fixes: 2780025 ("iommufd/iova_bitmap: Handle recording beyond the mapped pages") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joao Martins <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Tested-by: Matt Ochs <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
1 parent 00fa1a8 commit 7a7bba1

File tree

1 file changed

+66
-7
lines changed

1 file changed

+66
-7
lines changed

drivers/iommu/iommufd/iova_bitmap.c

Lines changed: 66 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -119,6 +119,9 @@ struct iova_bitmap {
119119

120120
/* length of the IOVA range set ahead the pinned pages */
121121
unsigned long set_ahead_length;
122+
123+
/* true if it using the iterator otherwise it pins dynamically */
124+
bool iterator;
122125
};
123126

124127
/*
@@ -340,6 +343,17 @@ static unsigned long iova_bitmap_mapped_length(struct iova_bitmap *bitmap)
340343
return remaining;
341344
}
342345

346+
/*
347+
* Returns true if [@iova..@iova+@length-1] is part of the mapped IOVA range.
348+
*/
349+
static bool iova_bitmap_mapped_range(struct iova_bitmap_map *mapped,
350+
unsigned long iova, size_t length)
351+
{
352+
return mapped->npages &&
353+
(iova >= mapped->iova &&
354+
(iova + length - 1) <= (mapped->iova + mapped->length - 1));
355+
}
356+
343357
/*
344358
* Returns true if there's not more data to iterate.
345359
*/
@@ -374,6 +388,27 @@ static int iova_bitmap_set_ahead(struct iova_bitmap *bitmap,
374388
return ret;
375389
}
376390

391+
/*
392+
* Advances to a selected range, releases the current pinned
393+
* pages and pins the next set of bitmap pages.
394+
* Returns 0 on success or otherwise errno.
395+
*/
396+
static int iova_bitmap_advance_to(struct iova_bitmap *bitmap,
397+
unsigned long iova)
398+
{
399+
unsigned long index;
400+
401+
index = iova_bitmap_offset_to_index(bitmap, iova - bitmap->iova);
402+
if (index >= bitmap->mapped_total_index)
403+
return -EINVAL;
404+
bitmap->mapped_base_index = index;
405+
406+
iova_bitmap_put(bitmap);
407+
408+
/* Pin the next set of bitmap pages */
409+
return iova_bitmap_get(bitmap);
410+
}
411+
377412
/*
378413
* Advances to the next range, releases the current pinned
379414
* pages and pins the next set of bitmap pages.
@@ -426,13 +461,15 @@ int iova_bitmap_for_each(struct iova_bitmap *bitmap, void *opaque,
426461
if (ret)
427462
return ret;
428463

464+
bitmap->iterator = true;
429465
for (; !iova_bitmap_done(bitmap) && !ret;
430466
ret = iova_bitmap_advance(bitmap)) {
431467
ret = fn(bitmap, iova_bitmap_mapped_iova(bitmap),
432468
iova_bitmap_mapped_length(bitmap), opaque);
433469
if (ret)
434470
break;
435471
}
472+
bitmap->iterator = false;
436473

437474
return ret;
438475
}
@@ -452,11 +489,28 @@ void iova_bitmap_set(struct iova_bitmap *bitmap,
452489
unsigned long iova, size_t length)
453490
{
454491
struct iova_bitmap_map *mapped = &bitmap->mapped;
455-
unsigned long cur_bit = ((iova - mapped->iova) >>
456-
mapped->pgshift) + mapped->pgoff * BITS_PER_BYTE;
457-
unsigned long last_bit = (((iova + length - 1) - mapped->iova) >>
458-
mapped->pgshift) + mapped->pgoff * BITS_PER_BYTE;
459-
unsigned long last_page_idx = mapped->npages - 1;
492+
unsigned long cur_bit, last_bit, last_page_idx;
493+
494+
update_indexes:
495+
if (unlikely(!bitmap->iterator &&
496+
!iova_bitmap_mapped_range(mapped, iova, length))) {
497+
498+
/*
499+
* The attempt to advance the base index to @iova
500+
* may fail if it's out of bounds, or pinning the pages
501+
* returns an error.
502+
*
503+
* It is a no-op if within a iova_bitmap_for_each() closure.
504+
*/
505+
if (iova_bitmap_advance_to(bitmap, iova))
506+
return;
507+
}
508+
509+
last_page_idx = mapped->npages - 1;
510+
cur_bit = ((iova - mapped->iova) >>
511+
mapped->pgshift) + mapped->pgoff * BITS_PER_BYTE;
512+
last_bit = (((iova + length - 1) - mapped->iova) >>
513+
mapped->pgshift) + mapped->pgoff * BITS_PER_BYTE;
460514

461515
do {
462516
unsigned int page_idx = cur_bit / BITS_PER_PAGE;
@@ -469,8 +523,13 @@ void iova_bitmap_set(struct iova_bitmap *bitmap,
469523
unsigned long left =
470524
((last_bit - cur_bit + 1) << mapped->pgshift);
471525

472-
bitmap->set_ahead_length = left;
473-
break;
526+
if (bitmap->iterator) {
527+
bitmap->set_ahead_length = left;
528+
return;
529+
}
530+
iova += (length - left);
531+
length = left;
532+
goto update_indexes;
474533
}
475534

476535
kaddr = kmap_local_page(mapped->pages[page_idx]);

0 commit comments

Comments
 (0)