Re: [PATCH 4/4] dmaengine: idxd: Use DMA API for in-kernel DMA with PASID

From: Dave Jiang
Date: Wed Dec 08 2021 - 10:35:54 EST



On 12/8/2021 6:13 AM, Jason Gunthorpe wrote:
On Tue, Dec 07, 2021 at 05:47:14AM -0800, Jacob Pan wrote:
In-kernel DMA should be managed by DMA mapping API. The existing kernel
PASID support is based on the SVA machinery in SVA lib that is intended
for user process SVA. The binding between a kernel PASID and kernel
mapping has many flaws. See discussions in the link below.

This patch utilizes iommu_enable_pasid_dma() to enable DSA to perform DMA
requests with PASID under the same mapping managed by DMA mapping API.
In addition, SVA-related bits for kernel DMA are removed. As a result,
DSA users shall use DMA mapping API to obtain DMA handles instead of
using kernel virtual addresses.
Er, shouldn't this be adding dma_map/etc type calls?

You can't really say a driver is using the DMA API without actually
calling the DMA API..

+ /*
+ * Try to enable both in-kernel and user DMA request with PASID.
+ * PASID is supported unless both user and kernel PASID are
+ * supported. Do not fail probe here in that idxd can still be
+ * used w/o PASID or IOMMU.
+ */
+ if (iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) ||
+ idxd_enable_system_pasid(idxd)) {
+ dev_warn(dev, "Failed to enable PASID\n");
+ } else {
+ set_bit(IDXD_FLAG_PASID_ENABLED, &idxd->flags);
}
Huh? How can the driver keep going if PASID isn't supported? I thought
the whole point of this was because the device cannot do DMA without
PASID at all?

There are 2 types of WQ supported with the DSA devices. A dedicated WQ type and a shared WQ type. The dedicated WQ type can support DMA with and without PASID. The shared wq type must have a PASID to operate. The driver can support dedicated WQ only without PASID usage when there is no PASID support.



Jason