Re: [PATCH v5 00/34] MT8195 IOMMU SUPPORT
On Mon, 2022-02-28 at 14:50 +0100, AngeloGioacchino Del Regno wrote: > Il 28/02/22 13:34, Joerg Roedel ha scritto: > > Hi Yong Wu, > > > > On Thu, Feb 17, 2022 at 07:34:19PM +0800, Yong Wu wrote: > > > Yong Wu (34): > > >dt-bindings: mediatek: mt8195: Add binding for MM IOMMU > > >dt-bindings: mediatek: mt8195: Add binding for infra IOMMU > > >iommu/mediatek: Fix 2 HW sharing pgtable issue > > >iommu/mediatek: Add list_del in mtk_iommu_remove > > >iommu/mediatek: Remove clk_disable in mtk_iommu_remove > > >iommu/mediatek: Add mutex for m4u_group and m4u_dom in data > > >iommu/mediatek: Add mutex for data in the mtk_iommu_domain > > >iommu/mediatek: Adapt sharing and non-sharing pgtable case > > >iommu/mediatek: Add 12G~16G support for multi domains > > >iommu/mediatek: Add a flag DCM_DISABLE > > >iommu/mediatek: Add a flag NON_STD_AXI > > >iommu/mediatek: Remove the granule in the tlb flush > > >iommu/mediatek: Always enable output PA over 32bits in isr > > >iommu/mediatek: Add SUB_COMMON_3BITS flag > > >iommu/mediatek: Add IOMMU_TYPE flag > > >iommu/mediatek: Contain MM IOMMU flow with the MM TYPE > > >iommu/mediatek: Adjust device link when it is sub-common > > >iommu/mediatek: Allow IOMMU_DOMAIN_UNMANAGED for PCIe VFIO > > >iommu/mediatek: Add a PM_CLK_AO flag for infra iommu > > >iommu/mediatek: Add infra iommu support > > >iommu/mediatek: Add PCIe support > > >iommu/mediatek: Add mt8195 support > > >iommu/mediatek: Only adjust code about register base > > >iommu/mediatek: Just move code position in hw_init > > >iommu/mediatek: Separate mtk_iommu_data for v1 and v2 > > >iommu/mediatek: Remove mtk_iommu.h > > >iommu/mediatek-v1: Just rename mtk_iommu to mtk_iommu_v1 > > >iommu/mediatek: Add mtk_iommu_bank_data structure > > >iommu/mediatek: Initialise bank HW for each a bank > > >iommu/mediatek: Change the domid to iova_region_id > > >iommu/mediatek: Get the proper bankid for multi banks > > >iommu/mediatek: Initialise/Remove for multi bank dev > > >iommu/mediatek: Backup/restore regsiters for multi banks > > >iommu/mediatek: mt8195: Enable multi banks for infra iommu > > > > This doesn't apply cleanly, can you please send a version rebased > > to > > v5.17-rc4? As in the cover letter, this patchset doesn't base on v5.17-rc4, it bases on next-20220216 which has contained [1] and Dafna's patchset below. By the way, It still conflicts with the latest next-20220228 which has just contained[2]. In this case, How should I do? Send a version base on the latest next? [1] https://lore.kernel.org/linux-iommu/20220117070510.17642-1-yong...@mediatek.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=next-20220228=grep=component_compare Thanks. > > > > Thanks, > > > > Joerg > > Hello Joerg, > > this series depends on the following series: > https://patchwork.kernel.org/project/linux-mediatek/list/?series=592275 > > ...which is also well tested and ready to be merged in. > > Applying Yong's series without the mentioned series from Dafna would > not work. Yes. Thanks. > > > Thanks, > Angelo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] iommu/omap: Fix missing put_device() call in omap_iommu_probe_device
The reference taken by 'of_find_device_by_node()' must be released when
not needed anymore.
Add the corresponding 'put_device()' in the error handling path and
the regular path.
Fixes: ede1c2e7d4dc ("iommu/omap: Store iommu_dev pointer in arch_data")
Signed-off-by: Miaoqian Lin
---
changes in v2:
- move put_device() before of_node_put().
- add put_device() in the regular path.
---
drivers/iommu/omap-iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 91749654fd49..b30a0a00 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1683,6 +1683,7 @@ static struct iommu_device
*omap_iommu_probe_device(struct device *dev)
oiommu = platform_get_drvdata(pdev);
if (!oiommu) {
+ put_device(>dev);
of_node_put(np);
kfree(arch_data);
return ERR_PTR(-EINVAL);
@@ -1691,6 +1692,7 @@ static struct iommu_device
*omap_iommu_probe_device(struct device *dev)
tmp->iommu_dev = oiommu;
tmp->dev = >dev;
+ put_device(>dev);
of_node_put(np);
}
--
2.17.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 0/7] arm64: Default to 32-bit wide ZONE_DMA
Hi All, It seems that the ZONE_DMA changes have broken the operation of Rochip rk3399 chipsets from v5.10.22 onwards. It isn't clear what needs to be changed to get any of these boards up and running again. Any pointers on how/what to change ? An easy test for debugging is to run stress : stress --cpu 4 --io 4 --vm 2 --vm-bytes 128M stress: info: [255] dispatching hogs: 4 cpu, 4 io, 2 vm, 0 hdd [8.070280] SError Interrupt on CPU4, code 0xbf00 -- SError [8.070286] CPU: 4 PID: 261 Comm: stress Not tainted 5.10.21 #1 [8.070289] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070293] pstate: 0005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [8.070296] pc : clear_page+0x14/0x28 [8.070298] lr : clear_subpage+0x50/0x90 [8.070302] sp : 800012abbc40 [8.070305] x29: 800012abbc40 x28: 00f68000 [8.070313] x27: x26: 01f38e40 [8.070320] x25: 8000114fd000 x24: [8.070326] x23: x22: 1000 [8.070334] x21: a7e0 x20: fe01 [8.070341] x19: 00f68000 x18: [8.070348] x17: x16: [8.070354] x15: 0002 x14: 0001 [8.070361] x13: 00075879 x12: 00c0 [8.070368] x11: 80006c46a000 x10: 0200 [8.070374] x9 : x8 : 0010 [8.070381] x7 : 7db800a0 x6 : 800011b899c0 [8.070387] x5 : x4 : 7db800f7 [8.070394] x3 : 0220 x2 : 0004 [8.070401] x1 : 0040 x0 : 085ff4c0 [8.070409] Kernel panic - not syncing: Asynchronous SError Interrupt [8.070412] CPU: 4 PID: 261 Comm: stress Not tainted 5.10.21 #1 [8.070415] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070418] Call trace: [8.070420] dump_backtrace+0x0/0x1b0 [8.070423] show_stack+0x18/0x70 [8.070425] dump_stack+0xd0/0x12c [8.070428] panic+0x16c/0x334 [8.070430] nmi_panic+0x8c/0x90 [8.070433] arm64_serror_panic+0x78/0x84 [8.070435] do_serror+0x64/0x70 [8.070437] el1_error+0x88/0x108 [8.070440] clear_page+0x14/0x28 [8.070443] clear_huge_page+0x74/0x210 [8.070445] do_huge_pmd_anonymous_page+0x1b0/0x7c0 [8.070448] handle_mm_fault+0xdac/0x1290 [8.070451] do_page_fault+0x130/0x3a0 [8.070453] do_translation_fault+0xb0/0xc0 [8.070456] do_mem_abort+0x44/0xb0 [8.070458] el0_da+0x28/0x40 [8.070461] el0_sync_handler+0x168/0x1b0 [8.070464] el0_sync+0x174/0x180 [8.070508] SError Interrupt on CPU0, code 0xbf00 -- SError [8.070511] CPU: 0 PID: 258 Comm: stress Not tainted 5.10.21 #1 [8.070515] Hardware name: FriendlyElec NanoPi M4 (DT) [8.070518] pstate: 8000 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [8.070520] pc : cec22e98 [8.070523] lr : cec22d84 [8.070525] sp : e67a8620 [8.070528] x29: e67a8620 x28: 0003 [8.070534] x27: cec34000 x26: aeb42610 [8.070541] x25: a69af010 x24: cec23a98 [8.070547] x23: cec35010 x22: cec35000 [8.070554] x21: 1000 x20: [8.070560] x19: 0800 x18: [8.070567] x17: x16: [8.070573] x15: x14: [8.070580] x13: 8000 x12: [8.070587] x11: 0020 x10: 0030 [8.070593] x9 : 000a x8 : 00de [8.070599] x7 : 0020 x6 : 021b [8.070606] x5 : x4 : [8.070613] x3 : x2 : aeb47000 [8.070619] x1 : 005a x0 : 00a58000 [8.070629] SMP: stopping secondary CPUs [8.070632] Kernel Offset: disabled [8.070634] CPU features: 0x0240022,6100600c [8.070637] Memory Limit: none -- 2.32.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 06/11] PCI: portdrv: Set driver_managed_dma
Hi Bjorn,
On 3/1/22 3:56 AM, Bjorn Helgaas wrote:
On Mon, Feb 28, 2022 at 08:50:51AM +0800, Lu Baolu wrote:
If a switch lacks ACS P2P Request Redirect, a device below the switch can
bypass the IOMMU and DMA directly to other devices below the switch, so
all the downstream devices must be in the same IOMMU group as the switch
itself.
The existing VFIO framework allows the portdrv driver to be bound to the
bridge while its downstream devices are assigned to user space. The
pci_dma_configure() marks the IOMMU group as containing only devices
with kernel drivers that manage DMA. Avoid this default behavior for the
portdrv driver in order for compatibility with the current VFIO usage.
It would be nice to explicitly say here how we can look at portdrv
(and pci_stub) and conclude that ".driver_managed_dma = true" is safe.
Otherwise I won't know what kind of future change to portdrv might
make it unsafe.
Fair enough. We can add below words:
We achieve this by setting ".driver_managed_dma = true" in pci_driver
structure. It is safe because the portdrv driver meets below criteria:
- This driver doesn't use DMA, as you can't find any related calls like
pci_set_master() or any kernel DMA API (dma_map_*() and etc.).
- It doesn't use MMIO as you can't find ioremap() or similar calls. It's
tolerant to userspace possibly also touching the same MMIO registers
via P2P DMA access.
Suggested-by: Jason Gunthorpe
Suggested-by: Kevin Tian
Signed-off-by: Lu Baolu
Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
Thank you!
Best regards,
baolu
---
drivers/pci/pcie/portdrv_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 35eca6277a96..6b2adb678c21 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -202,6 +202,8 @@ static struct pci_driver pcie_portdriver = {
.err_handler = _portdrv_err_handler,
+ .driver_managed_dma = true,
+
.driver.pm = PCIE_PORTDRV_PM_OPS,
};
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] iommu/iova: Reset max32_alloc_size after cleaning rcache in the fail path
From: Yunfei Wang
In alloc_iova_fast function, if __alloc_and_insert_iova_range fail,
alloc_iova_fast will try flushing rcache and retry alloc iova, but
this has an issue:
Since __alloc_and_insert_iova_range fail will set the current alloc
iova size to max32_alloc_size (iovad->max32_alloc_size = size),
when the retry is executed into the __alloc_and_insert_iova_range
function, the retry action will be blocked by the check condition
(size >= iovad->max32_alloc_size) and goto iova32_full directly,
causes the action of retry regular alloc iova in
__alloc_and_insert_iova_range to not actually be executed.
Based on the above, so need reset max32_alloc_size before retry alloc
iova when alloc iova fail, that is set the initial dma_32bit_pfn value
of iovad to max32_alloc_size, so that the action of retry alloc iova
in __alloc_and_insert_iova_range can be executed.
Signed-off-by: Yunfei Wang
Cc: # 5.10.*
---
v2: Cc sta...@vger.kernel.org
1. This patch needs to be merged stable branch, add sta...@vger.kernel.org
in mail list.
---
drivers/iommu/iova.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index b28c9435b898..0c085ae8293f 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -453,6 +453,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long
size,
retry:
new_iova = alloc_iova(iovad, size, limit_pfn, true);
if (!new_iova) {
+ unsigned long flags;
unsigned int cpu;
if (!flush_rcache)
@@ -463,6 +464,12 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long
size,
for_each_online_cpu(cpu)
free_cpu_cached_iovas(cpu, iovad);
free_global_cached_iovas(iovad);
+
+ /* Reset max32_alloc_size after flushing rcache for retry */
+ spin_lock_irqsave(>iova_rbtree_lock, flags);
+ iovad->max32_alloc_size = iovad->dma_32bit_pfn;
+ spin_unlock_irqrestore(>iova_rbtree_lock, flags);
+
goto retry;
}
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 12/12] iommu/vt-d: Enable ATS for the devices in SATC table
From: Yian Chen
Starting from Intel VT-d v3.2, Intel platform BIOS can provide additional
SATC table structure. SATC table includes a list of SoC integrated devices
that support ATC (Address translation cache).
Enabling ATC (via ATS capability) can be a functional requirement for SATC
device operation or optional to enhance device performance/functionality.
This is determined by the bit of ATC_REQUIRED in SATC table. When IOMMU is
working in scalable mode, software chooses to always enable ATS for every
device in SATC table because Intel SoC devices in SATC table are trusted to
use ATS.
On the other hand, if IOMMU is in legacy mode, ATS of SATC capable devices
can work transparently to software and be automatically enabled by IOMMU
hardware. As the result, there is no need for software to enable ATS on
these devices.
This also removes dmar_find_matched_atsr_unit() helper as it becomes dead
code now.
Signed-off-by: Yian Chen
Link: https://lore.kernel.org/r/20220222185416.1722611-1-yian.c...@intel.com
Signed-off-by: Lu Baolu
---
include/linux/intel-iommu.h | 1 -
drivers/iommu/intel/iommu.c | 40 +++--
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 4909d6c9ac21..2f9891cb3d00 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -693,7 +693,6 @@ static inline int nr_pte_to_next_page(struct dma_pte *pte)
}
extern struct dmar_drhd_unit * dmar_find_matched_drhd_unit(struct pci_dev
*dev);
-extern int dmar_find_matched_atsr_unit(struct pci_dev *dev);
extern int dmar_enable_qi(struct intel_iommu *iommu);
extern void dmar_disable_qi(struct intel_iommu *iommu);
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 19562891d6ef..df5c62ecf942 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3693,7 +3693,31 @@ static void intel_iommu_free_dmars(void)
}
}
-int dmar_find_matched_atsr_unit(struct pci_dev *dev)
+static struct dmar_satc_unit *dmar_find_matched_satc_unit(struct pci_dev *dev)
+{
+ struct dmar_satc_unit *satcu;
+ struct acpi_dmar_satc *satc;
+ struct device *tmp;
+ int i;
+
+ dev = pci_physfn(dev);
+ rcu_read_lock();
+
+ list_for_each_entry_rcu(satcu, _satc_units, list) {
+ satc = container_of(satcu->hdr, struct acpi_dmar_satc, header);
+ if (satc->segment != pci_domain_nr(dev->bus))
+ continue;
+ for_each_dev_scope(satcu->devices, satcu->devices_cnt, i, tmp)
+ if (to_pci_dev(tmp) == dev)
+ goto out;
+ }
+ satcu = NULL;
+out:
+ rcu_read_unlock();
+ return satcu;
+}
+
+static int dmar_ats_supported(struct pci_dev *dev, struct intel_iommu *iommu)
{
int i, ret = 1;
struct pci_bus *bus;
@@ -3701,8 +3725,20 @@ int dmar_find_matched_atsr_unit(struct pci_dev *dev)
struct device *tmp;
struct acpi_dmar_atsr *atsr;
struct dmar_atsr_unit *atsru;
+ struct dmar_satc_unit *satcu;
dev = pci_physfn(dev);
+ satcu = dmar_find_matched_satc_unit(dev);
+ if (satcu)
+ /*
+* This device supports ATS as it is in SATC table.
+* When IOMMU is in legacy mode, enabling ATS is done
+* automatically by HW for the device that requires
+* ATS, hence OS should not enable this device ATS
+* to avoid duplicated TLB invalidation.
+*/
+ return !(satcu->atc_required && !sm_supported(iommu));
+
for (bus = dev->bus; bus; bus = bus->parent) {
bridge = bus->self;
/* If it's an integrated device, allow ATS */
@@ -4550,7 +4586,7 @@ static struct iommu_device
*intel_iommu_probe_device(struct device *dev)
if (dev_is_pci(dev)) {
if (ecap_dev_iotlb_support(iommu->ecap) &&
pci_ats_supported(pdev) &&
- dmar_find_matched_atsr_unit(pdev))
+ dmar_ats_supported(pdev, iommu))
info->ats_supported = 1;
if (sm_supported(iommu)) {
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 11/12] iommu/vt-d: Remove unused function intel_svm_capable()
From: YueHaibing
This is unused since commit 4048377414162 ("iommu/vt-d: Use
iommu_sva_alloc(free)_pasid() helpers").
Signed-off-by: YueHaibing
Link: https://lore.kernel.org/r/20220216113851.25004-1-yuehaib...@huawei.com
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/svm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 944e2408b6d2..241d095b6dcf 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -168,11 +168,6 @@ int intel_svm_finish_prq(struct intel_iommu *iommu)
return 0;
}
-static inline bool intel_svm_capable(struct intel_iommu *iommu)
-{
- return iommu->flags & VTD_FLAG_SVM_CAPABLE;
-}
-
void intel_svm_check(struct intel_iommu *iommu)
{
if (!pasid_supported(iommu))
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 10/12] iommu/vt-d: Add missing "__init" for rmrr_sanity_check()
From: Marco Bonelli
rmrr_sanity_check() calls arch_rmrr_sanity_check(), which is marked as
"__init". Add the annotation for rmrr_sanity_check() too. This function is
currently only called from dmar_parse_one_rmrr() which is also "__init".
Signed-off-by: Marco Bonelli
Link: https://lore.kernel.org/r/20220210023141.9208-1-ma...@mebeim.net
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index f5b15bc20426..19562891d6ef 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3364,7 +3364,7 @@ static void __init init_iommu_pm_ops(void)
static inline void init_iommu_pm_ops(void) {}
#endif /* CONFIG_PM */
-static int rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
+static int __init rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
{
if (!IS_ALIGNED(rmrr->base_address, PAGE_SIZE) ||
!IS_ALIGNED(rmrr->end_address + 1, PAGE_SIZE) ||
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 09/12] iommu/vt-d: Move intel_iommu_ops to header file
From: Andy Shevchenko
Compiler is not happy about hidden declaration of intel_iommu_ops.
.../iommu.c:414:24: warning: symbol 'intel_iommu_ops' was not declared. Should
it be static?
Move declaration to header file to make compiler happy.
Signed-off-by: Andy Shevchenko
Link:
https://lore.kernel.org/r/20220207141240.8253-1-andriy.shevche...@linux.intel.com
Signed-off-by: Lu Baolu
---
include/linux/intel-iommu.h | 2 ++
drivers/iommu/intel/dmar.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 03f1134fc2fe..4909d6c9ac21 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -783,6 +783,8 @@ bool context_present(struct context_entry *context);
struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus,
u8 devfn, int alloc);
+extern const struct iommu_ops intel_iommu_ops;
+
#ifdef CONFIG_INTEL_IOMMU
extern int iommu_calculate_agaw(struct intel_iommu *iommu);
extern int iommu_calculate_max_sagaw(struct intel_iommu *iommu);
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 6d10be50ec30..4de960834a1b 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -66,8 +66,6 @@ static unsigned long
dmar_seq_ids[BITS_TO_LONGS(DMAR_UNITS_SUPPORTED)];
static int alloc_iommu(struct dmar_drhd_unit *drhd);
static void free_iommu(struct intel_iommu *iommu);
-extern const struct iommu_ops intel_iommu_ops;
-
static void dmar_register_drhd_unit(struct dmar_drhd_unit *drhd)
{
/*
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 08/12] iommu/vt-d: Fix indentation of goto labels
Remove blanks before goto labels.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Link:
https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com
---
drivers/iommu/intel/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 0030dbc8764a..f5b15bc20426 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -827,7 +827,7 @@ struct intel_iommu *device_to_iommu(struct device *dev, u8
*bus, u8 *devfn)
}
if (pdev && drhd->include_all) {
- got_pdev:
+got_pdev:
if (bus && devfn) {
*bus = pdev->bus->number;
*devfn = pdev->devfn;
@@ -836,7 +836,7 @@ struct intel_iommu *device_to_iommu(struct device *dev, u8
*bus, u8 *devfn)
}
}
iommu = NULL;
- out:
+out:
if (iommu_is_dummy(iommu, dev))
iommu = NULL;
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 07/12] iommu/vt-d: Remove unnecessary prototypes
Some prototypes in iommu.c are unnecessary. Delete them. Signed-off-by: Lu Baolu Reviewed-by: Christoph Hellwig Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com --- drivers/iommu/intel/iommu.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index be3dbc89df06..0030dbc8764a 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -296,14 +296,9 @@ static LIST_HEAD(dmar_satc_units); /* bitmap for indexing intel_iommus */ static int g_num_of_iommus; -static void domain_exit(struct dmar_domain *domain); static void domain_remove_dev_info(struct dmar_domain *domain); static void dmar_remove_one_dev_info(struct device *dev); static void __dmar_remove_one_dev_info(struct device_domain_info *info); -static int intel_iommu_attach_device(struct iommu_domain *domain, -struct device *dev); -static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain *domain, - dma_addr_t iova); int dmar_disabled = !IS_ENABLED(CONFIG_INTEL_IOMMU_DEFAULT_ON); int intel_iommu_sm = IS_ENABLED(CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON); -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 06/12] iommu/vt-d: Remove unnecessary includes
Remove unnecessary include files and sort the remaining alphabetically. Signed-off-by: Lu Baolu Reviewed-by: Christoph Hellwig Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com --- drivers/iommu/intel/iommu.c | 34 +++--- 1 file changed, 7 insertions(+), 27 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index c109d12cab0d..be3dbc89df06 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -13,38 +13,18 @@ #define pr_fmt(fmt) "DMAR: " fmt #define dev_fmt(fmt)pr_fmt(fmt) -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include +#include +#include #include +#include #include #include +#include +#include +#include +#include #include #include -#include -#include -#include -#include -#include -#include -#include -#include -#include #include "../irq_remapping.h" #include "../iommu-sva-lib.h" -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 05/12] iommu/vt-d: Remove DEFER_DEVICE_DOMAIN_INFO
Allocate and set the per-device iommu private data during iommu device
probe. This makes the per-device iommu private data always available
during iommu_probe_device() and iommu_release_device(). With this changed,
the dummy DEFER_DEVICE_DOMAIN_INFO pointer could be removed. The wrappers
for getting the private data and domain are also cleaned.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Link:
https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com
---
include/linux/intel-iommu.h | 2 -
drivers/iommu/intel/debugfs.c | 3 +-
drivers/iommu/intel/iommu.c | 186 +-
drivers/iommu/intel/pasid.c | 12 +--
drivers/iommu/intel/svm.c | 6 +-
5 files changed, 79 insertions(+), 130 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 8c7591b5f3e2..03f1134fc2fe 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -733,8 +733,6 @@ int for_each_device_domain(int (*fn)(struct
device_domain_info *info,
void *data), void *data);
void iommu_flush_write_buffer(struct intel_iommu *iommu);
int intel_iommu_enable_pasid(struct intel_iommu *iommu, struct device *dev);
-struct dmar_domain *find_domain(struct device *dev);
-struct device_domain_info *get_domain_info(struct device *dev);
struct intel_iommu *device_to_iommu(struct device *dev, u8 *bus, u8 *devfn);
#ifdef CONFIG_INTEL_IOMMU_SVM
diff --git a/drivers/iommu/intel/debugfs.c b/drivers/iommu/intel/debugfs.c
index db7a0ca73626..ed796eea4581 100644
--- a/drivers/iommu/intel/debugfs.c
+++ b/drivers/iommu/intel/debugfs.c
@@ -344,7 +344,8 @@ static void pgtable_walk_level(struct seq_file *m, struct
dma_pte *pde,
static int show_device_domain_translation(struct device *dev, void *data)
{
- struct dmar_domain *domain = find_domain(dev);
+ struct device_domain_info *info = dev_iommu_priv_get(dev);
+ struct dmar_domain *domain = info->domain;
struct seq_file *m = data;
u64 path[6] = { 0 };
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 7f2ef790595e..c109d12cab0d 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -342,21 +342,6 @@ static int iommu_skip_te_disable;
int intel_iommu_gfx_mapped;
EXPORT_SYMBOL_GPL(intel_iommu_gfx_mapped);
-#define DEFER_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-2))
-struct device_domain_info *get_domain_info(struct device *dev)
-{
- struct device_domain_info *info;
-
- if (!dev)
- return NULL;
-
- info = dev_iommu_priv_get(dev);
- if (unlikely(info == DEFER_DEVICE_DOMAIN_INFO))
- return NULL;
-
- return info;
-}
-
DEFINE_SPINLOCK(device_domain_lock);
static LIST_HEAD(device_domain_list);
@@ -741,11 +726,6 @@ struct context_entry *iommu_context_addr(struct
intel_iommu *iommu, u8 bus,
return [devfn];
}
-static bool attach_deferred(struct device *dev)
-{
- return dev_iommu_priv_get(dev) == DEFER_DEVICE_DOMAIN_INFO;
-}
-
/**
* is_downstream_to_pci_bridge - test if a device belongs to the PCI
* sub-hierarchy of a candidate PCI-PCI bridge
@@ -2432,15 +2412,6 @@ static void domain_context_clear_one(struct
device_domain_info *info, u8 bus, u8
__iommu_flush_dev_iotlb(info, 0, MAX_AGAW_PFN_WIDTH);
}
-static inline void unlink_domain_info(struct device_domain_info *info)
-{
- assert_spin_locked(_domain_lock);
- list_del(>link);
- list_del(>global);
- if (info->dev)
- dev_iommu_priv_set(info->dev, NULL);
-}
-
static void domain_remove_dev_info(struct dmar_domain *domain)
{
struct device_domain_info *info, *tmp;
@@ -2452,24 +2423,6 @@ static void domain_remove_dev_info(struct dmar_domain
*domain)
spin_unlock_irqrestore(_domain_lock, flags);
}
-struct dmar_domain *find_domain(struct device *dev)
-{
- struct device_domain_info *info;
-
- if (unlikely(!dev || !dev->iommu))
- return NULL;
-
- if (unlikely(attach_deferred(dev)))
- return NULL;
-
- /* No lock here, assumes no domain exit in normal case */
- info = get_domain_info(dev);
- if (likely(info))
- return info->domain;
-
- return NULL;
-}
-
static inline struct device_domain_info *
dmar_search_domain_by_dev_info(int segment, int bus, int devfn)
{
@@ -2530,66 +2483,20 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
struct device *dev,
struct dmar_domain *domain)
{
- struct device_domain_info *info;
+ struct device_domain_info *info = dev_iommu_priv_get(dev);
unsigned long flags;
int ret;
- info = kzalloc(sizeof(*info), GFP_KERNEL);
- if
[PATCH 04/12] iommu/vt-d: Remove domain and devinfo mempool
The domain and devinfo memory blocks are only allocated during device
probe and released during remove. There's no hot-path context, hence
no need for memory pools.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Link:
https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com
---
drivers/iommu/intel/iommu.c | 104 ++--
1 file changed, 5 insertions(+), 99 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index a1b6fc7174c8..7f2ef790595e 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -452,9 +452,6 @@ static int __init intel_iommu_setup(char *str)
}
__setup("intel_iommu=", intel_iommu_setup);
-static struct kmem_cache *iommu_domain_cache;
-static struct kmem_cache *iommu_devinfo_cache;
-
void *alloc_pgtable_page(int node)
{
struct page *page;
@@ -471,26 +468,6 @@ void free_pgtable_page(void *vaddr)
free_page((unsigned long)vaddr);
}
-static inline void *alloc_domain_mem(void)
-{
- return kmem_cache_alloc(iommu_domain_cache, GFP_ATOMIC);
-}
-
-static void free_domain_mem(void *vaddr)
-{
- kmem_cache_free(iommu_domain_cache, vaddr);
-}
-
-static inline void * alloc_devinfo_mem(void)
-{
- return kmem_cache_alloc(iommu_devinfo_cache, GFP_ATOMIC);
-}
-
-static inline void free_devinfo_mem(void *vaddr)
-{
- kmem_cache_free(iommu_devinfo_cache, vaddr);
-}
-
static inline int domain_type_is_si(struct dmar_domain *domain)
{
return domain->domain.type == IOMMU_DOMAIN_IDENTITY;
@@ -1885,11 +1862,10 @@ static struct dmar_domain *alloc_domain(unsigned int
type)
{
struct dmar_domain *domain;
- domain = alloc_domain_mem();
+ domain = kzalloc(sizeof(*domain), GFP_KERNEL);
if (!domain)
return NULL;
- memset(domain, 0, sizeof(*domain));
domain->nid = NUMA_NO_NODE;
if (first_level_by_default(type))
domain->flags |= DOMAIN_FLAG_USE_FIRST_LEVEL;
@@ -1973,7 +1949,7 @@ static void domain_exit(struct dmar_domain *domain)
put_pages_list();
}
- free_domain_mem(domain);
+ kfree(domain);
}
/*
@@ -2558,7 +2534,7 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
unsigned long flags;
int ret;
- info = alloc_devinfo_mem();
+ info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return NULL;
@@ -2574,13 +2550,9 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
info->segment = pci_domain_nr(pdev->bus);
}
- info->ats_supported = info->pasid_supported = info->pri_supported = 0;
- info->ats_enabled = info->pasid_enabled = info->pri_enabled = 0;
- info->ats_qdep = 0;
info->dev = dev;
info->domain = domain;
info->iommu = iommu;
- info->pasid_table = NULL;
if (dev && dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(info->dev);
@@ -2610,7 +2582,7 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
if (ret) {
spin_unlock_irqrestore(_domain_lock, flags);
- free_devinfo_mem(info);
+ kfree(info);
return NULL;
}
@@ -3343,65 +3315,6 @@ static int __init init_dmars(void)
return ret;
}
-static inline int iommu_domain_cache_init(void)
-{
- int ret = 0;
-
- iommu_domain_cache = kmem_cache_create("iommu_domain",
-sizeof(struct dmar_domain),
-0,
-SLAB_HWCACHE_ALIGN,
-
-NULL);
- if (!iommu_domain_cache) {
- pr_err("Couldn't create iommu_domain cache\n");
- ret = -ENOMEM;
- }
-
- return ret;
-}
-
-static inline int iommu_devinfo_cache_init(void)
-{
- int ret = 0;
-
- iommu_devinfo_cache = kmem_cache_create("iommu_devinfo",
-sizeof(struct device_domain_info),
-0,
-SLAB_HWCACHE_ALIGN,
-NULL);
- if (!iommu_devinfo_cache) {
- pr_err("Couldn't create devinfo cache\n");
- ret = -ENOMEM;
- }
-
- return ret;
-}
-
-static int __init iommu_init_mempool(void)
-{
- int ret;
-
- ret = iommu_domain_cache_init();
- if (ret)
- goto domain_error;
-
- ret = iommu_devinfo_cache_init();
- if (!ret)
- return ret;
-
- kmem_cache_destroy(iommu_domain_cache);
-domain_error:
-
- return -ENOMEM;
-}
-
-static void __init iommu_exit_mempool(void)
-{
- kmem_cache_destroy(iommu_devinfo_cache);
-
[PATCH 03/12] iommu/vt-d: Remove iova_cache_get/put()
These have been done in drivers/iommu/dma-iommu.c. Remove this duplicate
code.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Link:
https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com
---
drivers/iommu/intel/iommu.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 56fe9b22c576..a1b6fc7174c8 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3381,9 +3381,6 @@ static inline int iommu_devinfo_cache_init(void)
static int __init iommu_init_mempool(void)
{
int ret;
- ret = iova_cache_get();
- if (ret)
- return ret;
ret = iommu_domain_cache_init();
if (ret)
@@ -3395,7 +3392,6 @@ static int __init iommu_init_mempool(void)
kmem_cache_destroy(iommu_domain_cache);
domain_error:
- iova_cache_put();
return -ENOMEM;
}
@@ -3404,7 +3400,6 @@ static void __init iommu_exit_mempool(void)
{
kmem_cache_destroy(iommu_devinfo_cache);
kmem_cache_destroy(iommu_domain_cache);
- iova_cache_put();
}
static void __init init_no_remapping_devices(void)
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 02/12] iommu/vt-d: Remove finding domain in dmar_insert_one_dev_info()
The Intel IOMMU driver has already converted to use default domain
framework in iommu core. There's no need to find a domain for the
device in the domain attaching path. Cleanup that code.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Link:
https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com
---
drivers/iommu/intel/iommu.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ff43c2a3a206..56fe9b22c576 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2554,7 +2554,6 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
struct device *dev,
struct dmar_domain *domain)
{
- struct dmar_domain *found = NULL;
struct device_domain_info *info;
unsigned long flags;
int ret;
@@ -2605,26 +2604,6 @@ static struct dmar_domain
*dmar_insert_one_dev_info(struct intel_iommu *iommu,
}
spin_lock_irqsave(_domain_lock, flags);
- if (dev)
- found = find_domain(dev);
-
- if (!found) {
- struct device_domain_info *info2;
- info2 = dmar_search_domain_by_dev_info(info->segment, info->bus,
- info->devfn);
- if (info2) {
- found = info2->domain;
- info2->dev = dev;
- }
- }
-
- if (found) {
- spin_unlock_irqrestore(_domain_lock, flags);
- free_devinfo_mem(info);
- /* Caller must free the original domain */
- return found;
- }
-
spin_lock(>lock);
ret = domain_attach_iommu(domain, iommu);
spin_unlock(>lock);
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 01/12] iommu/vt-d: Remove intel_iommu::domains
The "domains" field of the intel_iommu structure keeps the mapping of
domain_id to dmar_domain. This information is not used anywhere. Remove
and cleanup it to avoid unnecessary memory consumption.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Link:
https://lore.kernel.org/r/20220214025704.3184654-1-baolu...@linux.intel.com
---
include/linux/intel-iommu.h | 1 -
drivers/iommu/intel/iommu.c | 68 ++---
2 files changed, 3 insertions(+), 66 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 5cfda90b2cca..8c7591b5f3e2 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -578,7 +578,6 @@ struct intel_iommu {
#ifdef CONFIG_INTEL_IOMMU
unsigned long *domain_ids; /* bitmap of domains */
- struct dmar_domain ***domains; /* ptr to domains */
spinlock_t lock; /* protect context, domain ids */
struct root_entry *root_entry; /* virtual address */
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index ce33f85c72ab..ff43c2a3a206 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -455,36 +455,6 @@ __setup("intel_iommu=", intel_iommu_setup);
static struct kmem_cache *iommu_domain_cache;
static struct kmem_cache *iommu_devinfo_cache;
-static struct dmar_domain* get_iommu_domain(struct intel_iommu *iommu, u16 did)
-{
- struct dmar_domain **domains;
- int idx = did >> 8;
-
- domains = iommu->domains[idx];
- if (!domains)
- return NULL;
-
- return domains[did & 0xff];
-}
-
-static void set_iommu_domain(struct intel_iommu *iommu, u16 did,
-struct dmar_domain *domain)
-{
- struct dmar_domain **domains;
- int idx = did >> 8;
-
- if (!iommu->domains[idx]) {
- size_t size = 256 * sizeof(struct dmar_domain *);
- iommu->domains[idx] = kzalloc(size, GFP_ATOMIC);
- }
-
- domains = iommu->domains[idx];
- if (WARN_ON(!domains))
- return;
- else
- domains[did & 0xff] = domain;
-}
-
void *alloc_pgtable_page(int node)
{
struct page *page;
@@ -1751,8 +1721,7 @@ static void intel_flush_iotlb_all(struct iommu_domain
*domain)
DMA_TLB_DSI_FLUSH);
if (!cap_caching_mode(iommu->cap))
- iommu_flush_dev_iotlb(get_iommu_domain(iommu, did),
- 0, MAX_AGAW_PFN_WIDTH);
+ iommu_flush_dev_iotlb(dmar_domain, 0,
MAX_AGAW_PFN_WIDTH);
}
}
@@ -1815,7 +1784,6 @@ static void iommu_disable_translation(struct intel_iommu
*iommu)
static int iommu_init_domains(struct intel_iommu *iommu)
{
u32 ndomains;
- size_t size;
ndomains = cap_ndoms(iommu->cap);
pr_debug("%s: Number of Domains supported <%d>\n",
@@ -1827,24 +1795,6 @@ static int iommu_init_domains(struct intel_iommu *iommu)
if (!iommu->domain_ids)
return -ENOMEM;
- size = (ALIGN(ndomains, 256) >> 8) * sizeof(struct dmar_domain **);
- iommu->domains = kzalloc(size, GFP_KERNEL);
-
- if (iommu->domains) {
- size = 256 * sizeof(struct dmar_domain *);
- iommu->domains[0] = kzalloc(size, GFP_KERNEL);
- }
-
- if (!iommu->domains || !iommu->domains[0]) {
- pr_err("%s: Allocating domain array failed\n",
- iommu->name);
- bitmap_free(iommu->domain_ids);
- kfree(iommu->domains);
- iommu->domain_ids = NULL;
- iommu->domains= NULL;
- return -ENOMEM;
- }
-
/*
* If Caching mode is set, then invalid translations are tagged
* with domain-id 0, hence we need to pre-allocate it. We also
@@ -1871,7 +1821,7 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
struct device_domain_info *info, *tmp;
unsigned long flags;
- if (!iommu->domains || !iommu->domain_ids)
+ if (!iommu->domain_ids)
return;
spin_lock_irqsave(_domain_lock, flags);
@@ -1892,15 +1842,8 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
static void free_dmar_iommu(struct intel_iommu *iommu)
{
- if ((iommu->domains) && (iommu->domain_ids)) {
- int elems = ALIGN(cap_ndoms(iommu->cap), 256) >> 8;
- int i;
-
- for (i = 0; i < elems; i++)
- kfree(iommu->domains[i]);
- kfree(iommu->domains);
+ if (iommu->domain_ids) {
bitmap_free(iommu->domain_ids);
- iommu->domains = NULL;
iommu->domain_ids = NULL;
}
@@ -1978,11 +1921,8 @@ static int domain_attach_iommu(struct dmar_domain
*domain,
}
[PATCH 00/12] [PULL REQUEST] Intel IOMMU updates for Linux v5.18
Hi Joerg, This includes patches queued for v5.18. It includes: - [PATCH 1 ~ 11] Various cleanups, no intentional functional changes. - [PATCH 12] Enable ATS in SoC-integrated devices listed in ACPI/SATC table. Please consider them for v5.18. Best regards, Baolu Andy Shevchenko (1): iommu/vt-d: Move intel_iommu_ops to header file Lu Baolu (8): iommu/vt-d: Remove intel_iommu::domains iommu/vt-d: Remove finding domain in dmar_insert_one_dev_info() iommu/vt-d: Remove iova_cache_get/put() iommu/vt-d: Remove domain and devinfo mempool iommu/vt-d: Remove DEFER_DEVICE_DOMAIN_INFO iommu/vt-d: Remove unnecessary includes iommu/vt-d: Remove unnecessary prototypes iommu/vt-d: Fix indentation of goto labels Marco Bonelli (1): iommu/vt-d: Add missing "__init" for rmrr_sanity_check() Yian Chen (1): iommu/vt-d: Enable ATS for the devices in SATC table YueHaibing (1): iommu/vt-d: Remove unused function intel_svm_capable() include/linux/intel-iommu.h | 6 +- drivers/iommu/intel/debugfs.c | 3 +- drivers/iommu/intel/dmar.c| 2 - drivers/iommu/intel/iommu.c | 461 +- drivers/iommu/intel/pasid.c | 12 +- drivers/iommu/intel/svm.c | 11 +- 6 files changed, 133 insertions(+), 362 deletions(-) -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/iova: Reset max32_alloc_size after cleaning rcache in the fail path
From: Yunfei Wang
In alloc_iova_fast function, if __alloc_and_insert_iova_range fail,
alloc_iova_fast will try flushing rcache and retry alloc iova, but
this has an issue:
Since __alloc_and_insert_iova_range fail will set the current alloc
iova size to max32_alloc_size (iovad->max32_alloc_size = size),
when the retry is executed into the __alloc_and_insert_iova_range
function, the retry action will be blocked by the check condition
(size >= iovad->max32_alloc_size) and goto iova32_full directly,
causes the action of retry regular alloc iova in
__alloc_and_insert_iova_range to not actually be executed.
Based on the above, so need reset max32_alloc_size before retry alloc
iova when alloc iova fail, that is set the initial dma_32bit_pfn value
of iovad to max32_alloc_size, so that the action of retry alloc iova
in __alloc_and_insert_iova_range can be executed.
Signed-off-by: Yunfei Wang
---
drivers/iommu/iova.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index b28c9435b898..0c085ae8293f 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -453,6 +453,7 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long
size,
retry:
new_iova = alloc_iova(iovad, size, limit_pfn, true);
if (!new_iova) {
+ unsigned long flags;
unsigned int cpu;
if (!flush_rcache)
@@ -463,6 +464,12 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long
size,
for_each_online_cpu(cpu)
free_cpu_cached_iovas(cpu, iovad);
free_global_cached_iovas(iovad);
+
+ /* Reset max32_alloc_size after flushing rcache for retry */
+ spin_lock_irqsave(>iova_rbtree_lock, flags);
+ iovad->max32_alloc_size = iovad->dma_32bit_pfn;
+ spin_unlock_irqrestore(>iova_rbtree_lock, flags);
+
goto retry;
}
--
2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] kernel: dma-debug: fix return value of __setup handlers
When valid kernel command line parameters
dma_debug=off dma_debug_entries=100
are used, they are reported as Unknown parameters and added to init's
environment strings, polluting it.
Unknown kernel command line parameters "BOOT_IMAGE=/boot/bzImage-517rc5
dma_debug=off dma_debug_entries=100", will be passed to user space.
and
Run /sbin/init as init process
with arguments:
/sbin/init
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc5
dma_debug=off
dma_debug_entries=100
Return 1 from these __setup handlers to indicate that the command line
option has been handled.
Fixes: 59d3daafa1726 ("dma-debug: add kernel command line parameters")
Signed-off-by: Randy Dunlap
Reported-by: Igor Zhbanov
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0de...@omprussia.ru
Cc: Joerg Roedel
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: iommu@lists.linux-foundation.org
Cc: Robin Murphy
---
kernel/dma/debug.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20220228.orig/kernel/dma/debug.c
+++ linux-next-20220228/kernel/dma/debug.c
@@ -927,7 +927,7 @@ static __init int dma_debug_cmdline(char
global_disable = true;
}
- return 0;
+ return 1;
}
static __init int dma_debug_entries_cmdline(char *str)
@@ -936,7 +936,7 @@ static __init int dma_debug_entries_cmdl
return -EINVAL;
if (!get_option(, _prealloc_entries))
nr_prealloc_entries = PREALLOC_DMA_DEBUG_ENTRIES;
- return 0;
+ return 1;
}
__setup("dma_debug=", dma_debug_cmdline);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 10/11] vfio: Remove iommu group notifier
On Mon, 28 Feb 2022 08:50:55 +0800 Lu Baolu wrote: > The iommu core and driver core have been enhanced to avoid unsafe driver > binding to a live group after iommu_group_set_dma_owner(PRIVATE_USER) > has been called. There's no need to register iommu group notifier. This > removes the iommu group notifer which contains BUG_ON() and WARN(). > > Signed-off-by: Lu Baolu > Reviewed-by: Jason Gunthorpe > --- > drivers/vfio/vfio.c | 147 > 1 file changed, 147 deletions(-) Acked-by: Alex Williamson ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 09/11] vfio: Delete the unbound_list
On Mon, 28 Feb 2022 08:50:54 +0800
Lu Baolu wrote:
> From: Jason Gunthorpe
>
> commit 60720a0fc646 ("vfio: Add device tracking during unbind") added the
> unbound list to plug a problem with KVM where KVM_DEV_VFIO_GROUP_DEL
> relied on vfio_group_get_external_user() succeeding to return the
> vfio_group from a group file descriptor. The unbound list allowed
> vfio_group_get_external_user() to continue to succeed in edge cases.
>
> However commit 5d6dee80a1e9 ("vfio: New external user group/file match")
> deleted the call to vfio_group_get_external_user() during
> KVM_DEV_VFIO_GROUP_DEL. Instead vfio_external_group_match_file() is used
> to directly match the file descriptor to the group pointer.
>
> This in turn avoids the call down to vfio_dev_viable() during
> KVM_DEV_VFIO_GROUP_DEL and also avoids the trouble the first commit was
> trying to fix.
>
> There are no other users of vfio_dev_viable() that care about the time
> after vfio_unregister_group_dev() returns, so simply delete the
> unbound_list entirely.
>
> Reviewed-by: Chaitanya Kulkarni
> Signed-off-by: Jason Gunthorpe
> Signed-off-by: Lu Baolu
> ---
> drivers/vfio/vfio.c | 74 ++---
> 1 file changed, 2 insertions(+), 72 deletions(-)
Acked-by: Alex Williamson
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 08/11] vfio: Remove use of vfio_group_viable()
On Mon, 28 Feb 2022 08:50:53 +0800 Lu Baolu wrote: > As DMA ownership is claimed for the iommu group when a VFIO group is > added to a VFIO container, the VFIO group viability is guaranteed as long > as group->container_users > 0. Remove those unnecessary group viability > checks which are only hit when group->container_users is not zero. > > The only remaining reference is in GROUP_GET_STATUS, which could be called > at any time when group fd is valid. Here we just replace the > vfio_group_viable() by directly calling IOMMU core to get viability status. > > Signed-off-by: Lu Baolu > Reviewed-by: Jason Gunthorpe > --- > drivers/vfio/vfio.c | 18 ++ > 1 file changed, 6 insertions(+), 12 deletions(-) Acked-by: Alex Williamson ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 07/11] vfio: Set DMA ownership for VFIO devices
On Mon, 28 Feb 2022 08:50:52 +0800 Lu Baolu wrote: > Claim group dma ownership when an IOMMU group is set to a container, > and release the dma ownership once the iommu group is unset from the > container. > > This change disallows some unsafe bridge drivers to bind to non-ACS > bridges while devices under them are assigned to user space. This is an > intentional enhancement and possibly breaks some existing > configurations. The recommendation to such an affected user would be > that the previously allowed host bridge driver was unsafe for this use > case and to continue to enable assignment of devices within that group, > the driver should be unbound from the bridge device or replaced with the > pci-stub driver. > > For any bridge driver, we consider it unsafe if it satisfies any of the > following conditions: > > 1) The bridge driver uses DMA. Calling pci_set_master() or calling any > kernel DMA API (dma_map_*() and etc.) is an indicate that the > driver is doing DMA. > > 2) If the bridge driver uses MMIO, it should be tolerant to hostile > userspace also touching the same MMIO registers via P2P DMA > attacks. > > If the bridge driver turns out to be a safe one, it could be used as > before by setting the driver's .driver_managed_dma field, just like what > we have done in the pcieport driver. > > Signed-off-by: Lu Baolu > Reviewed-by: Jason Gunthorpe > --- > drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 + > drivers/vfio/pci/vfio_pci.c | 1 + > drivers/vfio/platform/vfio_amba.c | 1 + > drivers/vfio/platform/vfio_platform.c | 1 + > drivers/vfio/vfio.c | 10 +- > 5 files changed, 13 insertions(+), 1 deletion(-) Acked-by: Alex Williamson ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Add RPLS to quirk list to skip TE disabling
On Sat, 2022-02-26 at 14:40 +0800, Lu Baolu wrote: > On 2/25/22 10:12 PM, Vivi, Rodrigo wrote: > > On Fri, 2022-02-25 at 10:20 +0800, Lu Baolu wrote: > > > On 2/24/22 9:39 PM, Vivi, Rodrigo wrote: > > > > On Thu, 2022-02-24 at 13:42 +0800, Lu Baolu wrote: > > > > > On 2/23/22 2:29 PM, Tejas Upadhyay wrote: > > > > > > The VT-d spec requires (10.4.4 Global Command Register, TE > > > > > > field) that: > > > > > > > > > > > > Hardware implementations supporting DMA draining must drain > > > > > > any in-flight DMA read/write requests queued within the > > > > > > Root-Complex before completing the translation enable > > > > > > command and reflecting the status of the command through > > > > > > the TES field in the Global Status register. > > > > > > > > > > > > Unfortunately, some integrated graphic devices fail to do > > > > > > so after some kind of power state transition. As the > > > > > > result, the system might stuck in iommu_disable_translati > > > > > > on(), waiting for the completion of TE transition. > > > > > > > > > > > > This adds RPLS to a quirk list for those devices and skips > > > > > > TE disabling if the qurik hits. > > > > > > > > > > > > Fixes:https://gitlab.freedesktop.org/drm/intel/- > > > > > > /issues/4898 > > > > > > Fixes: LCK-10789 > > > > > Remove this please. > > > > good catch. Wrong use of Fixes tag. > > > > "Fixes:" should only be used for patches fixing other patches > > > > and > > > > mentioning the commit id. > > > This is still a fix patch, right? If so, > > > > > > Fixes: b1012ca8dc4f9 "iommu/vt-d: Skip TE disabling on quirky gfx > > > dedicated iommu" > > > Cc:sta...@vger.kernel.org > > hm... you have a point, but I'm not comfortable with this because > > for me it is like an addition of a pci id of a new platform. > > Older kernels won't have the support for that anyway. > > and if for every new platform we add here we need to blame this > > b1012ca8dc4f9 (which did the right time when it was created) > > it doesn't look fair to me. > > I have no idea about the graphic roadmap. So I'd like you to decide > it. okay, so no Fixes or CC-stable it is. > > > > > > > Baolu, > > > > could you mind if we use > > > > > > > > Closes:https://gitlab.freedesktop.org/drm/intel/-/issues/4898 > > > > > > > > or maybe > > > > > > > > References:https://gitlab.freedesktop.org/drm/intel/- > > > > /issues/4898 > > > > > > > > This last one seems to be the one use in drivers/iommu > > > > and the Closes is what we use in drm-intel, hence the one used > > > > with gitlab.freedesktop links in general. > > > How about "Link:"? > > > > > > As Documentation/process/submitting-patches.rst states: > > > > > > If related discussions or any other background information behind > > > the > > > change > > > can be found on the web, add 'Link:' tags pointing to it. In case > > > your patch > > > fixes a bug, for example, add a tag with a URL referencing the > > > report > > > in the > > > mailing list archives or a bug tracker; if the patch is a result > > > of > > > some > > > earlier mailing list discussion or something documented on the > > > web, > > > point to > > > it. > > yeap, "Link:" works well too. Tejas, please change it to "Link:" > > > > With these changes could we get your ack to merge to drm-intel? > > This change in VT-d driver looks good to me. > > Acked-by: Lu Baolu and please resend to intel-gfx cc'ing the iommu mailing list. no topic/core-for-CI prefix this time, just a clean submission so we can get that and apply to drm-intel/drm-intel-next after passing our CI. Thank you all, Rodrigo. > > Best regards, > baolu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 06/11] PCI: portdrv: Set driver_managed_dma
On Mon, Feb 28, 2022 at 08:50:51AM +0800, Lu Baolu wrote:
> If a switch lacks ACS P2P Request Redirect, a device below the switch can
> bypass the IOMMU and DMA directly to other devices below the switch, so
> all the downstream devices must be in the same IOMMU group as the switch
> itself.
>
> The existing VFIO framework allows the portdrv driver to be bound to the
> bridge while its downstream devices are assigned to user space. The
> pci_dma_configure() marks the IOMMU group as containing only devices
> with kernel drivers that manage DMA. Avoid this default behavior for the
> portdrv driver in order for compatibility with the current VFIO usage.
It would be nice to explicitly say here how we can look at portdrv
(and pci_stub) and conclude that ".driver_managed_dma = true" is safe.
Otherwise I won't know what kind of future change to portdrv might
make it unsafe.
> Suggested-by: Jason Gunthorpe
> Suggested-by: Kevin Tian
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pcie/portdrv_pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
> index 35eca6277a96..6b2adb678c21 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -202,6 +202,8 @@ static struct pci_driver pcie_portdriver = {
>
> .err_handler= _portdrv_err_handler,
>
> + .driver_managed_dma = true,
> +
> .driver.pm = PCIE_PORTDRV_PM_OPS,
> };
>
> --
> 2.25.1
>
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 05/11] PCI: pci_stub: Set driver_managed_dma
On Mon, Feb 28, 2022 at 08:50:50AM +0800, Lu Baolu wrote:
> The current VFIO implementation allows pci-stub driver to be bound to
> a PCI device with other devices in the same IOMMU group being assigned
> to userspace. The pci-stub driver has no dependencies on DMA or the
> IOVA mapping of the device, but it does prevent the user from having
> direct access to the device, which is useful in some circumstances.
>
> The pci_dma_configure() marks the iommu_group as containing only devices
> with kernel drivers that manage DMA. For compatibility with the VFIO
> usage, avoid this default behavior for the pci_stub. This allows the
> pci_stub still able to be used by the admin to block driver binding after
> applying the DMA ownership to VFIO.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pci-stub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/pci-stub.c b/drivers/pci/pci-stub.c
> index e408099fea52..d1f4c1ce7bd1 100644
> --- a/drivers/pci/pci-stub.c
> +++ b/drivers/pci/pci-stub.c
> @@ -36,6 +36,7 @@ static struct pci_driver stub_driver = {
> .name = "pci-stub",
> .id_table = NULL, /* only dynamic id's */
> .probe = pci_stub_probe,
> + .driver_managed_dma = true,
> };
>
> static int __init pci_stub_init(void)
> --
> 2.25.1
>
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful
From: Christoph Hellwig Sent: Monday, February 28, 2022 3:31 AM > > On Mon, Feb 28, 2022 at 02:53:39AM +, Michael Kelley (LINUX) wrote: > > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 > > AM > > > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > > addressing needs and replace the verbose argument with a set of > > > flags, including one to force enable bounce buffering. > > > > > > Note that this patch removes the possibility to force xen-swiotlb > > > use using swiotlb=force on the command line on x86 (arm and arm64 > > > never supported that), but this interface will be restored shortly. > > > > > > Signed-off-by: Christoph Hellwig > > > --- > > > arch/arm/mm/init.c | 6 + > > > arch/arm64/mm/init.c | 6 + > > > arch/ia64/mm/init.c| 4 +-- > > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > > arch/mips/loongson64/dma.c | 2 +- > > > arch/mips/sibyte/common/dma.c | 2 +- > > > arch/powerpc/include/asm/swiotlb.h | 1 + > > > arch/powerpc/mm/mem.c | 3 ++- > > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > > arch/riscv/mm/init.c | 8 +- > > > arch/s390/mm/init.c| 3 +-- > > > arch/x86/kernel/cpu/mshyperv.c | 8 -- > > > arch/x86/kernel/pci-dma.c | 15 ++- > > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > > drivers/xen/swiotlb-xen.c | 4 +-- > > > include/linux/swiotlb.h| 15 ++- > > > include/trace/events/swiotlb.h | 29 - > > > kernel/dma/swiotlb.c | 35 ++ > > > 18 files changed, 56 insertions(+), 93 deletions(-) > > > > [snip] > > > > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c > > > b/arch/x86/kernel/cpu/mshyperv.c > > > index 5a99f993e6392..568274917f1cd 100644 > > > --- a/arch/x86/kernel/cpu/mshyperv.c > > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > > swiotlb_unencrypted_base = > ms_hyperv.shared_gpa_boundary; > > > #endif > > > } > > > - > > > -#ifdef CONFIG_SWIOTLB > > > - /* > > > - * Enable swiotlb force mode in Isolation VM to > > > - * use swiotlb bounce buffer for dma transaction. > > > - */ > > > - swiotlb_force = SWIOTLB_FORCE; > > > -#endif > > > > With this code removed, it's not clear to me what forces the use of the > > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() > > doesn't > > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > > looking more closely at the meaning of the CC_ATTR_* values, and it may > > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". > > Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. > I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well > there? I'm unsure. The comments for CC_ATTR_HOST_MEM_ENCRYPT indicates that it is for SME. The comments for both CC_ATTR_MEM_ENCRYPT and CC_ATTR_GUEST_MEM_ENCRYPT mention SEV and SEV-ES (and presumably SEV-SNP). But I haven't looked at the details of the core SNP patches from the AMD folks. I'd say that they need to weigh in on the right approach here that will work for both SME and the various SEV flavors, and then hopefully the Hyper-V case will fit in. Michael ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 00/34] MT8195 IOMMU SUPPORT
Il 28/02/22 13:34, Joerg Roedel ha scritto: Hi Yong Wu, On Thu, Feb 17, 2022 at 07:34:19PM +0800, Yong Wu wrote: Yong Wu (34): dt-bindings: mediatek: mt8195: Add binding for MM IOMMU dt-bindings: mediatek: mt8195: Add binding for infra IOMMU iommu/mediatek: Fix 2 HW sharing pgtable issue iommu/mediatek: Add list_del in mtk_iommu_remove iommu/mediatek: Remove clk_disable in mtk_iommu_remove iommu/mediatek: Add mutex for m4u_group and m4u_dom in data iommu/mediatek: Add mutex for data in the mtk_iommu_domain iommu/mediatek: Adapt sharing and non-sharing pgtable case iommu/mediatek: Add 12G~16G support for multi domains iommu/mediatek: Add a flag DCM_DISABLE iommu/mediatek: Add a flag NON_STD_AXI iommu/mediatek: Remove the granule in the tlb flush iommu/mediatek: Always enable output PA over 32bits in isr iommu/mediatek: Add SUB_COMMON_3BITS flag iommu/mediatek: Add IOMMU_TYPE flag iommu/mediatek: Contain MM IOMMU flow with the MM TYPE iommu/mediatek: Adjust device link when it is sub-common iommu/mediatek: Allow IOMMU_DOMAIN_UNMANAGED for PCIe VFIO iommu/mediatek: Add a PM_CLK_AO flag for infra iommu iommu/mediatek: Add infra iommu support iommu/mediatek: Add PCIe support iommu/mediatek: Add mt8195 support iommu/mediatek: Only adjust code about register base iommu/mediatek: Just move code position in hw_init iommu/mediatek: Separate mtk_iommu_data for v1 and v2 iommu/mediatek: Remove mtk_iommu.h iommu/mediatek-v1: Just rename mtk_iommu to mtk_iommu_v1 iommu/mediatek: Add mtk_iommu_bank_data structure iommu/mediatek: Initialise bank HW for each a bank iommu/mediatek: Change the domid to iova_region_id iommu/mediatek: Get the proper bankid for multi banks iommu/mediatek: Initialise/Remove for multi bank dev iommu/mediatek: Backup/restore regsiters for multi banks iommu/mediatek: mt8195: Enable multi banks for infra iommu This doesn't apply cleanly, can you please send a version rebased to v5.17-rc4? Thanks, Joerg Hello Joerg, this series depends on the following series: https://patchwork.kernel.org/project/linux-mediatek/list/?series=592275 ...which is also well tested and ready to be merged in. Applying Yong's series without the mentioned series from Dafna would not work. Thanks, Angelo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
On Mon, Feb 21, 2022 at 01:33:48PM +0800, Lu Baolu wrote:
> Fixes: 474dd1c65064 ("iommu/vt-d: Fix clearing real DMA device's
> scalable-mode context entries")
> Cc: sta...@vger.kernel.org # v5.14+
> Signed-off-by: Adrian Huang
> Link: https://lore.kernel.org/r/20220216091307.703-1-adrianhuang0...@gmail.com
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied for v5.17, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/5] iommu/amd: Cleanup and fixes
On Mon, Feb 21, 2022 at 10:29:11AM +0530, Vasant Hegde wrote: > This series contains various cleanup and trivial fixes. > > Suravee Suthikulpanit (2): > iommu/amd: Improve error handling for amd_iommu_init_pci > iommu/amd: Improve amd_iommu_v2_exit() > > Vasant Hegde (3): > iommu/amd: Call memunmap in error path > iommu/amd: Clean up function declarations > iommu/amd: Remove unused struct fault.devid > > drivers/iommu/amd/amd_iommu.h | 4 > drivers/iommu/amd/init.c | 16 > drivers/iommu/amd/iommu_v2.c | 35 +-- > 3 files changed, 29 insertions(+), 26 deletions(-) Besides the error messages in the first patch this looks good to me. Please re-send with the updates and I consider it for v5.18. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/5] iommu/amd: Improve error handling for amd_iommu_init_pci
On Mon, Feb 21, 2022 at 10:29:12AM +0530, Vasant Hegde wrote:
> From: Suravee Suthikulpanit
>
> Add error messages to prevent silent failure.
>
> Signed-off-by: Suravee Suthikulpanit
> Signed-off-by: Vasant Hegde
> ---
> drivers/iommu/amd/init.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> index 1eacd43cb436..770ac679b682 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -1942,9 +1942,10 @@ static int __init amd_iommu_init_pci(void)
>
> for_each_iommu(iommu) {
> ret = iommu_init_pci(iommu);
> - if (ret)
> - break;
> -
> + if (ret) {
> + pr_err("IOMMU:%d Failed to initialize!\n",
> iommu->index);
Please make that message "IOMMU%d: Failed to initialize IOMMU Hardware
(error=%d)!\n".
> + goto out;
> + }
> /* Need to setup range after PCI init */
> iommu_set_cwwb_range(iommu);
> }
> @@ -1960,6 +1961,10 @@ static int __init amd_iommu_init_pci(void)
>* active.
>*/
> ret = amd_iommu_init_api();
> + if (ret) {
> + pr_err("IOMMU: Failed to initialize api!\n");
And that "IOMMU: Failed to initialize IOMMU-API interface (error=%d)!\n"
> + goto out;
> + }
>
> init_device_table_dma();
>
> @@ -1969,6 +1974,7 @@ static int __init amd_iommu_init_pci(void)
> if (!ret)
> print_iommu_info();
>
> +out:
> return ret;
> }
>
> --
> 2.27.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 00/34] MT8195 IOMMU SUPPORT
Hi Yong Wu, On Thu, Feb 17, 2022 at 07:34:19PM +0800, Yong Wu wrote: > Yong Wu (34): > dt-bindings: mediatek: mt8195: Add binding for MM IOMMU > dt-bindings: mediatek: mt8195: Add binding for infra IOMMU > iommu/mediatek: Fix 2 HW sharing pgtable issue > iommu/mediatek: Add list_del in mtk_iommu_remove > iommu/mediatek: Remove clk_disable in mtk_iommu_remove > iommu/mediatek: Add mutex for m4u_group and m4u_dom in data > iommu/mediatek: Add mutex for data in the mtk_iommu_domain > iommu/mediatek: Adapt sharing and non-sharing pgtable case > iommu/mediatek: Add 12G~16G support for multi domains > iommu/mediatek: Add a flag DCM_DISABLE > iommu/mediatek: Add a flag NON_STD_AXI > iommu/mediatek: Remove the granule in the tlb flush > iommu/mediatek: Always enable output PA over 32bits in isr > iommu/mediatek: Add SUB_COMMON_3BITS flag > iommu/mediatek: Add IOMMU_TYPE flag > iommu/mediatek: Contain MM IOMMU flow with the MM TYPE > iommu/mediatek: Adjust device link when it is sub-common > iommu/mediatek: Allow IOMMU_DOMAIN_UNMANAGED for PCIe VFIO > iommu/mediatek: Add a PM_CLK_AO flag for infra iommu > iommu/mediatek: Add infra iommu support > iommu/mediatek: Add PCIe support > iommu/mediatek: Add mt8195 support > iommu/mediatek: Only adjust code about register base > iommu/mediatek: Just move code position in hw_init > iommu/mediatek: Separate mtk_iommu_data for v1 and v2 > iommu/mediatek: Remove mtk_iommu.h > iommu/mediatek-v1: Just rename mtk_iommu to mtk_iommu_v1 > iommu/mediatek: Add mtk_iommu_bank_data structure > iommu/mediatek: Initialise bank HW for each a bank > iommu/mediatek: Change the domid to iova_region_id > iommu/mediatek: Get the proper bankid for multi banks > iommu/mediatek: Initialise/Remove for multi bank dev > iommu/mediatek: Backup/restore regsiters for multi banks > iommu/mediatek: mt8195: Enable multi banks for infra iommu This doesn't apply cleanly, can you please send a version rebased to v5.17-rc4? Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 0/9] iommu cleanup and refactoring
On Wed, Feb 16, 2022 at 10:52:40AM +0800, Lu Baolu wrote: > Lu Baolu (9): > iommu/vt-d: Remove guest pasid related callbacks > iommu: Remove guest pasid related interfaces and definitions > iommu/vt-d: Remove aux-domain related callbacks > iommu: Remove aux-domain related interfaces and iommu_ops > iommu: Remove apply_resv_region > drm/nouveau/device: Get right pgsize_bitmap of iommu_domain > iommu: Use right way to retrieve iommu_ops > iommu: Remove unused argument in is_attach_deferred > iommu: Split struct iommu_ops Applied to core branch, thanks Baolu! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] dma-mapping: remove CONFIG_DMA_REMAP
CONFIG_DMA_REMAP is used to build a few helpers around the core
vmalloc code, and to use them in case there is a highmem page in
dma-direct, and to make dma coherent allocations be able to use
non-contiguous pages allocations for DMA allocations in the dma-iommu
layer.
Right now it needs to be explicitly selected by architectures, and
is only done so by architectures that require remapping to deal
with devices that are not DMA coherent. Make it unconditional for
builds with CONFIG_MMU as it is very little extra code, but makes
it much more likely that large DMA allocations succeed on x86.
This fixes hot plugging a NVMe thunderbolt SSD for me, which tries
to allocate a 1MB buffer that is otherwise hard to obtain due to
memory fragmentation on a heavily used laptop.
Signed-off-by: Christoph Hellwig
Reviewed-by: Robin Murphy
---
Changes since v1:
- drop a not required CONFIG_MMU check
arch/arm/Kconfig | 2 +-
arch/xtensa/Kconfig | 2 +-
drivers/iommu/dma-iommu.c | 14 +-
kernel/dma/Kconfig| 7 +--
kernel/dma/Makefile | 2 +-
kernel/dma/direct.c | 18 +++---
6 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c97cb40eebb6..83fb277e50759 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -47,7 +47,7 @@ config ARM
select DMA_DECLARE_COHERENT
select DMA_GLOBAL_POOL if !MMU
select DMA_OPS
- select DMA_REMAP if MMU
+ select DMA_NONCOHERENT_MMAP if MMU
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
select GENERIC_ALLOCATOR
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index 8ac599aa6d994..76438ee313d16 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -17,7 +17,7 @@ config XTENSA
select BUILDTIME_TABLE_SORT
select CLONE_BACKWARDS
select COMMON_CLK
- select DMA_REMAP if MMU
+ select DMA_NONCOHERENT_MMAP if MMU
select GENERIC_ATOMIC64
select GENERIC_IRQ_SHOW
select GENERIC_PCI_IOMAP
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d85d54f2b5496..cebced7ddf390 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -852,7 +852,6 @@ static void *iommu_dma_alloc_remap(struct device *dev,
size_t size,
return NULL;
}
-#ifdef CONFIG_DMA_REMAP
static struct sg_table *iommu_dma_alloc_noncontiguous(struct device *dev,
size_t size, enum dma_data_direction dir, gfp_t gfp,
unsigned long attrs)
@@ -882,7 +881,6 @@ static void iommu_dma_free_noncontiguous(struct device
*dev, size_t size,
sg_free_table(>sgt);
kfree(sh);
}
-#endif /* CONFIG_DMA_REMAP */
static void iommu_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
@@ -1276,7 +1274,7 @@ static void __iommu_dma_free(struct device *dev, size_t
size, void *cpu_addr)
dma_free_from_pool(dev, cpu_addr, alloc_size))
return;
- if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) {
+ if (is_vmalloc_addr(cpu_addr)) {
/*
* If it the address is remapped, then it's either non-coherent
* or highmem CMA, or an iommu_dma_alloc_remap() construction.
@@ -1318,7 +1316,7 @@ static void *iommu_dma_alloc_pages(struct device *dev,
size_t size,
if (!page)
return NULL;
- if (IS_ENABLED(CONFIG_DMA_REMAP) && (!coherent || PageHighMem(page))) {
+ if (!coherent || PageHighMem(page)) {
pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
cpu_addr = dma_common_contiguous_remap(page, alloc_size,
@@ -1350,7 +1348,7 @@ static void *iommu_dma_alloc(struct device *dev, size_t
size,
gfp |= __GFP_ZERO;
- if (IS_ENABLED(CONFIG_DMA_REMAP) && gfpflags_allow_blocking(gfp) &&
+ if (gfpflags_allow_blocking(gfp) &&
!(attrs & DMA_ATTR_FORCE_CONTIGUOUS)) {
return iommu_dma_alloc_remap(dev, size, handle, gfp,
dma_pgprot(dev, PAGE_KERNEL, attrs), attrs);
@@ -1391,7 +1389,7 @@ static int iommu_dma_mmap(struct device *dev, struct
vm_area_struct *vma,
if (off >= nr_pages || vma_pages(vma) > nr_pages - off)
return -ENXIO;
- if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) {
+ if (is_vmalloc_addr(cpu_addr)) {
struct page **pages = dma_common_find_pages(cpu_addr);
if (pages)
@@ -1413,7 +1411,7 @@ static int iommu_dma_get_sgtable(struct device *dev,
struct sg_table *sgt,
struct page *page;
int ret;
- if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) {
+ if (is_vmalloc_addr(cpu_addr)) {
struct page **pages = dma_common_find_pages(cpu_addr);
if (pages) {
@@ -1445,10
Re: [PATCH v2 2/2] iommu/mediatek: Add mt8186 iommu support
On 23/02/2022 08:24, Yong Wu wrote:
Add mt8186 iommu supports.
Signed-off-by: Anan Sun
Signed-off-by: Yong Wu
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d9ca9ffe404c..174a2f3bd68a 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -160,6 +160,7 @@ enum mtk_iommu_plat {
M4U_MT8167,
M4U_MT8173,
M4U_MT8183,
+ M4U_MT8186,
M4U_MT8192,
M4U_MT8195,
};
@@ -1438,6 +1439,21 @@ static const struct mtk_iommu_plat_data mt8183_data = {
.larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
+static const struct mtk_iommu_plat_data mt8186_data_mm = {
+ .m4u_plat = M4U_MT8186,
+ .flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
+ WR_THROT_EN | IOVA_34_EN | NOT_STD_AXI_MODE |
+ MTK_IOMMU_TYPE_MM,
+ .larbid_remap = {{0}, {1, MTK_INVALID_LARBID, 8}, {4}, {7}, {2}, {9,
11, 19, 20},
+ {MTK_INVALID_LARBID, 14, 16},
+ {MTK_INVALID_LARBID, 13, MTK_INVALID_LARBID, 17}},
+ .inv_sel_reg= REG_MMU_INV_SEL_GEN2,
+ .banks_num = 1,
+ .banks_enable = {true},
+ .iova_region= mt8192_multi_dom,
+ .iova_region_nr = ARRAY_SIZE(mt8192_multi_dom),
+};
+
static const struct mtk_iommu_plat_data mt8192_data = {
.m4u_plat = M4U_MT8192,
.flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
@@ -1507,6 +1523,7 @@ static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt8167-m4u", .data = _data},
{ .compatible = "mediatek,mt8173-m4u", .data = _data},
{ .compatible = "mediatek,mt8183-m4u", .data = _data},
+ { .compatible = "mediatek,mt8186-iommu-mm",.data =
_data_mm}, /* mm: m4u */
{ .compatible = "mediatek,mt8192-m4u", .data = _data},
{ .compatible = "mediatek,mt8195-iommu-infra", .data =
_data_infra},
{ .compatible = "mediatek,mt8195-iommu-vdo", .data =
_data_vdo},
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] dt-bindings: mediatek: mt8186: Add binding for MM iommu
On 23/02/2022 08:24, Yong Wu wrote: Add mt8186 iommu binding. "-mm" means the iommu is for Multimedia. Signed-off-by: Yong Wu Acked-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Reviewed-by: Matthias Brugger --- .../bindings/iommu/mediatek,iommu.yaml| 4 + .../dt-bindings/memory/mt8186-memory-port.h | 217 ++ 2 files changed, 221 insertions(+) create mode 100644 include/dt-bindings/memory/mt8186-memory-port.h diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index c528a299afa9..d78df484bb76 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -76,6 +76,7 @@ properties: - mediatek,mt8167-m4u # generation two - mediatek,mt8173-m4u # generation two - mediatek,mt8183-m4u # generation two + - mediatek,mt8186-iommu-mm # generation two - mediatek,mt8192-m4u # generation two - mediatek,mt8195-iommu-vdo# generation two - mediatek,mt8195-iommu-vpp# generation two @@ -120,6 +121,7 @@ properties: dt-binding/memory/mt8167-larb-port.h for mt8167, dt-binding/memory/mt8173-larb-port.h for mt8173, dt-binding/memory/mt8183-larb-port.h for mt8183, + dt-binding/memory/mt8186-memory-port.h for mt8186, dt-binding/memory/mt8192-larb-port.h for mt8192. dt-binding/memory/mt8195-memory-port.h for mt8195. @@ -141,6 +143,7 @@ allOf: - mediatek,mt2701-m4u - mediatek,mt2712-m4u - mediatek,mt8173-m4u + - mediatek,mt8186-iommu-mm - mediatek,mt8192-m4u - mediatek,mt8195-iommu-vdo - mediatek,mt8195-iommu-vpp @@ -153,6 +156,7 @@ allOf: properties: compatible: enum: +- mediatek,mt8186-iommu-mm - mediatek,mt8192-m4u - mediatek,mt8195-iommu-vdo - mediatek,mt8195-iommu-vpp diff --git a/include/dt-bindings/memory/mt8186-memory-port.h b/include/dt-bindings/memory/mt8186-memory-port.h new file mode 100644 index ..bda265725870 --- /dev/null +++ b/include/dt-bindings/memory/mt8186-memory-port.h @@ -0,0 +1,217 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2022 MediaTek Inc. + * + * Author: Anan Sun + * Author: Yong Wu + */ +#ifndef _DT_BINDINGS_MEMORY_MT8186_LARB_PORT_H_ +#define _DT_BINDINGS_MEMORY_MT8186_LARB_PORT_H_ + +#include + +/* + * MM IOMMU supports 16GB dma address. We separate it to four ranges: + * 0 ~ 4G; 4G ~ 8G; 8G ~ 12G; 12G ~ 16G, we could adjust these masters + * locate in anyone bank. BUT: + * a) Make sure all the ports inside a larb are in one range. + * b) The iova of any master can NOT cross the 4G/8G/12G boundary. + * + * This is the suggested mapping in this SoC: + * + * modulesdma-address-region larbs-ports + * disp 0 ~ 4G larb0/1/2 + * vcodec 4G ~ 8G larb4/7 + * cam/mdp 8G ~ 12G the other larbs. + * N/A 12G ~ 16G + * CCU0 0x24000_ ~ 0x243ff_ larb13: port 9/10 + * CCU1 0x24400_ ~ 0x247ff_ larb14: port 4/5 + */ + +/* MM IOMMU ports */ +/* LARB 0 -- MMSYS */ +#define IOMMU_PORT_L0_DISP_POSTMASK0 MTK_M4U_ID(0, 0) +#define IOMMU_PORT_L0_REVERSED MTK_M4U_ID(0, 1) +#define IOMMU_PORT_L0_OVL_RDMA0MTK_M4U_ID(0, 2) +#define IOMMU_PORT_L0_DISP_FAKE0 MTK_M4U_ID(0, 3) + +/* LARB 1 -- MMSYS */ +#define IOMMU_PORT_L1_DISP_RDMA1 MTK_M4U_ID(1, 0) +#define IOMMU_PORT_L1_OVL_2L_RDMA0 MTK_M4U_ID(1, 1) +#define IOMMU_PORT_L1_DISP_RDMA0 MTK_M4U_ID(1, 2) +#define IOMMU_PORT_L1_DISP_WDMA0 MTK_M4U_ID(1, 3) +#define IOMMU_PORT_L1_DISP_FAKE1 MTK_M4U_ID(1, 4) + +/* LARB 2 -- MMSYS */ +#define IOMMU_PORT_L2_MDP_RDMA0MTK_M4U_ID(2, 0) +#define IOMMU_PORT_L2_MDP_RDMA1MTK_M4U_ID(2, 1) +#define IOMMU_PORT_L2_MDP_WROT0MTK_M4U_ID(2, 2) +#define IOMMU_PORT_L2_MDP_WROT1MTK_M4U_ID(2, 3) +#define IOMMU_PORT_L2_DISP_FAKE0 MTK_M4U_ID(2, 4) + +/* LARB 4 -- VDEC */ +#define IOMMU_PORT_L4_HW_VDEC_MC_EXT MTK_M4U_ID(4, 0) +#define IOMMU_PORT_L4_HW_VDEC_UFO_EXT MTK_M4U_ID(4, 1) +#define IOMMU_PORT_L4_HW_VDEC_PP_EXT MTK_M4U_ID(4, 2) +#define IOMMU_PORT_L4_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(4, 3) +#define IOMMU_PORT_L4_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(4, 4) +#define IOMMU_PORT_L4_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(4, 5) +#define IOMMU_PORT_L4_HW_VDEC_TILE_EXT MTK_M4U_ID(4, 6) +#define IOMMU_PORT_L4_HW_VDEC_VLD_EXT MTK_M4U_ID(4, 7) +#define IOMMU_PORT_L4_HW_VDEC_VLD2_EXT MTK_M4U_ID(4, 8) +#define IOMMU_PORT_L4_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(4, 9) +#define
Re: [PATCH] iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find
On Fri, Jan 07, 2022 at 08:09:11AM +, Miaoqian Lin wrote:
> The reference taken by 'of_find_device_by_node()' must be released when
> not needed anymore.
> Add the corresponding 'put_device()' in the error handling path.
>
> Fixes: 765a9d1d02b2 ("iommu/tegra-smmu: Fix mc errors on tegra124-nyan")
> Signed-off-by: Miaoqian Lin
> ---
> drivers/iommu/tegra-smmu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied for v5.17, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful
On Mon, Feb 28, 2022 at 02:53:39AM +, Michael Kelley (LINUX) wrote: > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31 AM > > > > Pass a bool to pass if swiotlb needs to be enabled based on the > > addressing needs and replace the verbose argument with a set of > > flags, including one to force enable bounce buffering. > > > > Note that this patch removes the possibility to force xen-swiotlb > > use using swiotlb=force on the command line on x86 (arm and arm64 > > never supported that), but this interface will be restored shortly. > > > > Signed-off-by: Christoph Hellwig > > --- > > arch/arm/mm/init.c | 6 + > > arch/arm64/mm/init.c | 6 + > > arch/ia64/mm/init.c| 4 +-- > > arch/mips/cavium-octeon/dma-octeon.c | 2 +- > > arch/mips/loongson64/dma.c | 2 +- > > arch/mips/sibyte/common/dma.c | 2 +- > > arch/powerpc/include/asm/swiotlb.h | 1 + > > arch/powerpc/mm/mem.c | 3 ++- > > arch/powerpc/platforms/pseries/setup.c | 3 --- > > arch/riscv/mm/init.c | 8 +- > > arch/s390/mm/init.c| 3 +-- > > arch/x86/kernel/cpu/mshyperv.c | 8 -- > > arch/x86/kernel/pci-dma.c | 15 ++- > > arch/x86/mm/mem_encrypt_amd.c | 3 --- > > drivers/xen/swiotlb-xen.c | 4 +-- > > include/linux/swiotlb.h| 15 ++- > > include/trace/events/swiotlb.h | 29 - > > kernel/dma/swiotlb.c | 35 ++ > > 18 files changed, 56 insertions(+), 93 deletions(-) > > [snip] > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > index 5a99f993e6392..568274917f1cd 100644 > > --- a/arch/x86/kernel/cpu/mshyperv.c > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > @@ -336,14 +336,6 @@ static void __init ms_hyperv_init_platform(void) > > swiotlb_unencrypted_base = > > ms_hyperv.shared_gpa_boundary; > > #endif > > } > > - > > -#ifdef CONFIG_SWIOTLB > > - /* > > -* Enable swiotlb force mode in Isolation VM to > > -* use swiotlb bounce buffer for dma transaction. > > -*/ > > - swiotlb_force = SWIOTLB_FORCE; > > -#endif > > With this code removed, it's not clear to me what forces the use of the > swiotlb in a Hyper-V isolated VM. The code in pci_swiotlb_detect_4g() doesn't > catch this case because cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT) > returns "false" in a Hyper-V guest. In the Hyper-V guest, it's only > cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) that returns "true". I'm > looking more closely at the meaning of the CC_ATTR_* values, and it may > be that Hyper-V should also return "true" for CC_ATTR_MEM_ENCRYPT, > but I don't think CC_ATTR_HOST_MEM_ENCRYPT should return "true". Ok, I assumed that CC_ATTR_HOST_MEM_ENCRYPT returned true in this case. I guess we just need to check for CC_ATTR_GUEST_MEM_ENCRYPT as well there? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dma-mapping: remove CONFIG_DMA_REMAP
On Mon, Feb 28, 2022 at 10:32:54AM +, Robin Murphy wrote: > Is it even possible to hit this case now? From a quick look, all the > architectures defining HIGHMEM either have an explicit dependency on MMU or > don't allow deselecting it anyway (plus I don't see how HIGHMEM && !MMU > could work in general), so I'm pretty sure this whole chunk should go away > now. > > With that (or if there *is* some subtle wacky case where PageHighmem() can > actually return true for !MMU, a comment to remind us in future), No, you're right - I don't think we can support highmem on !CONFIG_MMU. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dma-mapping: remove CONFIG_DMA_REMAP
On 2022-02-27 14:35, Christoph Hellwig wrote:
CONFIG_DMA_REMAP is used to build a few helpers around the core
vmalloc code, and to use them in case there is a highmem page in
dma-direct, and to make dma coherent allocations be able to use
non-contiguous pages allocations for DMA allocations in the dma-iommu
layer.
Right now it needs to be explicitly selected by architectures, and
is only done so by architectures that require remapping to deal
with devices that are not DMA coherent. Make it unconditional for
builds with CONFIG_MMU as it is very little extra code, but makes
it much more likely that large DMA allocations succeed on x86.
This fixes hot plugging a NVMe thunderbolt SSD for me, which tries
to allocate a 1MB buffer that is otherwise hard to obtain due to
memory fragmentation on a heavily used laptop.
Simplifying the maze is most welcome, however one thing stands out...
[...]
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 50f48e9e45987..fe1682fecdd57 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -269,10 +269,10 @@ void *dma_direct_alloc(struct device *dev, size_t size,
/*
* Depending on the cma= arguments and per-arch setup,
* dma_alloc_contiguous could return highmem pages.
-* Without remapping there is no way to return them here, so
-* log an error and fail.
+* Without MMU-based remapping there is no way to return them
+* here, so log an error and fail.
*/
- if (!IS_ENABLED(CONFIG_DMA_REMAP)) {
+ if (!IS_ENABLED(CONFIG_MMU)) {
dev_info(dev, "Rejecting highmem page from CMA.\n");
goto out_free_pages;
}
Is it even possible to hit this case now? From a quick look, all the
architectures defining HIGHMEM either have an explicit dependency on MMU
or don't allow deselecting it anyway (plus I don't see how HIGHMEM &&
!MMU could work in general), so I'm pretty sure this whole chunk should
go away now.
With that (or if there *is* some subtle wacky case where PageHighmem()
can actually return true for !MMU, a comment to remind us in future),
Reviewed-by: Robin Murphy
Cheers,
Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH V2] iommu/vt-d: Add RPLS to quirk list to skip TE disabling
Hi Rodrigo, Looks like "Lu Baolu" has acked patch here https://lore.kernel.org/linux-iommu/20220223062957.31797-1-tejaskumarx.surendrakumar.upadh...@intel.com/T/#u . Can you please push it in drm-intel? Thanks, Tejas > -Original Message- > From: Surendrakumar Upadhyay, TejaskumarX > > Sent: 25 February 2022 10:43 > To: iommu@lists.linux-foundation.org > Cc: Surendrakumar Upadhyay, TejaskumarX > ; Talla, RavitejaX Goud > ; Vivi, Rodrigo ; > sta...@vger.kernel.org > Subject: [PATCH V2] iommu/vt-d: Add RPLS to quirk list to skip TE disabling > > The VT-d spec requires (10.4.4 Global Command Register, TE > field) that: > > Hardware implementations supporting DMA draining must drain any in-flight > DMA read/write requests queued within the Root-Complex before > completing the translation enable command and reflecting the status of the > command through the TES field in the Global Status register. > > Unfortunately, some integrated graphic devices fail to do so after some kind > of power state transition. As the result, the system might stuck in > iommu_disable_translati on(), waiting for the completion of TE transition. > > This adds RPLS to a quirk list for those devices and skips TE disabling if the > qurik hits. > > Fixes: b1012ca8dc4f9 "iommu/vt-d: Skip TE disabling on quirky gfx dedicated > iommu" > Tested-by: Raviteja Goud Talla > Cc: Rodrigo Vivi > Cc: sta...@vger.kernel.org > Signed-off-by: Tejas Upadhyay > > --- > drivers/iommu/intel/iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c > index 92fea3fbbb11..be9487516617 100644 > --- a/drivers/iommu/intel/iommu.c > +++ b/drivers/iommu/intel/iommu.c > @@ -5743,7 +5743,7 @@ static void quirk_igfx_skip_te_disable(struct > pci_dev *dev) > ver = (dev->device >> 8) & 0xff; > if (ver != 0x45 && ver != 0x46 && ver != 0x4c && > ver != 0x4e && ver != 0x8a && ver != 0x98 && > - ver != 0x9a) > + ver != 0x9a && ver != 0xa7) > return; > > if (risky_device(dev)) > -- > 2.34.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 0/5] iommu: Allow IOVA rcache range be configured
On 14/02/2022 17:29, John Garry wrote:
Hi guys,
And a friendly reminder on this series also.
Cheers,
john
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This may be much more pronounced from commit 4e89dce72521 ("iommu/iova:
Retry from last rb tree node if iova search fails"), as discussed at [0].
IOVAs which cannot be cached are highly involved in the IOVA ageing issue,
as discussed at [1].
This series allows the IOVA rcache range be configured, so that we may
cache all IOVAs per domain, thus improving performance.
A new IOMMU group sysfs file is added - max_opt_dma_size - which is used
indirectly to configure the IOVA rcache range:
/sys/kernel/iommu_groups/X/max_opt_dma_size
This file is updated same as how the IOMMU group default domain type is
updated, i.e. must unbind the only device in the group first.
The inspiration here comes from block layer request queue sysfs
"optimal_io_size" file, in /sys/block/sdX/queue/optimal_io_size
Some old figures* for storage scenario (when increasing IOVA rcache range
to cover all DMA mapping sizes from the LLD):
v5.13-rc1 baseline: 1200K IOPS
With series:1800K IOPS
All above are for IOMMU strict mode. Non-strict mode gives ~1800K IOPS in
all scenarios.
Based on v5.17-rc4 + [2]
* I lost my high data throughout test setup
Differences to v4:
https://lore.kernel.org/linux-iommu/1626259003-201303-1-git-send-email-john.ga...@huawei.com/
- Major rebase
- Change the "Refactor iommu_group_store_type()" to not use a callback
and an op type enum instead
- I didn't pick up Will's Ack as it has changed so much
- Use a domain feature flag to keep same default group type
- Add wrapper for default IOVA rcache range
- Combine last 2x patches
[0]
https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leiz...@huawei.com/
[1]
https://lore.kernel.org/linux-iommu/1607538189-237944-1-git-send-email-john.ga...@huawei.com/
[2]
https://lore.kernel.org/linux-iommu/20220203063345-mutt-send-email-...@kernel.org/T/#m5b2b59576d35cad544314470f32e5f40ac5d1fe9
John Garry (5):
iommu: Refactor iommu_group_store_type()
iova: Allow rcache range upper limit to be flexible
iommu: Allow iommu_change_dev_def_domain() realloc same default domain
type
iommu: Allow max opt DMA len be set for a group via sysfs
iova: Add iova_len argument to iova_domain_init_rcaches()
.../ABI/testing/sysfs-kernel-iommu_groups | 16 ++
drivers/iommu/dma-iommu.c | 15 +-
drivers/iommu/iommu.c | 202 +-
drivers/iommu/iova.c | 37 ++--
drivers/vdpa/vdpa_user/iova_domain.c | 4 +-
include/linux/iommu.h | 7 +
include/linux/iova.h | 6 +-
7 files changed, 212 insertions(+), 75 deletions(-)
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iova: Remove forward declarations
On 18/02/2022 16:28, John Garry wrote:
Hi guys,
A friendly reminder on this one.
Cheers,
john
Now that the FQ code has been moved to dma-iommu.c and also the rcache-
related structures have been brought into iova.c, let's rearrange the code
to remove all the forward declarations.
The general order is as follows:
- RB tree code
- iova management
- magazine helpers
- rcache code and "fast" APIs
- iova domain public APIs
Rearrange prototypes in iova.h to follow the same general group ordering.
A couple of pre-existing checkpatch warnings are also remedied:
A suspect indentation is also corrected:
WARNING: suspect code indent for conditional statements (16, 32)
#374: FILE: drivers/iommu/iova.c:194:
+ } else if (overlap)
+ break;
WARNING: Block comments should align the * on each line
#1038: FILE: drivers/iommu/iova.c:787:
+ * fails too and the flush_rcache flag is set then the rcache will be flushed.
+*/
No functional change intended.
Signed-off-by: John Garry
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 7e9c3a97c040..d543131025b3 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -17,75 +17,40 @@
#define IOVA_RANGE_CACHE_MAX_SIZE 6 /* log of max cached IOVA range size (in pages) */
-static bool iova_rcache_insert(struct iova_domain *iovad,
- unsigned long pfn,
- unsigned long size);
-static unsigned long iova_rcache_get(struct iova_domain *iovad,
-unsigned long size,
-unsigned long limit_pfn);
-static void free_cpu_cached_iovas(unsigned int cpu, struct iova_domain *iovad);
-static void free_iova_rcaches(struct iova_domain *iovad);
+/*
+ * Magazine caches for IOVA ranges. For an introduction to magazines,
+ * see the USENIX 2001 paper "Magazines and Vmem: Extending the Slab
+ * Allocator to Many CPUs and Arbitrary Resources" by Bonwick and Adams.
+ * For simplicity, we use a static magazine size and don't implement the
+ * dynamic size tuning described in the paper.
+ */
-static int iova_cpuhp_dead(unsigned int cpu, struct hlist_node *node)
-{
- struct iova_domain *iovad;
+#define IOVA_MAG_SIZE 128
+#define MAX_GLOBAL_MAGS 32 /* magazines per bin */
- iovad = hlist_entry_safe(node, struct iova_domain, cpuhp_dead);
+struct iova_magazine {
+ unsigned long size;
+ unsigned long pfns[IOVA_MAG_SIZE];
+};
- free_cpu_cached_iovas(cpu, iovad);
- return 0;
-}
+struct iova_cpu_rcache {
+ spinlock_t lock;
+ struct iova_magazine *loaded;
+ struct iova_magazine *prev;
+};
-static void free_global_cached_iovas(struct iova_domain *iovad);
+struct iova_rcache {
+ spinlock_t lock;
+ unsigned long depot_size;
+ struct iova_magazine *depot[MAX_GLOBAL_MAGS];
+ struct iova_cpu_rcache __percpu *cpu_rcaches;
+};
static struct iova *to_iova(struct rb_node *node)
{
return rb_entry(node, struct iova, node);
}
-void
-init_iova_domain(struct iova_domain *iovad, unsigned long granule,
- unsigned long start_pfn)
-{
- /*
-* IOVA granularity will normally be equal to the smallest
-* supported IOMMU page size; both *must* be capable of
-* representing individual CPU pages exactly.
-*/
- BUG_ON((granule > PAGE_SIZE) || !is_power_of_2(granule));
-
- spin_lock_init(>iova_rbtree_lock);
- iovad->rbroot = RB_ROOT;
- iovad->cached_node = >anchor.node;
- iovad->cached32_node = >anchor.node;
- iovad->granule = granule;
- iovad->start_pfn = start_pfn;
- iovad->dma_32bit_pfn = 1UL << (32 - iova_shift(iovad));
- iovad->max32_alloc_size = iovad->dma_32bit_pfn;
- iovad->anchor.pfn_lo = iovad->anchor.pfn_hi = IOVA_ANCHOR;
- rb_link_node(>anchor.node, NULL, >rbroot.rb_node);
- rb_insert_color(>anchor.node, >rbroot);
-}
-EXPORT_SYMBOL_GPL(init_iova_domain);
-
-static struct rb_node *
-__get_cached_rbnode(struct iova_domain *iovad, unsigned long limit_pfn)
-{
- if (limit_pfn <= iovad->dma_32bit_pfn)
- return iovad->cached32_node;
-
- return iovad->cached_node;
-}
-
-static void
-__cached_rbnode_insert_update(struct iova_domain *iovad, struct iova *new)
-{
- if (new->pfn_hi < iovad->dma_32bit_pfn)
- iovad->cached32_node = >node;
- else
- iovad->cached_node = >node;
-}
-
static void
__cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
{
@@ -104,43 +69,6 @@ __cached_rbnode_delete_update(struct iova_domain *iovad,
struct iova *free)
iovad->cached_node = rb_next(>node);
}
-static struct rb_node *iova_find_limit(struct iova_domain *iovad, unsigned long limit_pfn)
-{
- struct rb_node *node, *next;
- /*
-* Ideally what we'd like to judge here is whether limit_pfn is close
-*
