Re: [PATCH v6-S1 5/6] dma/dpaa2: validate FLE pool IOVA mapping at vchan setup

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue,  6 Oct 2026 20:37:48 +0530
Prashant Gupta <prashant.gupta_3@nxp.com> wrote:

> From: Gagandeep Singh <g.singh@nxp.com>
> 
> The enqueue path turns every FLE virtual address into an IOVA with a
> single subtraction:
> 
> 	fle_iova = (uint64_t)fle - qdma_vq->fle_iova2va_offset;
> 
> That offset is derived once from fle_pool->mz, which is the memzone
> holding the mempool header, not the memzone(s) holding the objects. The
> objects are reserved separately by rte_mempool_populate_default(), so
> nothing so far confirmed that the offset taken from the header is also
> the offset of the chunks the FLEs are allocated from.
> 
> Walk the pool with rte_mempool_mem_iter() after creation and check both
> properties the fast path depends on. First, that every chunk is
> reachable through the IOMMU/SMMU, using DPAA2_VADDR_TO_IOVA_AND_CHECK().
> Second, that every chunk has the same VA to IOVA delta as the offset
> cached in the virtual queue, which a pool spread over chunks with
> different deltas would violate, for example with IOVA as PA and
> fragmented hugepages. Either way the IOVAs programmed into the FLEs
> would be wrong, so reject the setup instead.
> 
> On failure log the pool name, release the pool with rte_mempool_free()
> and clear the pointer, so that a later vchan-setup retry does not trip
> over a stale pool-name collision.
> 
> Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
> Signed-off-by: Prashant Gupta <prashant.gupta_3@nxp.com>
> ---

This AI review item seems serious enough that a new version is needed.


[PATCH 5/6] dma/dpaa2: validate FLE pool IOVA mapping at vchan setup

Error: vchan setup fails on 2M hugepages.

DPAA2_VADDR_TO_IOVA_AND_CHECK() on a whole chunk only succeeds if
the chunk fits in one fslmc dmaseg, and fslmc creates one dmaseg
per memseg (hugepage). The FLE pool is 8192 x 2312 bytes, about
19 MB, so on 2M pages the check always fails.

Also the reference offset comes from fle_pool->mz (the mempool
header), not from the object memory.

Take the offset from the first chunk and compare the rest:

struct dpaa2_qdma_fle_pool_check {
	uint64_t iova2va_offset;
	bool bad;
};

static void
dpaa2_qdma_fle_pool_iova_check(struct rte_mempool *mp __rte_unused,
	void *opaque, struct rte_mempool_memhdr *memhdr,
	unsigned int mem_idx)
{
	struct dpaa2_qdma_fle_pool_check *check = opaque;
	uint64_t offset;

	if (memhdr->iova == RTE_BAD_IOVA) {
		check->bad = true;
		return;
	}

	offset = (uint64_t)memhdr->addr - memhdr->iova;
	if (mem_idx == 0)
		check->iova2va_offset = offset;
	else if (offset != check->iova2va_offset)
		check->bad = true;
}

and in dpaa2_qdma_vchan_setup() drop the mz based iova/va:

	rte_mempool_mem_iter(qdma_dev->vqs[vchan].fle_pool,
		dpaa2_qdma_fle_pool_iova_check, &fle_check);
	if (fle_check.bad) {
		DPAA2_QDMA_ERR("%s spans inconsistent IOVA offsets",
			       pool_name);
		ret = -EINVAL;
		goto err_pool;
	}
	qdma_dev->vqs[vchan].fle_iova2va_offset =
		fle_check.iova2va_offset;

Warning: the later error paths (both rte_mempool_get_bulk() calls,
ring_cntx_idx alloc) still return with fle_pool allocated, so the
retry case in the commit message is still broken. Send all of them
to one label:

	return 0;

err_pool:
	rte_mempool_free(qdma_dev->vqs[vchan].fle_pool);
	qdma_dev->vqs[vchan].fle_pool = NULL;
	return ret;
}