提交 712d8f20 编写于 作者: Z Zhen Lei 提交者: Joerg Roedel

iommu: Enhance IOMMU default DMA mode build options

First, add build options IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the two config options in an choice, as they are mutually exclusive.

[jpg: Make choice between strict and lazy only (and not passthrough)]
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/1626088340-5838-4-git-send-email-john.garry@huawei.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>
上级 d8577d2e
......@@ -2042,9 +2042,10 @@
throughput at the cost of reduced device isolation.
Will fall back to strict mode if not supported by
the relevant IOMMU driver.
1 - Strict mode (default).
1 - Strict mode.
DMA unmap operations invalidate IOMMU hardware TLBs
synchronously.
unset - Use value of CONFIG_IOMMU_DEFAULT_{LAZY,STRICT}.
Note: on x86, the default behaviour depends on the
equivalent driver-specific parameters, but a strict
mode explicitly specified by either method takes
......
......@@ -90,6 +90,46 @@ config IOMMU_DEFAULT_PASSTHROUGH
If unsure, say N here.
choice
prompt "IOMMU default DMA IOTLB invalidation mode"
depends on IOMMU_DMA
default IOMMU_DEFAULT_STRICT
help
This option allows an IOMMU DMA IOTLB invalidation mode to be
chosen at build time, to override the default mode of each ARCH,
removing the need to pass in kernel parameters through command line.
It is still possible to provide common boot params to override this
config.
If unsure, keep the default.
config IOMMU_DEFAULT_STRICT
bool "strict"
help
For every IOMMU DMA unmap operation, the flush operation of IOTLB and
the free operation of IOVA are guaranteed to be done in the unmap
function.
config IOMMU_DEFAULT_LAZY
bool "lazy"
help
Support lazy mode, where for every IOMMU DMA unmap operation, the
flush operation of IOTLB and the free operation of IOVA are deferred.
They are only guaranteed to be done before the related IOVA will be
reused.
The isolation provided in this mode is not as secure as STRICT mode,
such that a vulnerable time window may be created between the DMA
unmap and the mappings cached in the IOMMU IOTLB or device TLB
finally being invalidated, where the device could still access the
memory which has already been unmapped by the device driver.
However this mode may provide better performance in high throughput
scenarios, and is still considerably more secure than passthrough
mode or no IOMMU.
endchoice
config OF_IOMMU
def_bool y
depends on OF && IOMMU_API
......
......@@ -30,7 +30,7 @@ static struct kset *iommu_group_kset;
static DEFINE_IDA(iommu_group_ida);
static unsigned int iommu_def_domain_type __read_mostly;
static bool iommu_dma_strict __read_mostly = true;
static bool iommu_dma_strict __read_mostly = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
static u32 iommu_cmd_line __read_mostly;
struct iommu_group {
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册