[git pull] IOMMU Updates for Linux v5.13
Hi Linus,
The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef:
Linux 5.12-rc7 (2021-04-11 15:16:13 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-updates-v5.13
for you to fetch changes up to 2d471b20c55e13c98d1dba413bf2de618e89cdac:
iommu: Streamline registration interface (2021-04-16 17:20:45 +0200)
IOMMU Updates for Linux v5.13
Including:
- Big cleanup of almost unsused parts of the IOMMU API by
Christoph Hellwig. This mostly affects the Freescale PAMU
driver.
- New IOMMU driver for Unisoc SOCs
- ARM SMMU Updates from Will:
- SMMUv3: Drop vestigial PREFETCH_ADDR support
- SMMUv3: Elide TLB sync logic for empty gather
- SMMUv3: Fix "Service Failure Mode" handling
- SMMUv2: New Qualcomm compatible string
- Removal of the AMD IOMMU performance counter writeable check
on AMD. It caused long boot delays on some machines and is
only needed to work around an errata on some older (possibly
pre-production) chips. If someone is still hit by this
hardware issue anyway the performance counters will just
return 0.
- Support for targeted invalidations in the AMD IOMMU driver.
Before that the driver only invalidated a single 4k page or the
whole IO/TLB for an address space. This has been extended now
and is mostly useful for emulated AMD IOMMUs.
- Several fixes for the Shared Virtual Memory support in the
Intel VT-d driver
- Mediatek drivers can now be built as modules
- Re-introduction of the forcedac boot option which got lost
when converting the Intel VT-d driver to the common dma-iommu
implementation.
- Extension of the IOMMU device registration interface and
support iommu_ops to be const again when drivers are built as
modules.
Christoph Hellwig (23):
iommu: remove the unused domain_window_disable method
iommu/fsl_pamu: remove fsl_pamu_get_domain_attr
iommu/fsl_pamu: remove support for setting DOMAIN_ATTR_GEOMETRY
iommu/fsl_pamu: merge iommu_alloc_dma_domain into fsl_pamu_domain_alloc
iommu/fsl_pamu: remove support for multiple windows
iommu/fsl_pamu: remove ->domain_window_enable
iommu/fsl_pamu: replace DOMAIN_ATTR_FSL_PAMU_STASH with a direct call
iommu/fsl_pamu: merge pamu_set_liodn and map_liodn
iommu/fsl_pamu: merge handle_attach_device into fsl_pamu_attach_device
iommu/fsl_pamu: enable the liodn when attaching a device
iommu/fsl_pamu: remove the snoop_id field
iommu/fsl_pamu: remove the rpn and snoop_id arguments to pamu_config_ppaac
iommu/fsl_pamu: hardcode the window address and size in pamu_config_ppaace
iommu: remove DOMAIN_ATTR_PAGING
iommu: remove DOMAIN_ATTR_GEOMETRY
iommu: remove DOMAIN_ATTR_NESTING
iommu: remove iommu_set_cmd_line_dma_api and iommu_cmd_line_dma_api
iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFG
iommu: remove iommu_domain_{get,set}_attr
iommu/amd: Remove the unused device errata code
iommu/amd: Remove the unused amd_iommu_get_v2_domain function
iommu/amd: Remove a few unused exports
iommu/amd: Move a few prototypes to include/linux/amd-iommu.h
Christophe JAILLET (1):
iommu/vt-d: Fix an error handling path in 'intel_prepare_irq_remapping()'
Chunyan Zhang (3):
dt-bindings: iommu: add bindings for sprd IOMMU
iommu: add Unisoc IOMMU basic driver
iommu/sprd: Fix parameter type warning
Colin Ian King (1):
iommu/unisoc: Fix spelling mistake "sixe" -> "size"
Dafna Hirschfeld (1):
iommu/mediatek: Always enable the clk on resume
Jacob Pan (4):
iommu/vt-d: Enable write protect for supervisor SVM
iommu/vt-d: Enable write protect propagation from guest
iommu/vt-d: Reject unsupported page request modes
iommu/vt-d: Calculate and set flags for handle_mm_fault
Jean-Philippe Brucker (7):
iommu: Fix comment for struct iommu_fwspec
iommu/arm-smmu-v3: Use device properties for pasid-num-bits
iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA
iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF
uacce: Enable IOMMU_DEV_FEAT_IOPF
iommu: Add a page fault handler
iommu/arm-smmu-v3: Maintain a SID->device structure
Joerg Roedel (3):
Merge tag 'arm-smmu-updates' of
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/smmu
iommu/fsl-pamu: Fix uninitialized variable warning
Merge branches 'iommu/fixes', 'arm/mediatek', 'arm/smmu', 'arm/exynos',
'unisoc', 'x86/vt-d', 'x86/amd' and 'core' into next
John
[PATCH] iommu/amd: Add amd_iommu=force_enable option
From: Joerg Roedel
Add this option to enable the IOMMU on platforms like AMD Stoney,
where the kernel usually disables it because it may cause problems in
some scenarios.
Signed-off-by: Joerg Roedel
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
drivers/iommu/amd/init.c| 7 +++
2 files changed, 10 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..c9573f726707 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -303,6 +303,9 @@
allowed anymore to lift isolation
requirements as needed. This option
does not override iommu=pt
+ force_enable - Force enable the IOMMU on platforms known
+ to be buggy with IOMMU enabled. Use this
+ option with care.
amd_iommu_dump= [HW,X86-64]
Enable AMD IOMMU driver option to dump the ACPI table
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 321f5906e6ed..3e2295d3b3e2 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -155,6 +155,7 @@ static int amd_iommu_xt_mode = IRQ_REMAP_XAPIC_MODE;
static bool amd_iommu_detected;
static bool __initdata amd_iommu_disabled;
+static bool __initdata amd_iommu_force_enable;
static int amd_iommu_target_ivhd_type;
u16 amd_iommu_last_bdf;/* largest PCI device id we have
@@ -2882,6 +2883,9 @@ static bool detect_ivrs(void)
acpi_put_table(ivrs_base);
+ if (amd_iommu_force_enable)
+ goto out;
+
/* Don't use IOMMU if there is Stoney Ridge graphics */
for (i = 0; i < 32; i++) {
u32 pci_id;
@@ -2893,6 +2897,7 @@ static bool detect_ivrs(void)
}
}
+out:
/* Make sure ACS will be enabled during PCI probe */
pci_request_acs();
@@ -3148,6 +3153,8 @@ static int __init parse_amd_iommu_options(char *str)
for (; *str; ++str) {
if (strncmp(str, "fullflush", 9) == 0)
amd_iommu_unmap_flush = true;
+ if (strncmp(str, "force_enable", 12) == 0)
+ amd_iommu_force_enable = true;
if (strncmp(str, "off", 3) == 0)
amd_iommu_disabled = true;
if (strncmp(str, "force_isolation", 15) == 0)
--
2.31.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/8] iommu: fix a couple of spelling mistakes detected by codespell tool
On Fri, Mar 26, 2021 at 02:24:04PM +0800, Zhen Lei wrote: > This detection and correction covers the entire driver/iommu directory. > > Zhen Lei (8): > iommu/pamu: fix a couple of spelling mistakes > iommu/omap: Fix spelling mistake "alignement" -> "alignment" > iommu/mediatek: Fix spelling mistake "phyiscal" -> "physical" > iommu/sun50i: Fix spelling mistake "consits" -> "consists" > iommu: fix a couple of spelling mistakes > iommu/amd: fix a couple of spelling mistakes > iommu/arm-smmu: Fix spelling mistake "initally" -> "initially" > iommu/vt-d: fix a couple of spelling mistakes This patch-set doesn't apply. Please re-send it as a single patch when v5.13-rc1 is released. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] iommu: Statically set module owner
On Thu, Apr 01, 2021 at 02:56:25PM +0100, Robin Murphy wrote: > It happens that the 3 drivers which first supported being modular are > also ones which play games with their pgsize_bitmap, so have non-const > iommu_ops where dynamically setting the owner manages to work out OK. > However, it's less than ideal to force that upon all drivers which want > to be modular - like the new sprd-iommu driver which now has a potential > bug in that regard - so let's just statically set the module owner and > let ops remain const wherever possible. > > Reviewed-by: Christoph Hellwig > Acked-by: Will Deacon > Signed-off-by: Robin Murphy > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 + > drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 + > drivers/iommu/sprd-iommu.c | 1 + > drivers/iommu/virtio-iommu.c| 1 + > include/linux/iommu.h | 9 + > 5 files changed, 5 insertions(+), 8 deletions(-) Applied these two directly on-top of my next branch. This essentially means that all topic branches are frozen now until after the merge window. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/fsl-pamu: Fix uninitialized variable warning
From: Joerg Roedel
The variable 'i' in the function update_liodn_stash() is not
initialized and only used in a debug printk(). So it has no
meaning at all, remove it.
Reported-by: kernel test robot
Signed-off-by: Joerg Roedel
---
drivers/iommu/fsl_pamu_domain.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 32944d67baa4..0ac781186dbd 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -57,14 +57,13 @@ static int __init iommu_init_mempool(void)
static int update_liodn_stash(int liodn, struct fsl_dma_domain *dma_domain,
u32 val)
{
- int ret = 0, i;
+ int ret = 0;
unsigned long flags;
spin_lock_irqsave(_lock, flags);
ret = pamu_update_paace_stash(liodn, val);
if (ret) {
- pr_debug("Failed to update SPAACE %d field for liodn %d\n ",
-i, liodn);
+ pr_debug("Failed to update SPAACE for liodn %d\n ", liodn);
spin_unlock_irqrestore(_lock, flags);
return ret;
}
--
2.30.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/vt-d: Force to flush iotlb before creating superpage
On Thu, Apr 15, 2021 at 08:46:28AM +0800, Longpeng(Mike) wrote:
> Fixes: 6491d4d02893 ("intel-iommu: Free old page tables before creating
> superpage")
> Cc: # v3.0+
> Link:
> https://lore.kernel.org/linux-iommu/670baaf8-4ff8-4e84-4be3-030b95ab5...@huawei.com/
> Suggested-by: Lu Baolu
> Signed-off-by: Longpeng(Mike)
> ---
> v1 -> v2:
> - add Joerg
> - reconstruct the solution base on the Baolu's suggestion
> ---
> drivers/iommu/intel/iommu.c | 52
> +
> 1 file changed, 38 insertions(+), 14 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] iommu/mediatek-v1: Avoid build fail when build as module
On Mon, Apr 12, 2021 at 02:48:42PM +0800, Yong Wu wrote:
> When this driver build as module, It build fail like:
>
> ERROR: modpost: "of_phandle_iterator_args"
> [drivers/iommu/mtk_iommu_v1.ko] undefined!
>
> This patch remove this interface to avoid this build fail.
>
> Reported-by: Valdis Kletnieks
> Signed-off-by: Yong Wu
> ---
> Currently below patch is only in linux-next-20210409. This fixes tag may be
> not needed. we can add this if it is need.
> Fixes: 8de000cf0265 ("iommu/mediatek-v1: Allow building as module")
> ---
> drivers/iommu/mtk_iommu_v1.c | 62
> 1 file changed, 28 insertions(+), 34 deletions(-)
Applied both, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Fix an error handling path in 'intel_prepare_irq_remapping()'
On Sun, Apr 11, 2021 at 09:08:17AM +0200, Christophe JAILLET wrote: > drivers/iommu/intel/irq_remapping.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86
On Sun, Apr 11, 2021 at 02:23:12PM +0800, Lu Baolu wrote: > drivers/iommu/intel/pasid.c | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/2] iommu/amd: Revert and remove failing PMC test
On Fri, Apr 09, 2021 at 03:58:46AM -0500, Suravee Suthikulpanit wrote: > Paul Menzel (1): > Revert "iommu/amd: Fix performance counter initialization" > > Suravee Suthikulpanit (1): > iommu/amd: Remove performance counter pre-initialization test Applied, thanks Paul and Suravee. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RESEND] iommu/amd: Remove duplicate check of devid
On Fri, Apr 09, 2021 at 11:30:40AM +0800, Shaokun Zhang wrote: > drivers/iommu/amd/iommu.c | 9 + > 1 file changed, 1 insertion(+), 8 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: exynos: remove unneeded local variable initialization
On Thu, Apr 08, 2021 at 10:16:22PM +0200, Krzysztof Kozlowski wrote: > drivers/iommu/exynos-iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: page-specific invalidations for more than one page
On Tue, Mar 23, 2021 at 02:06:19PM -0700, Nadav Amit wrote: > drivers/iommu/amd/iommu.c | 76 +-- > 1 file changed, 42 insertions(+), 34 deletions(-) Load-testing looks good here too, so this patch is queued now for v5.13, thanks Nadav. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] iommu/arm-smmu: Updates for 5.13
On Thu, Apr 08, 2021 at 02:29:59PM +0100, Will Deacon wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git > tags/arm-smmu-updates Pulled, thanks Will. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: page-specific invalidations for more than one page
On Thu, Apr 08, 2021 at 10:29:25AM +, Nadav Amit wrote: > In the version that you referred me to, iommu_update_domain_tlb() only > regards the size of the region to be flushed and disregards the > alignment: > > + order = get_order(domain->flush.end - domain->flush.start); > + mask= (0x1000ULL << order) - 1; > + address = ((domain->flush.start & ~mask) | (mask >> 1)) & ~0xfffULL; > > > If you need to flush for instance the region between 0x1000-0x5000, this > version would use the address|mask of 0x1000 (16KB page). The version I > sent regards the alignment, and since the range is not aligned would use > address|mask of 0x3000 (32KB page). > > IIUC, IOVA allocations today are aligned in such way, but at least in > the past (looking on 3.19 for the matter), it was not like always like > that, which can explain the problems. Yeah, that make sense and explains the data corruption problems. I will give your patch a try on one of my test machines and consider it for v5.13 if all goes well. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: page-specific invalidations for more than one page
Hi Nadav, On Wed, Apr 07, 2021 at 05:57:31PM +, Nadav Amit wrote: > I tested it on real bare-metal hardware. I ran some basic I/O workloads > with the IOMMU enabled, checkers enabled/disabled, and so on. > > However, I only tested the IOMMU-flushes and I did not test that the > device-IOTLB flush work, since I did not have the hardware for that. > > If you can refer me to the old patches, I will have a look and see > whether I can see a difference in the logic or test them. If you want > me to run different tests - let me know. If you want me to remove > the device-IOTLB invalidations logic - that is also fine with me. Here is the patch-set, it is from 2010 and against a very old version of the AMD IOMMU driver: https://lore.kernel.org/lkml/1265898797-32183-1-git-send-email-joerg.roe...@amd.com/ Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] Revert "iommu/amd: Fix performance counter initialization"
Hi Paul, On Thu, Mar 18, 2021 at 10:20:16AM +0100, Paul Menzel wrote: > Jörg, I know you are probably busy, but the patch was applied to the stable > series (v5.11.7). There are still too many question open regarding the > patch, and Suravee has not yet addressed the comments. It’d be great, if you > could revert it. We are currently discussing the next steps here. Maybe the retry logic can be removed entirely. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: page-specific invalidations for more than one page
On Tue, Mar 23, 2021 at 02:06:19PM -0700, Nadav Amit wrote: > From: Nadav Amit > > Currently, IOMMU invalidations and device-IOTLB invalidations using > AMD IOMMU fall back to full address-space invalidation if more than a > single page need to be flushed. > > Full flushes are especially inefficient when the IOMMU is virtualized by > a hypervisor, since it requires the hypervisor to synchronize the entire > address-space. > > AMD IOMMUs allow to provide a mask to perform page-specific > invalidations for multiple pages that match the address. The mask is > encoded as part of the address, and the first zero bit in the address > (in bits [51:12]) indicates the mask size. > > Use this hardware feature to perform selective IOMMU and IOTLB flushes. > Combine the logic between both for better code reuse. > > The IOMMU invalidations passed a smoke-test. The device IOTLB > invalidations are untested. Have you thoroughly tested this on real hardware? I had a patch-set doing the same many years ago and it lead to data corruption under load. Back then it could have been a bug in my code of course, but it made me cautious about using targeted invalidations. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD IOMMU cleanups and dead code removal
On Fri, Apr 02, 2021 at 04:33:08PM +0200, Christoph Hellwig wrote: > Hi, > > this series cleans up a few random bits in the AMD IOMMU driver. > > Diffstat: > arch/x86/events/amd/iommu.c|1 > arch/x86/events/amd/iommu.h| 19 -- > drivers/gpu/drm/amd/amdkfd/kfd_iommu.c |4 - > drivers/iommu/amd/amd_iommu.h |2 > drivers/iommu/amd/amd_iommu_types.h|1 > drivers/iommu/amd/init.c |5 - > drivers/iommu/amd/iommu.c | 90 > + > include/linux/amd-iommu.h | 30 --- > 8 files changed, 16 insertions(+), 136 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver v3
On Thu, Apr 01, 2021 at 05:52:36PM +0200, Christoph Hellwig wrote: > Diffstat: > arch/powerpc/include/asm/fsl_pamu_stash.h | 12 > drivers/gpu/drm/msm/adreno/adreno_gpu.c |5 > drivers/iommu/amd/iommu.c | 23 > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 75 --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |1 > drivers/iommu/arm/arm-smmu/arm-smmu.c | 111 +--- > drivers/iommu/arm/arm-smmu/arm-smmu.h |2 > drivers/iommu/dma-iommu.c |9 > drivers/iommu/fsl_pamu.c| 293 --- > drivers/iommu/fsl_pamu.h| 12 > drivers/iommu/fsl_pamu_domain.c | 688 > ++-- > drivers/iommu/fsl_pamu_domain.h | 46 - > drivers/iommu/intel/iommu.c | 95 --- > drivers/iommu/iommu.c | 118 +--- > drivers/soc/fsl/qbman/qman_portal.c | 55 -- > drivers/vfio/vfio_iommu_type1.c | 31 - > drivers/vhost/vdpa.c| 10 > include/linux/io-pgtable.h |4 > include/linux/iommu.h | 76 --- > 19 files changed, 203 insertions(+), 1463 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
On Thu, Apr 01, 2021 at 05:47:09PM +0200, Jean-Philippe Brucker wrote: > Jean-Philippe Brucker (10): > iommu: Fix comment for struct iommu_fwspec > iommu/arm-smmu-v3: Use device properties for pasid-num-bits > iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA > iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF > uacce: Enable IOMMU_DEV_FEAT_IOPF > iommu: Add a page fault handler > iommu/arm-smmu-v3: Maintain a SID->device structure Applied the first 7 patches, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: sprd: Fix parameter type warning
On Wed, Mar 31, 2021 at 11:16:45AM +0800, Chunyan Zhang wrote: > drivers/iommu/sprd-iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Report right snoop capability when using FL for IOVA
On Tue, Mar 30, 2021 at 10:11:45AM +0800, Lu Baolu wrote: > drivers/iommu/intel/pasid.h | 1 + > drivers/iommu/intel/iommu.c | 11 ++- > drivers/iommu/intel/pasid.c | 16 > 3 files changed, 27 insertions(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/2] iommu/mediatek-v1: Allow building as module
On Fri, Mar 26, 2021 at 11:23:36AM +0800, Yong Wu wrote: > This patch only adds support for building the IOMMU-v1 driver as module. > Correspondingly switch the config to tristate and update the iommu_ops's > owner to THIS_MODULE. > > Signed-off-by: Yong Wu Applied both, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/4] iommu/iova: Add CPU hotplug handler to flush rcaches to core code
On Thu, Mar 25, 2021 at 08:29:57PM +0800, John Garry wrote: > John Garry (4): > iova: Add CPU hotplug handler to flush rcaches > iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining > iommu: Delete iommu_dma_free_cpu_cached_iovas() > iommu: Stop exporting free_iova_fast() > > drivers/iommu/dma-iommu.c | 9 - > drivers/iommu/intel/iommu.c | 31 --- > drivers/iommu/iova.c| 34 +++--- > include/linux/cpuhotplug.h | 2 +- > include/linux/dma-iommu.h | 8 > include/linux/iova.h| 6 +- > 6 files changed, 33 insertions(+), 57 deletions(-) Okay, newer version. Applied this one instead, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: Fix a boundary issue to avoid performance drop
On Thu, Mar 25, 2021 at 09:43:45AM +, Will Deacon wrote: > Urgh, I must say I much preferred these things being exclusive, but this > looks like a necessary fix: > > Acked-by: Will Deacon Applied for v5.12. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/5] iommu/vt-d: Several misc cleanups
On Tue, Mar 23, 2021 at 09:05:55AM +0800, Lu Baolu wrote: > Lu Baolu (5): > iommu/vt-d: Remove unused dma map/unmap trace events > iommu/vt-d: Remove svm_dev_ops > iommu/vt-d: Remove SVM_FLAG_PRIVATE_PASID > iommu/vt-d: Remove unused function declarations > iommu/vt-d: Make unnecessarily global functions static Applied all, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/1] iommu/vt-d: Don't set then clear private data in prq_event_thread()
On Sat, Mar 20, 2021 at 10:41:56AM +0800, Lu Baolu wrote: > drivers/iommu/intel/svm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/1] iommu/vt-d: Fix lockdep splat in intel_pasid_get_entry()
On Sat, Mar 20, 2021 at 10:09:16AM +0800, Lu Baolu wrote: > drivers/iommu/intel/pasid.c | 21 + > 1 file changed, 13 insertions(+), 8 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/3] iommu/iova: Add CPU hotplug handler to flush rcaches to core code
On Mon, Mar 01, 2021 at 08:12:18PM +0800, John Garry wrote: > The Intel IOMMU driver supports flushing the per-CPU rcaches when a CPU is > offlined. > > Let's move it to core code, so everyone can take advantage. > > Also correct a code comment. > > Based on v5.12-rc1. Tested on arm64 only. > > John Garry (3): > iova: Add CPU hotplug handler to flush rcaches > iommu/vt-d: Remove IOVA domain rcache flushing for CPU offlining > iova: Correct comment for free_cpu_cached_iovas() > > drivers/iommu/intel/iommu.c | 31 --- > drivers/iommu/iova.c| 32 ++-- > include/linux/cpuhotplug.h | 2 +- > include/linux/iova.h| 1 + > 4 files changed, 32 insertions(+), 34 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: Add device name to iommu map/unmap trace events
On Tue, Apr 06, 2021 at 02:56:53PM +0800, chenxiang (M) wrote: > Is it possible to use group id to identify different domains? No, the best is to do this during post-processing of your traces by also keeping tack of domain-device attachments/detachments. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH][next] iommu: Fix spelling mistake "sixe" -> "size"
On Fri, Mar 19, 2021 at 09:57:50AM +, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/iommu/sprd-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
>
> diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
> index 7100ed17dcce..e1dc2f7d5639 100644
> --- a/drivers/iommu/sprd-iommu.c
> +++ b/drivers/iommu/sprd-iommu.c
> @@ -297,7 +297,7 @@ static int sprd_iommu_map(struct iommu_domain *domain,
> unsigned long iova,
> }
>
> if (iova < start || (iova + size) > (end + 1)) {
> - dev_err(dom->sdev->dev, "(iova(0x%lx) + sixe(%zx)) are not in
> the range!\n",
> + dev_err(dom->sdev->dev, "(iova(0x%lx) + size(%zx)) are not in
> the range!\n",
> iova, size);
> return -EINVAL;
> }
> --
> 2.30.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux v5.12-rc3
Hi Linus, The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0: Linux 5.12-rc3 (2021-03-14 14:41:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.12-rc3 for you to fetch changes up to 8dfd0fa6ecdc5e2099a57d485b7ce237abc6c7a0: iommu/tegra-smmu: Make tegra_smmu_probe_device() to handle all IOMMU phandles (2021-03-18 11:31:12 +0100) IOMMU Fixes for Linux v5.12-rc3 Including: - Three AMD IOMMU patches to fix a boot crash on AMD Stoney systems and every other AMD IOMMU system booted with 'amd_iommu=off'. This is a v5.11 regression. - A Fix for the Tegra IOMMU driver to make sure it detects all IOMMUs Dmitry Osipenko (1): iommu/tegra-smmu: Make tegra_smmu_probe_device() to handle all IOMMU phandles Joerg Roedel (3): iommu/amd: Move Stoney Ridge check to detect_ivrs() iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled iommu/amd: Keep track of amd_iommu_irq_remap state drivers/iommu/amd/init.c | 36 drivers/iommu/tegra-smmu.c | 7 +++ 2 files changed, 23 insertions(+), 20 deletions(-) Please pull. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Fix lockdep splat in intel_pasid_get_entry()
Hi Baolu, On Fri, Mar 19, 2021 at 09:02:34AM +0800, Lu Baolu wrote: > This code modifies the pasid directory entry. The pasid directory > entries are allocated on demand and will never be freed. > > > What you need to do here is to retry the whole path by adding a goto > > to before the first get_pasid_table_from_pde() call. > > Yes. Retrying by adding a goto makes the code clearer. > > > > > Btw, what makes sure that the pasid_entry does not go away when it is > > returned here? > > As explained above, it handles the pasid directory table entry which > won't go away. Okay, I think the goto is a good idea anyway, in case this changes someday. Please also add a comment to this code stating that the entries are never freed. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 7/7] iommu/amd: Add support for using AMD IOMMU v2 page table for DMA-API
On Fri, Mar 12, 2021 at 03:04:11AM -0600, Suravee Suthikulpanit wrote:
> Introduce init function for setting up DMA domain for DMA-API with
> the IOMMU v2 page table.
>
> Signed-off-by: Suravee Suthikulpanit
> ---
> drivers/iommu/amd/iommu.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index e29ece6e1e68..bd26de8764bd 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -1937,6 +1937,24 @@ static int protection_domain_init_v1(struct
> protection_domain *domain, int mode)
> return 0;
> }
>
> +static int protection_domain_init_v2(struct protection_domain *domain)
> +{
> + spin_lock_init(>lock);
> + domain->id = domain_id_alloc();
> + if (!domain->id)
> + return -ENOMEM;
> + INIT_LIST_HEAD(>dev_list);
> +
> + domain->giov = true;
> +
> + if (amd_iommu_pgtable == AMD_IOMMU_V2 &&
> + domain_enable_v2(domain, 1, false)) {
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
You also need to advertise a different aperture size and a different
pgsize-bitmap. The host page-table can only map a 48 bit address space,
not a 64 bit one like with v1 page-tables.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 6/7] iommu/amd: Introduce amd_iommu_pgtable command-line option
On Fri, Mar 12, 2021 at 03:04:10AM -0600, Suravee Suthikulpanit wrote: > To allow specification whether to use v1 or v2 IOMMU pagetable for > DMA remapping when calling kernel DMA-API. > > Signed-off-by: Suravee Suthikulpanit > --- > Documentation/admin-guide/kernel-parameters.txt | 6 ++ > drivers/iommu/amd/init.c| 15 +++ > 2 files changed, 21 insertions(+) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 04545725f187..466e807369ea 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -319,6 +319,12 @@ >This mode requires kvm-amd.avic=1. >(Default when IOMMU HW support is present.) > > + amd_iommu_pgtable= [HW,X86-64] > + Specifies one of the following AMD IOMMU page table to > + be used for DMA remapping for DMA-API: > + v1 - Use v1 page table (Default) > + v2 - Use v2 page table Any reason v2 can not be the default when it is supported by the IOMMU? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 5/7] iommu/amd: Add support for Guest IO protection
On Fri, Mar 12, 2021 at 03:04:09AM -0600, Suravee Suthikulpanit wrote:
> @@ -519,6 +521,7 @@ struct protection_domain {
> spinlock_t lock;/* mostly used to lock the page table*/
> u16 id; /* the domain id written to the device table */
> int glx;/* Number of levels for GCR3 table */
> + bool giov; /* guest IO protection domain */
Could this be turned into a flag?
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 4/7] iommu/amd: Initial support for AMD IOMMU v2 page table
Hi Suravee,
On Fri, Mar 12, 2021 at 03:04:08AM -0600, Suravee Suthikulpanit wrote:
> @@ -503,6 +504,7 @@ struct amd_io_pgtable {
> int mode;
> u64 *root;
> atomic64_t pt_root;/* pgtable root and pgtable mode */
> + struct mm_structv2_mm;
> };
A whole mm_struct is a bit too much when all we really need is an 8-byte
page-table root pointer.
> +static pte_t *fetch_pte(struct amd_io_pgtable *pgtable,
> + unsigned long iova,
> + unsigned long *page_size)
> +{
> + int level;
> + pte_t *ptep;
> +
> + ptep = lookup_address_in_mm(>v2_mm, iova, );
> + if (!ptep || pte_none(*ptep) || (level == PG_LEVEL_NONE))
> + return NULL;
So you are re-using the in-kernel page-table building code. That safes
some lines of code, but has several problems:
1) When you boot a kernel with this code on a machine with
5-level paging, the IOMMU code will build a 5-level
page-table too, breaking IOMMU mappings.
2) You need a whole mm_struct per domain, which is big.
3) The existing macros for CPU page-tables require locking. For
IOMMU page-tables this is not really necessary and might
cause scalability issues.
Overall I think you should write your own code to build a 4-level
page-table and use cmpxchg64 to avoid the need for locking. Then things
will not break when such a kernel is suddenly booted on a machine which
as 5-level paging enabled.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] iommu/virtio: Enable x86 support
On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote: > With the VIOT support in place, x86 platforms can now use the > virtio-iommu. > > The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it > themselves. > > Signed-off-by: Jean-Philippe Brucker > --- > drivers/iommu/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index 2819b5c8ec30..ccca83ef2f06 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -400,8 +400,9 @@ config HYPERV_IOMMU > config VIRTIO_IOMMU > tristate "Virtio IOMMU driver" > depends on VIRTIO > - depends on ARM64 > + depends on (ARM64 || X86) > select IOMMU_API > + select IOMMU_DMA if X86 > select INTERVAL_TREE > select ACPI_VIOT if ACPI > help Acked-by: Joerg Roedel ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/4] Misc vSVA fixes for VT-d
On Tue, Mar 02, 2021 at 02:13:56AM -0800, Jacob Pan wrote: > Hi Baolu et al, > > This is a collection of SVA-related fixes. > > ChangeLog: > > v2: > - For guest SVA, call pasid_set_wpe directly w/o checking host CR0.wp > (Review comments by Kevin T.) > - Added fixes tag > > Thanks, > > Jacob > > Jacob Pan (4): > iommu/vt-d: Enable write protect for supervisor SVM > iommu/vt-d: Enable write protect propagation from guest > iommu/vt-d: Reject unsupported page request modes > iommu/vt-d: Calculate and set flags for handle_mm_fault > > drivers/iommu/intel/pasid.c | 29 + > drivers/iommu/intel/svm.c | 21 + > include/uapi/linux/iommu.h | 3 ++- > 3 files changed, 48 insertions(+), 5 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1] iommu/tegra-smmu: Make tegra_smmu_probe_device() to handle all IOMMU phandles
On Fri, Mar 12, 2021 at 06:54:39PM +0300, Dmitry Osipenko wrote:
> The tegra_smmu_probe_device() handles only the first IOMMU device-tree
> phandle, skipping the rest. Devices like 3D module on Tegra30 have
> multiple IOMMU phandles, one for each h/w block, and thus, only one
> IOMMU phandle is added to fwspec for the 3D module, breaking GPU.
> Previously this problem was masked by tegra_smmu_attach_dev() which
> didn't use the fwspec, but parsed the DT by itself. The previous commit
> to tegra-smmu driver partially reverted changes that caused problems for
> T124 and now we have tegra_smmu_attach_dev() that uses the fwspec and
> the old-buggy variant of tegra_smmu_probe_device() which skips secondary
> IOMMUs.
>
> Make tegra_smmu_probe_device() not to skip the secondary IOMMUs. This
> fixes a partially attached IOMMU of the 3D module on Tegra30 and now GPU
> works properly once again.
>
> Fixes: 765a9d1d02b2 ("iommu/tegra-smmu: Fix mc errors on tegra124-nyan")
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/iommu/tegra-smmu.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Applied for v5.12, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Report more information about invalidation errors
On Thu, Mar 18, 2021 at 08:53:40AM +0800, Lu Baolu wrote: > When the invalidation queue errors are encountered, dump the information > logged by the VT-d hardware together with the pending queue invalidation > descriptors. > > Signed-off-by: Ashok Raj > Tested-by: Guo Kaijie > Signed-off-by: Lu Baolu > --- > drivers/iommu/intel/dmar.c | 68 ++--- > include/linux/intel-iommu.h | 6 > 2 files changed, 70 insertions(+), 4 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Disable SVM when ATS/PRI/PASID are not enabled in the device
On Sun, Mar 14, 2021 at 01:15:34PM -0700, Kyung Min Park wrote: > Currently, the Intel VT-d supports Shared Virtual Memory (SVM) only when > IO page fault is supported. Otherwise, shared memory pages can not be > swapped out and need to be pinned. The device needs the Address Translation > Service (ATS), Page Request Interface (PRI) and Process Address Space > Identifier (PASID) capabilities to be enabled to support IO page fault. > > Disable SVM when ATS, PRI and PASID are not enabled in the device. > > Signed-off-by: Kyung Min Park Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Fix lockdep splat in intel_pasid_get_entry()
On Wed, Mar 17, 2021 at 08:58:34AM +0800, Lu Baolu wrote:
> The pasid_lock is used to synchronize different threads from modifying a
> same pasid directory entry at the same time. It causes below lockdep splat.
>
> [ 83.296538]
> [ 83.296538] WARNING: possible irq lock inversion dependency detected
> [ 83.296539] 5.12.0-rc3+ #25 Tainted: GW
> [ 83.296539]
> [ 83.296540] bash/780 just changed the state of lock:
> [ 83.296540] 82b29c98 (device_domain_lock){..-.}-{2:2}, at:
>iommu_flush_dev_iotlb.part.0+0x32/0x110
> [ 83.296547] but this lock took another, SOFTIRQ-unsafe lock in the past:
> [ 83.296547] (pasid_lock){+.+.}-{2:2}
> [ 83.296548]
>
>and interrupts could create inverse lock ordering between them.
>
> [ 83.296549] other info that might help us debug this:
> [ 83.296549] Chain exists of:
> device_domain_lock --> >lock --> pasid_lock
> [ 83.296551] Possible interrupt unsafe locking scenario:
>
> [ 83.296551]CPU0CPU1
> [ 83.296552]
> [ 83.296552] lock(pasid_lock);
> [ 83.296553]local_irq_disable();
> [ 83.296553]lock(device_domain_lock);
> [ 83.296554]lock(>lock);
> [ 83.296554]
> [ 83.296554] lock(device_domain_lock);
> [ 83.296555]
> *** DEADLOCK ***
>
> Fix it by replacing the pasid_lock with an atomic exchange operation.
>
> Reported-and-tested-by: Dave Jiang
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/pasid.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
> index 9fb3d3e80408..1ddcb8295f72 100644
> --- a/drivers/iommu/intel/pasid.c
> +++ b/drivers/iommu/intel/pasid.c
> @@ -24,7 +24,6 @@
> /*
> * Intel IOMMU system wide PASID name space:
> */
> -static DEFINE_SPINLOCK(pasid_lock);
> u32 intel_pasid_max_id = PASID_MAX;
>
> int vcmd_alloc_pasid(struct intel_iommu *iommu, u32 *pasid)
> @@ -259,19 +258,18 @@ struct pasid_entry *intel_pasid_get_entry(struct device
> *dev, u32 pasid)
> dir_index = pasid >> PASID_PDE_SHIFT;
> index = pasid & PASID_PTE_MASK;
>
> - spin_lock(_lock);
> entries = get_pasid_table_from_pde([dir_index]);
> if (!entries) {
> entries = alloc_pgtable_page(info->iommu->node);
> - if (!entries) {
> - spin_unlock(_lock);
> + if (!entries)
> return NULL;
> - }
>
> - WRITE_ONCE(dir[dir_index].val,
> -(u64)virt_to_phys(entries) | PASID_PTE_PRESENT);
> + if (cmpxchg64([dir_index].val, 0ULL,
> + (u64)virt_to_phys(entries) | PASID_PTE_PRESENT)) {
> + free_pgtable_page(entries);
> + entries = get_pasid_table_from_pde([dir_index]);
This is racy, someone could have already cleared the pasid-entry again.
What you need to do here is to retry the whole path by adding a goto
to before the first get_pasid_table_from_pde() call.
Btw, what makes sure that the pasid_entry does not go away when it is
returned here?
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Don't set then immediately clear in prq_event_thread()
Hi Baolu,
On Tue, Mar 09, 2021 at 08:46:41AM +0800, Lu Baolu wrote:
> The private data field of a page group response descriptor is set then
> immediately cleared in prq_event_thread(). Fix this by moving clearing
> code up.
>
> Fixes: 5b438f4ba315d ("iommu/vt-d: Support page request in scalable mode")
> Cc: Jacob Pan
> Reviewed-by: Liu Yi L
> Signed-off-by: Lu Baolu
Does this fix an actual bug? If so, please state it in the commit
message and also fix the subject line to state what is set/cleared.
Thanks,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] iommu/iova: Add rbtree entry helper
On Fri, Mar 05, 2021 at 04:35:22PM +, Robin Murphy wrote: > Repeating the rb_entry() boilerplate all over the place gets old fast. > Before adding yet more instances, add a little hepler to tidy it up. > > Signed-off-by: Robin Murphy > --- > drivers/iommu/iova.c | 23 ++- > 1 file changed, 14 insertions(+), 9 deletions(-) Applied both, thanks Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: Resurrect the "forcedac" option
On Fri, Mar 05, 2021 at 04:32:34PM +, Robin Murphy wrote:
> In converting intel-iommu over to the common IOMMU DMA ops, it quietly
> lost the functionality of its "forcedac" option. Since this is a handy
> thing both for testing and for performance optimisation on certain
> platforms, reimplement it under the common IOMMU parameter namespace.
>
> For the sake of fixing the inadvertent breakage of the Intel-specific
> parameter, remove the dmar_forcedac remnants and hook it up as an alias
> while documenting the transition to the new common parameter.
>
> Fixes: c588072bba6b ("iommu/vt-d: Convert intel iommu driver to the iommu
> ops")
> Signed-off-by: Robin Murphy
> ---
> Documentation/admin-guide/kernel-parameters.txt | 15 ---
> drivers/iommu/dma-iommu.c | 13 -
> drivers/iommu/intel/iommu.c | 5 ++---
> include/linux/dma-iommu.h | 2 ++
> 4 files changed, 24 insertions(+), 11 deletions(-)
Applied for v5.13, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 0/2] Add Unisoc IOMMU basic driver
On Fri, Mar 05, 2021 at 05:32:14PM +0800, Chunyan Zhang wrote: > .../devicetree/bindings/iommu/sprd,iommu.yaml | 57 ++ > drivers/iommu/Kconfig | 12 + > drivers/iommu/Makefile| 1 + > drivers/iommu/sprd-iommu.c| 577 ++ > 4 files changed, 647 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iommu/sprd,iommu.yaml > create mode 100644 drivers/iommu/sprd-iommu.c Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu: Check dev->iommu in iommu_dev_xxx functions
On Wed, Mar 03, 2021 at 05:36:11PM +, Shameer Kolothum wrote:
> The device iommu probe/attach might have failed leaving dev->iommu
> to NULL and device drivers may still invoke these functions resulting
> in a crash in iommu vendor driver code.
>
> Hence make sure we check that.
>
> Fixes: a3a195929d40 ("iommu: Add APIs for multiple domains per device")
> Signed-off-by: Shameer Kolothum
> ---
> v2 --> v3
> -Removed iommu_ops from struct dev_iommu.
> v1 --> v2:
> -Added iommu_ops to struct dev_iommu based on the discussion with Robin.
> -Rebased against iommu-tree core branch.
> ---
> drivers/iommu/iommu.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/3] iommu/amd: Fix booting with amd_iommu=off
On Wed, Mar 17, 2021 at 06:48:50PM +0800, Huang Rui wrote: > Series are Acked-by: Huang Rui Thanks, series is applied for v5.12 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/5] iommu/vt-d: Remove WO permissions on second-level paging entries
Hi, On Mon, Mar 08, 2021 at 11:47:46AM -0800, Raj, Ashok wrote: > That is the primary motivation, given that we have moved to 1st level for > general IOVA, first level doesn't have a WO mapping. I didn't know enough > about the history to determine if a WO without a READ is very useful. I > guess the ZLR was invented to support those cases without a READ in PCIe. I Okay, please update the commit message and re-send. I guess these patches are 5.13 stuff. In that case, Baolu can include them into his pull request later this cycle. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled
On Wed, Mar 17, 2021 at 01:37:16PM +, David Woodhouse wrote: > If we can get to the point where we don't even need to check > amd_iommu_irq_remap in the ...select() function because the IRQ domain > is never even registered in the case where the flag ends up false, all > the better :) This should already be achieved with this patch :) But the check is still needed if something goes wrong during IOMMU initialization. In this case the IOMMUs are teared down and the memory is freed. But the IRQ domains stay registered for now, mostly because the upper-level APIs to register them lack a deregister function. I havn't looked into the details yet whether it is suffient to call irq_domain_remove() on a domain created with arch_create_remap_msi_irq_domain() for example. This needs more research on my side :) Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled
On Wed, Mar 17, 2021 at 11:47:11AM +, David Woodhouse wrote: > If you've already moved the Stoney Ridge check out of the way, there's > no real reason why you can't just set init_state=IOMMU_CMDLINE_DISABLED > directly from parse_amd_iommu_options(), is there? Then you don't need > the condition here at all? True, there is even more room for optimization. The amd_iommu_disabled variable can go away entirely, including its checks in early_amd_iommu_init(). I will do a patch-set on-top of this for v5.13 which does more cleanups. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 3/3] iommu/amd: Keep track of amd_iommu_irq_remap state
From: Joerg Roedel
The amd_iommu_irq_remap variable is set to true in amd_iommu_prepare().
But if initialization fails it is not set to false. Fix that and
correctly keep track of whether irq remapping is enabled or not.
References: https://bugzilla.kernel.org/show_bug.cgi?id=212133
References: https://bugzilla.suse.com/show_bug.cgi?id=1183132
Fixes: b34f10c2dc59 ("iommu/amd: Stop irq_remapping_select() matching when
remapping is disabled")
Cc: sta...@vger.kernel.org # v5.11
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/init.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 61dae1800b7f..321f5906e6ed 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -3002,8 +3002,11 @@ int __init amd_iommu_prepare(void)
amd_iommu_irq_remap = true;
ret = iommu_go_to_state(IOMMU_ACPI_FINISHED);
- if (ret)
+ if (ret) {
+ amd_iommu_irq_remap = false;
return ret;
+ }
+
return amd_iommu_irq_remap ? 0 : -ENODEV;
}
--
2.30.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/3] iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled
From: Joerg Roedel
Don't even try to initialize the AMD IOMMU hardware when amd_iommu=off has been
passed on the kernel command line.
References: https://bugzilla.kernel.org/show_bug.cgi?id=212133
References: https://bugzilla.suse.com/show_bug.cgi?id=1183132
Cc: sta...@vger.kernel.org # v5.11
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/init.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 3280e6f5b720..61dae1800b7f 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -2919,12 +2919,12 @@ static int __init state_next(void)
}
break;
case IOMMU_IVRS_DETECTED:
- ret = early_amd_iommu_init();
- init_state = ret ? IOMMU_INIT_ERROR : IOMMU_ACPI_FINISHED;
- if (init_state == IOMMU_ACPI_FINISHED && amd_iommu_disabled) {
- pr_info("AMD IOMMU disabled\n");
+ if (amd_iommu_disabled) {
init_state = IOMMU_CMDLINE_DISABLED;
ret = -EINVAL;
+ } else {
+ ret = early_amd_iommu_init();
+ init_state = ret ? IOMMU_INIT_ERROR :
IOMMU_ACPI_FINISHED;
}
break;
case IOMMU_ACPI_FINISHED:
--
2.30.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/3] iommu/amd: Move Stoney Ridge check to detect_ivrs()
From: Joerg Roedel
The AMD IOMMU will not be enabled on AMD Stoney Ridge systems. Bail
out even earlier and refuse to even detect the IOMMU there.
References: https://bugzilla.kernel.org/show_bug.cgi?id=212133
References: https://bugzilla.suse.com/show_bug.cgi?id=1183132
Cc: sta...@vger.kernel.org # v5.11
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/init.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 9126efcbaf2c..3280e6f5b720 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -2714,7 +2714,6 @@ static int __init early_amd_iommu_init(void)
struct acpi_table_header *ivrs_base;
int i, remap_cache_sz, ret;
acpi_status status;
- u32 pci_id;
if (!amd_iommu_detected)
return -ENODEV;
@@ -2804,16 +2803,6 @@ static int __init early_amd_iommu_init(void)
if (ret)
goto out;
- /* Disable IOMMU if there's Stoney Ridge graphics */
- for (i = 0; i < 32; i++) {
- pci_id = read_pci_config(0, i, 0, 0);
- if ((pci_id & 0x) == 0x1002 && (pci_id >> 16) == 0x98e4) {
- pr_info("Disable IOMMU on Stoney Ridge\n");
- amd_iommu_disabled = true;
- break;
- }
- }
-
/* Disable any previously enabled IOMMUs */
if (!is_kdump_kernel() || amd_iommu_disabled)
disable_iommus();
@@ -2880,6 +2869,7 @@ static bool detect_ivrs(void)
{
struct acpi_table_header *ivrs_base;
acpi_status status;
+ int i;
status = acpi_get_table("IVRS", 0, _base);
if (status == AE_NOT_FOUND)
@@ -2892,6 +2882,17 @@ static bool detect_ivrs(void)
acpi_put_table(ivrs_base);
+ /* Don't use IOMMU if there is Stoney Ridge graphics */
+ for (i = 0; i < 32; i++) {
+ u32 pci_id;
+
+ pci_id = read_pci_config(0, i, 0, 0);
+ if ((pci_id & 0x) == 0x1002 && (pci_id >> 16) == 0x98e4) {
+ pr_info("Disable IOMMU on Stoney Ridge\n");
+ return false;
+ }
+ }
+
/* Make sure ACS will be enabled during PCI probe */
pci_request_acs();
--
2.30.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 0/3] iommu/amd: Fix booting with amd_iommu=off
From: Joerg Roedel Hi, it turned out that booting a kernel with amd_iommu=off on a machine that has an AMD IOMMU causes an early kernel crash. There are two reasons for this, and fixing one of them is already sufficient, but both reasons deserve fixing, which is done in this patch-set. Regards, Joerg Joerg Roedel (3): iommu/amd: Move Stoney Ridge check to detect_ivrs() iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled iommu/amd: Keep track of amd_iommu_irq_remap state drivers/iommu/amd/init.c | 36 1 file changed, 20 insertions(+), 16 deletions(-) -- 2.30.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Fix iommu remap panic while amd_iommu is set to disable
On Tue, Mar 16, 2021 at 09:36:02PM +0800, Huang Rui wrote: > Thanks for the comments. Could you please elaborate this? > > Do you mean while amd_iommu=off, we won't prepare the IVRS, and even > needn't get all ACPI talbes. Because they are never be used and the next > state will always goes into IOMMU_CMDLINE_DISABLED, am I right? The first problem was that amd_iommu_irq_remap is never set back to false when irq-remapping initialization fails in amd_iommu_prepare(). But there are other problems, like that even when the IOMMU is set to disabled on the command line with amd_iommu=off, the code still sets up all IOMMUs and registers IRQ domains for them. Later the code checks wheter the IOMMU should stay disabled and tears everything down, except for the IRQ domains, which stay in the global list. The APIs do not really support tearing down IRQ domains well, so its not so easy to add this to the tear-down path. Now that the IRQ domains stay in the list, the ACPI code will come along later and calls the ->select() call-back for every IRQ domain, which gets execution to irq_remapping_select(), depite IOMMU being disabled and amd_iommu_rlookup_table already de-allocated. But since amd_iommu_irq_remap is still true the NULL pointer is dereferenced, causing the crash. When the IRQ domains would not be around, this would also not happen. So my patches also change the initializtion to not do all the setup work when amd_iommu=off was passed on the command line. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Fix iommu remap panic while amd_iommu is set to disable
Hi Huang, On Thu, Mar 11, 2021 at 10:28:07PM +0800, Huang Rui wrote: > diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c > index f0adbc48fd17..a08e885403b7 100644 > --- a/drivers/iommu/amd/iommu.c > +++ b/drivers/iommu/amd/iommu.c > @@ -3862,7 +3862,7 @@ static int irq_remapping_select(struct irq_domain *d, > struct irq_fwspec *fwspec, > else if (x86_fwspec_is_hpet(fwspec)) > devid = get_hpet_devid(fwspec->param[0]); > > - if (devid < 0) > + if (devid < 0 || !amd_iommu_rlookup_table) > return 0; The problem is deeper than this fix suggests. I prepared other fixes for this particular problem. Please find them here: https://git.kernel.org/pub/scm/linux/kernel/git/joro/linux.git/log/?h=iommu-fixes Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux iommu-updates-v5.12
Hi Linus, The following changes since commit 45e606f2726926b04094e1c9bf809bca4884c57f: Merge branches 'arm/renesas', 'arm/smmu', 'x86/amd', 'x86/vt-d' and 'core' into next (2021-02-12 15:27:17 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.12-rc1 for you to fetch changes up to 444d66a23c1f1e4c4d12aed4812681d0ad835d60: iommu/vt-d: Fix status code for Allocate/Free PASID command (2021-03-04 13:32:04 +0100) IOMMU Fixes for Linux v5.12-rc1 Including: - Fix for a sleeping-while-atomic issue in the AMD IOMMU code - Disabling lazy IOTLB flush for untrusted devices in the Intel VT-d driver - Fix status code definitions for Intel VT-d - Fix IO Page Fault issue in Tegra IOMMU driver Andrey Ryabinin (1): iommu/amd: Fix sleeping in atomic in increase_address_space() Lu Baolu (1): iommu: Don't use lazy flush for untrusted device Nicolin Chen (1): iommu/tegra-smmu: Fix mc errors on tegra124-nyan Zenghui Yu (1): iommu/vt-d: Fix status code for Allocate/Free PASID command drivers/iommu/amd/io_pgtable.c | 10 +++--- drivers/iommu/dma-iommu.c | 15 + drivers/iommu/intel/pasid.h| 4 +-- drivers/iommu/tegra-smmu.c | 72 +- 4 files changed, 87 insertions(+), 14 deletions(-) Please pull. Thanks, Joerg signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Fix status code for Allocate/Free PASID command
On Sat, Feb 27, 2021 at 03:39:09PM +0800, Zenghui Yu wrote:
> As per Intel vt-d spec, Rev 3.0 (section 10.4.45 "Virtual Command Response
> Register"), the status code of "No PASID available" error in response to
> the Allocate PASID command is 2, not 1. The same for "Invalid PASID" error
> in response to the Free PASID command.
>
> We will otherwise see confusing kernel log under the command failure from
> guest side. Fix it.
>
> Fixes: 24f27d32ab6b ("iommu/vt-d: Enlightened PASID allocation")
> Signed-off-by: Zenghui Yu
Applied for v5.12, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/tegra-smmu: Fix mc errors on tegra124-nyan
On Thu, Feb 18, 2021 at 02:07:02PM -0800, Nicolin Chen wrote: > drivers/iommu/tegra-smmu.c | 72 +- > 1 file changed, 71 insertions(+), 1 deletion(-) Applied for v5.12, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/5] iommu/vt-d: Remove WO permissions on second-level paging entries
On Thu, Feb 25, 2021 at 02:26:51PM +0800, Lu Baolu wrote: > When the first level page table is used for IOVA translation, it only > supports Read-Only and Read-Write permissions. The Write-Only permission > is not supported as the PRESENT bit (implying Read permission) should > always set. When using second level, we still give separate permissions > that allows WriteOnly which seems inconsistent and awkward. There is no > use case we can think off, hence remove that configuration to make it > consistent. No use-case for WriteOnly mappings? How about DMA_FROM_DEVICE mappings? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Fix sleeping in atomic in increase_address_space()
On Wed, Feb 17, 2021 at 06:10:02PM +, Will Deacon wrote:
> > drivers/iommu/amd/iommu.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
>
> Acked-by: Will Deacon
Applied for v5.12, thanks.
There were some conflicts which I resolved, can you please check the
result, Andrey? The updated patch is attached.
>From 140456f994195b568ecd7fc2287a34eadffef3ca Mon Sep 17 00:00:00 2001
From: Andrey Ryabinin
Date: Wed, 17 Feb 2021 17:30:04 +0300
Subject: [PATCH] iommu/amd: Fix sleeping in atomic in increase_address_space()
increase_address_space() calls get_zeroed_page(gfp) under spin_lock with
disabled interrupts. gfp flags passed to increase_address_space() may allow
sleeping, so it comes to this:
BUG: sleeping function called from invalid context at mm/page_alloc.c:4342
in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8
Call Trace:
dump_stack+0x66/0x8b
___might_sleep+0xec/0x110
__alloc_pages_nodemask+0x104/0x300
get_zeroed_page+0x15/0x40
iommu_map_page+0xdd/0x3e0
amd_iommu_map+0x50/0x70
iommu_map+0x106/0x220
vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1]
do_vfs_ioctl+0xa3/0x6f0
ksys_ioctl+0x66/0x70
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x4e/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fix this by moving get_zeroed_page() out of spin_lock/unlock section.
Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()")
Signed-off-by: Andrey Ryabinin
Acked-by: Will Deacon
Cc:
Link: https://lore.kernel.org/r/20210217143004.19165-1-a...@yandex-team.com
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/io_pgtable.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index 1c4961e05c12..bb0ee5c9fde7 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -182,6 +182,10 @@ static bool increase_address_space(struct
protection_domain *domain,
bool ret = true;
u64 *pte;
+ pte = (void *)get_zeroed_page(gfp);
+ if (!pte)
+ return false;
+
spin_lock_irqsave(>lock, flags);
if (address <= PM_LEVEL_SIZE(domain->iop.mode))
@@ -191,10 +195,6 @@ static bool increase_address_space(struct
protection_domain *domain,
if (WARN_ON_ONCE(domain->iop.mode == PAGE_MODE_6_LEVEL))
goto out;
- pte = (void *)get_zeroed_page(gfp);
- if (!pte)
- goto out;
-
*pte = PM_LEVEL_PDE(domain->iop.mode,
iommu_virt_to_phys(domain->iop.root));
domain->iop.root = pte;
@@ -208,10 +208,12 @@ static bool increase_address_space(struct
protection_domain *domain,
*/
amd_iommu_domain_set_pgtable(domain, pte, domain->iop.mode);
+ pte = NULL;
ret = true;
out:
spin_unlock_irqrestore(>lock, flags);
+ free_page((unsigned long)pte);
return ret;
}
--
2.26.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver
On Mon, Mar 01, 2021 at 09:42:40AM +0100, Christoph Hellwig wrote: > Diffstat: > arch/powerpc/include/asm/fsl_pamu_stash.h | 12 > drivers/gpu/drm/msm/adreno/adreno_gpu.c |2 > drivers/iommu/amd/iommu.c | 23 > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 85 --- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 122 +--- > drivers/iommu/dma-iommu.c |8 > drivers/iommu/fsl_pamu.c| 264 -- > drivers/iommu/fsl_pamu.h| 10 > drivers/iommu/fsl_pamu_domain.c | 694 > ++-- > drivers/iommu/fsl_pamu_domain.h | 46 - > drivers/iommu/intel/iommu.c | 55 -- > drivers/iommu/iommu.c | 75 --- > drivers/soc/fsl/qbman/qman_portal.c | 56 -- > drivers/vfio/vfio_iommu_type1.c | 31 - > drivers/vhost/vdpa.c| 10 > include/linux/iommu.h | 81 --- > 16 files changed, 214 insertions(+), 1360 deletions(-) Nice cleanup, thanks. The fsl_pamu driver and interface has always been a little bit of an alien compared to other IOMMU drivers. I am inclined to merge this after -rc3 is out, given some reviews. Can you also please add changelogs to the last three patches? Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Updates for Linux v5.12
Hi Linus, The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v5.12 for you to fetch changes up to 45e606f2726926b04094e1c9bf809bca4884c57f: Merge branches 'arm/renesas', 'arm/smmu', 'x86/amd', 'x86/vt-d' and 'core' into next (2021-02-12 15:27:17 +0100) IOMMU Updates for Linux v5.12 Including: - ARM SMMU and Mediatek updates from Will Deacon: - Support for MT8192 IOMMU from Mediatek - Arm v7s io-pgtable extensions for MT8192 - Removal of TLBI_ON_MAP quirk - New Qualcomm compatible strings - Allow SVA without hardware broadcast TLB maintenance on SMMUv3 - Virtualization Host Extension support for SMMUv3 (SVA) - Allow SMMUv3 PMU (perf) driver to be built independently from IOMMU - Some tidy-up in IOVA and core code - Conversion of the AMD IOMMU code to use the generic IO-page-table framework - Intel VT-d updates from Lu Baolu: - Audit capability consistency among different IOMMUs - Add SATC reporting structure support - Add iotlb_sync_map callback support - SDHI Support for Renesas IOMMU driver - Misc Cleanups and other small improvments Adrian Huang (1): iommu/amd: Remove unnecessary assignment Bjorn Andersson (2): dt-bindings: arm-smmu-qcom: Add Qualcomm SC8180X compatible iommu/arm-smmu-qcom: Add Qualcomm SC8180X impl Bjorn Helgaas (1): iommu/vt-d: Fix 'physical' typos Colin Ian King (1): iommu/mediatek: Fix unsigned domid comparison with less than zero Dan Carpenter (1): iommu/mediatek: Fix error code in probe() Douglas Anderson (1): iommu: Properly pass gfp_t in _iommu_map() to avoid atomic sleeping Isaac J. Manjarres (1): iommu/arm-smmu-qcom: Fix mask extraction for bootloader programmed SMRs Jean-Philippe Brucker (3): iommu/arm-smmu-v3: Split arm_smmu_tlb_inv_range() iommu/arm-smmu-v3: Make BTM optional for SVA iommu/arm-smmu-v3: Add support for VHE Joerg Roedel (2): Merge tag 'arm-smmu-updates' of git://git.kernel.org/.../will/linux into arm/smmu Merge branches 'arm/renesas', 'arm/smmu', 'x86/amd', 'x86/vt-d' and 'core' into next John Garry (7): iova: Make has_iova_flush_queue() private iova: Delete copy_reserved_iova() iova: Stop exporting some more functions iommu: Stop exporting iommu_map_sg_atomic() iommu: Delete iommu_domain_window_disable() iommu: Delete iommu_dev_has_feature() driver/perf: Remove ARM_SMMU_V3_PMU dependency on ARM_SMMU_V3 Kyung Min Park (2): iommu/vt-d: Audit IOMMU Capabilities and add helper functions iommu/vt-d: Move capability check code to cap_audit files Lianbo Jiang (2): dma-iommu: use static-key to minimize the impact in the fast-path iommu: use the __iommu_attach_device() directly for deferred attach Lu Baolu (7): iommu/vt-d: Consolidate duplicate cache invaliation code iommu/vt-d: Add qi_submit trace event iommu/vt-d: Preset Access/Dirty bits for IOVA over FL iommu/vt-d: Clear PRQ overflow only when PRQ is empty iommu/vt-d: Use INVALID response code instead of FAILURE iommu/vt-d: Fix compile error [-Werror=implicit-function-declaration] iommu/vt-d: Add iotlb_sync_map callback Lukas Bulwahn (1): MAINTAINERS: repair file pattern in MEDIATEK IOMMU DRIVER Robin Murphy (3): iommu/arm-smmu-v3: Remove the page 1 fixup iommu/msm: Hook up iotlb_sync_map iommu/io-pgtable: Remove TLBI_ON_MAP quirk Suravee Suthikulpanit (14): iommu/amd: Re-define amd_iommu_domain_encode_pgtable as inline iommu/amd: Prepare for generic IO page table framework iommu/amd: Move pt_root to struct amd_io_pgtable iommu/amd: Convert to using amd_io_pgtable iommu/amd: Declare functions as extern iommu/amd: Move IO page table related functions iommu/amd: Restructure code for freeing page table iommu/amd: Remove amd_iommu_domain_get_pgtable iommu/amd: Rename variables to be consistent with struct io_pgtable_ops iommu/amd: Refactor fetch_pte to use struct amd_io_pgtable iommu/amd: Introduce iommu_v1_iova_to_phys iommu/amd: Introduce iommu_v1_map_page and iommu_v1_unmap_page iommu/amd: Adopt IO page table framework for AMD IOMMU v1 page table iommu/amd: Fix performance counter initialization Tom Rix (1): iommu/amd: remove h from printk format specifier Vinod Koul (2): dt-bindings: arm-smmu: Add
Re: [PATCH] iommu: Add device name to iommu map/unmap trace events
On Tue, Feb 09, 2021 at 06:06:20PM +0530, Sai Prakash Ranjan wrote:
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 5e7fe519430a..6064187d9bb6 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -87,6 +87,7 @@ struct iommu_domain {
> void *handler_token;
> struct iommu_domain_geometry geometry;
> void *iova_cookie;
> + char dev_name[32];
> };
No, definitly not. A domain is a device DMA address space which can be
used by more than one device. Just look at IOMMU groups with more than
one member device, in this case just one device name would be very
misleading.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Fix performance counter initialization
On Mon, Feb 08, 2021 at 06:27:12AM -0600, Suravee Suthikulpanit wrote: > drivers/iommu/amd/init.c | 45 ++-- > 1 file changed, 34 insertions(+), 11 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] MAINTAINERS: repair file pattern in MEDIATEK IOMMU DRIVER
On Mon, Feb 08, 2021 at 02:35:25PM +0800, Yong Wu wrote:
> On Mon, 2021-02-08 at 07:10 +0100, Lukas Bulwahn wrote:
> > Commit 6af4873852c4 ("MAINTAINERS: Add entry for MediaTek IOMMU") mentions
> > the pattern 'drivers/iommu/mtk-iommu*', but the files are actually named
> > with an underscore, not with a hyphen.
> >
> > Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
> >
> > warning: no file matches F:drivers/iommu/mtk-iommu*
> >
> > Repair this minor typo in the file pattern.
> >
> > Signed-off-by: Lukas Bulwahn
> > ---
> > applies cleanly on next-20210205
> >
> > Yong, please ack.
>
> +Joerg.
>
> sorry for the typo.
>
> Acked-by: Yong Wu
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/mediatek: Fix error code in probe()
On Fri, Feb 05, 2021 at 03:46:17PM +0300, Dan Carpenter wrote: > drivers/iommu/mtk_iommu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fix for Linux v5.11-rc6
Hi Linus, The following changes since commit 1048ba83fb1c00cd24172e23e8263972f6b5d9ac: Linux 5.11-rc6 (2021-01-31 13:50:09 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.11-rc6 for you to fetch changes up to 4c9fb5d9140802db4db9f66c23887f43174e113c: iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it (2021-02-02 15:57:23 +0100) IOMMU Fix for Linux v5.11-rc6 - Fix a possible NULL-ptr dereference in dev_iommu_priv_get() which is too easy to accidentially trigger from IOMMU drivers. In the current case the AMD IOMMU driver triggered it on some machines in the IO-page-fault path, so fix it once and for all. ---- Joerg Roedel (1): iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it include/linux/iommu.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Please pull. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH][next][V2] iommu/mediatek: Fix unsigned domid comparison with less than zero
On Thu, Feb 04, 2021 at 03:00:01PM +, Colin King wrote: > drivers/iommu/mtk_iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/2] VMD MSI Remapping Bypass
On Thu, Feb 04, 2021 at 12:09:04PM -0700, Jon Derrick wrote:
> Jon Derrick (2):
> iommu/vt-d: Use Real PCI DMA device for IRTE
> PCI: vmd: Disable MSI/X remapping when possible
>
> drivers/iommu/intel/irq_remapping.c | 3 +-
> drivers/pci/controller/vmd.c| 60 +++--
> 2 files changed, 50 insertions(+), 13 deletions(-)
This probably goes via Bjorn's tree, so
Acked-by: Joerg Roedel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/7] [PULL REQUEST] iommu/vt-d: Update for v5.12
On Thu, Feb 04, 2021 at 07:52:29PM +0800, Lu Baolu wrote: > Hi Joerg, > > I just received some internal comments on the last patch > > [PATCH 7/7] iommu/vt-d: Apply SATC policy > > We need some extra work on it and probably re-target it to v5.13. > > Can you please only consider patch 1 ~ 6 for v5.12? Applied patches 1-6, thanks Baolu. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 16/16] iommu/hyperv: setup an IO-APIC IRQ remapping domain for root partition
On Wed, Feb 03, 2021 at 03:04:35PM +, Wei Liu wrote:
> Just like MSI/MSI-X, IO-APIC interrupts are remapped by Microsoft
> Hypervisor when Linux runs as the root partition. Implement an IRQ
> domain to handle mapping and unmapping of IO-APIC interrupts.
>
> Signed-off-by: Wei Liu
Acked-by: Joerg Roedel
> ---
> v6:
> 1. Simplify code due to changes in a previous patch.
> ---
> arch/x86/hyperv/irqdomain.c | 25 +
> arch/x86/include/asm/mshyperv.h | 4 +
> drivers/iommu/hyperv-iommu.c| 177 +++-
> 3 files changed, 203 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/hyperv/irqdomain.c b/arch/x86/hyperv/irqdomain.c
> index 117f17e8c88a..0cabc9aece38 100644
> --- a/arch/x86/hyperv/irqdomain.c
> +++ b/arch/x86/hyperv/irqdomain.c
> @@ -360,3 +360,28 @@ struct irq_domain * __init hv_create_pci_msi_domain(void)
> }
>
> #endif /* CONFIG_PCI_MSI */
> +
> +int hv_unmap_ioapic_interrupt(int ioapic_id, struct hv_interrupt_entry
> *entry)
> +{
> + union hv_device_id device_id;
> +
> + device_id.as_uint64 = 0;
> + device_id.device_type = HV_DEVICE_TYPE_IOAPIC;
> + device_id.ioapic.ioapic_id = (u8)ioapic_id;
> +
> + return hv_unmap_interrupt(device_id.as_uint64, entry);
> +}
> +EXPORT_SYMBOL_GPL(hv_unmap_ioapic_interrupt);
> +
> +int hv_map_ioapic_interrupt(int ioapic_id, bool level, int cpu, int vector,
> + struct hv_interrupt_entry *entry)
> +{
> + union hv_device_id device_id;
> +
> + device_id.as_uint64 = 0;
> + device_id.device_type = HV_DEVICE_TYPE_IOAPIC;
> + device_id.ioapic.ioapic_id = (u8)ioapic_id;
> +
> + return hv_map_interrupt(device_id, level, cpu, vector, entry);
> +}
> +EXPORT_SYMBOL_GPL(hv_map_ioapic_interrupt);
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index ccc849e25d5e..345d7c6f8c37 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -263,6 +263,10 @@ static inline void hv_set_msi_entry_from_desc(union
> hv_msi_entry *msi_entry,
>
> struct irq_domain *hv_create_pci_msi_domain(void);
>
> +int hv_map_ioapic_interrupt(int ioapic_id, bool level, int vcpu, int vector,
> + struct hv_interrupt_entry *entry);
> +int hv_unmap_ioapic_interrupt(int ioapic_id, struct hv_interrupt_entry
> *entry);
> +
> #else /* CONFIG_HYPERV */
> static inline void hyperv_init(void) {}
> static inline void hyperv_setup_mmu_ops(void) {}
> diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> index 1d21a0b5f724..e285a220c913 100644
> --- a/drivers/iommu/hyperv-iommu.c
> +++ b/drivers/iommu/hyperv-iommu.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include "irq_remapping.h"
>
> @@ -115,30 +116,43 @@ static const struct irq_domain_ops hyperv_ir_domain_ops
> = {
> .free = hyperv_irq_remapping_free,
> };
>
> +static const struct irq_domain_ops hyperv_root_ir_domain_ops;
> static int __init hyperv_prepare_irq_remapping(void)
> {
> struct fwnode_handle *fn;
> int i;
> + const char *name;
> + const struct irq_domain_ops *ops;
>
> if (!hypervisor_is_type(X86_HYPER_MS_HYPERV) ||
> x86_init.hyper.msi_ext_dest_id() ||
> !x2apic_supported())
> return -ENODEV;
>
> - fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> + if (hv_root_partition) {
> + name = "HYPERV-ROOT-IR";
> + ops = _root_ir_domain_ops;
> + } else {
> + name = "HYPERV-IR";
> + ops = _ir_domain_ops;
> + }
> +
> + fn = irq_domain_alloc_named_id_fwnode(name, 0);
> if (!fn)
> return -ENOMEM;
>
> ioapic_ir_domain =
> irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
> - 0, IOAPIC_REMAPPING_ENTRY, fn,
> - _ir_domain_ops, NULL);
> + 0, IOAPIC_REMAPPING_ENTRY, fn, ops, NULL);
>
> if (!ioapic_ir_domain) {
> irq_domain_free_fwnode(fn);
> return -ENOMEM;
> }
>
> + if (hv_root_partition)
> + return 0; /* The rest is only relevant to guests */
> +
> /*
>* Hyper-V doesn't provide irq remapping function for
>* IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> @@ -166,4 +180,161 @@ struct irq_remap_ops hyperv_irq_remap_ops = {
> .enable = hyperv_enable_irq_remapping,
> };
>
> +/* IRQ remapping domain w
Re: [PATCH][next] iommu/mediatek: Fix unsigned domid comparison with less than zero
On Thu, Feb 04, 2021 at 09:25:58AM +, Will Deacon wrote:
> On Wed, Feb 03, 2021 at 01:59:36PM +, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the check for domid < 0 is always false because domid
> > is unsigned. Fix this by making it signed.
> >
> > Addresses-CoverityL ("Unsigned comparison against 0")
>
> Typo here ('L' instead of ':')
>
> > Fixes: ab1d5281a62b ("iommu/mediatek: Add iova reserved function")
> > Signed-off-by: Colin Ian King
> > ---
> > drivers/iommu/mtk_iommu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 0ad14a7604b1..823d719945b2 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -640,7 +640,7 @@ static void mtk_iommu_get_resv_regions(struct device
> > *dev,
> >struct list_head *head)
> > {
> > struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
> > - unsigned int domid = mtk_iommu_get_domain_id(dev, data->plat_data), i;
> > + int domid = mtk_iommu_get_domain_id(dev, data->plat_data), i;
>
> Not sure if it's intentional, but this also makes 'i' signed. It probably
> should remain 'unsigned' to match 'iova_region_nr' in
> 'struct mtk_iommu_plat_data'.
Yes, 'i' should stay unsigned. Colin, can you please fix that up and
re-send?
Thanks,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it
From: Joerg Roedel
The dev_iommu_priv_get() needs a similar check to
dev_iommu_fwspec_get() to make sure no NULL-ptr is dereferenced.
Fixes: 05a0542b456e1 ("iommu/amd: Store dev_data as device iommu private data")
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=211241
Cc: sta...@vger.kernel.org # v5.8+
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 524ffc2ff64f..5b3a7a08dc70 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -616,7 +616,10 @@ static inline void dev_iommu_fwspec_set(struct device *dev,
static inline void *dev_iommu_priv_get(struct device *dev)
{
- return dev->iommu->priv;
+ if (dev->iommu)
+ return dev->iommu->priv;
+ else
+ return NULL;
}
static inline void dev_iommu_priv_set(struct device *dev, void *priv)
--
2.30.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] iommu: add Unisoc iommu basic driver
On Tue, Feb 02, 2021 at 02:34:34PM +, Robin Murphy wrote: > Nope, I believe if Arm Ltd. had any involvement in this I'd know about it :) Okay, got confused by thinking of ARM as the CPU architecture, not the company :) But given the intel/ and amd/ subdirectories refer to company names as well, the same is true for arm/. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] iommu: add Unisoc iommu basic driver
On Tue, Feb 02, 2021 at 06:42:57PM +0800, Chunyan Zhang wrote:
> +static phys_addr_t sprd_iommu_iova_to_phys(struct iommu_domain *domain,
> +dma_addr_t iova)
> +{
> + struct sprd_iommu_domain *dom = to_sprd_domain(domain);
> + unsigned long flags;
> + phys_addr_t pa;
> + unsigned long start = domain->geometry.aperture_start;
> + unsigned long end = domain->geometry.aperture_end;
> +
> + if (iova < start || iova > end)
> + pr_err("iova (0x%llx) exceed the vpn range[0x%lx-0x%lx]!\n",
> +iova, start, end);
It is not a good idea to continue here with an out-of-range iova. The
code below might access random memory for its checks. Better do a
WARN_ON here and return an invalid physical address.
> +
> + spin_lock_irqsave(>pgtlock, flags);
> + pa = *(dom->pgt_va + ((iova - start) >> SPRD_IOMMU_PAGE_SHIFT));
> + pa = (pa << SPRD_IOMMU_PAGE_SHIFT) + ((iova - start) &
> (SPRD_IOMMU_PAGE_SIZE - 1));
> + spin_unlock_irqrestore(>pgtlock, flags);
> +
> + return pa;
> +}
> +
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] iommu: add Unisoc iommu basic driver
On Tue, Feb 02, 2021 at 06:42:57PM +0800, Chunyan Zhang wrote: > From: Chunyan Zhang > > This iommu module can be used by Unisoc's multimedia devices, such as > display, Image codec(jpeg) and a few signal processors, including > VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc. > > Signed-off-by: Chunyan Zhang > --- > drivers/iommu/Kconfig | 12 + > drivers/iommu/Makefile | 1 + > drivers/iommu/sprd-iommu.c | 598 + This looks like it actually belongs under drivers/iommu/arm/, no? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: Properly pass gfp_t in _iommu_map() to avoid atomic sleeping
On Mon, Feb 01, 2021 at 05:06:23PM -0800, Douglas Anderson wrote: > drivers/iommu/iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] iommu/arm-smmu: Updates for 5.12
On Tue, Feb 02, 2021 at 01:53:41PM +, Will Deacon wrote: > On Tue, Feb 02, 2021 at 02:34:56PM +0100, Joerg Roedel wrote: > > On Mon, Feb 01, 2021 at 03:46:33PM +, Will Deacon wrote: > > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git > > > tags/arm-smmu-updates > > > > Pulled, thanks Will. > > Cheers, Joerg. Doug spotted a thinko in one of the patches, so you'll want > to apply this guy on top: > > https://lore.kernel.org/r/20210201170611.1.I64a7b62579287d668d7c89e105dcedf45d641063@changeid Yes, applied on-top of your pull-request. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/3] iommu/vt-d: Apply SATC policy
On Tue, Feb 02, 2021 at 12:40:57PM +0800, Lu Baolu wrote:
> + 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) &&
> satcu->atc_required) {
You can safe a level of indentation and make this look nicer if you do:
if (satc->segment != pci_domain_nr(dev->bus) ||
!satcu->atc_required)
continue;
> + for_each_dev_scope(satcu->devices, satcu->devices_cnt,
> i, tmp)
> + if (to_pci_dev(tmp) == dev)
> + goto out;
> + }
> + }
> + ret = 0;
> +out:
> + rcu_read_unlock();
> + return ret;
> +}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/3] iommu/vt-d: Parse SATC reporting structure
On Tue, Feb 02, 2021 at 12:40:56PM +0800, Lu Baolu wrote:
> + case ACPI_DMAR_TYPE_SATC:
> + satc = container_of(header, struct acpi_dmar_satc, header);
> + pr_info("SATC flags: 0x%x\n", satc->flags);
> + break;
Did the pr_info() slip through or is there a real purpose for having
this information in the kernel log?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] iommu/vt-d: Add new enum value and structure for SATC
Hi Baolu,
On Tue, Feb 02, 2021 at 12:40:55PM +0800, Lu Baolu wrote:
> @@ -514,7 +514,8 @@ enum acpi_dmar_type {
> ACPI_DMAR_TYPE_ROOT_ATS = 2,
> ACPI_DMAR_TYPE_HARDWARE_AFFINITY = 3,
> ACPI_DMAR_TYPE_NAMESPACE = 4,
> - ACPI_DMAR_TYPE_RESERVED = 5 /* 5 and greater are reserved */
> + ACPI_DMAR_TYPE_SATC = 5,
> + ACPI_DMAR_TYPE_RESERVED = 6 /* 5 and greater are reserved */
Nit: The comment needs to be updated too.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Fix compile error [-Werror=implicit-function-declaration]
On Sat, Jan 30, 2021 at 11:19:07PM +0800, Lu Baolu wrote: > drivers/iommu/intel/Makefile | 2 +- > drivers/iommu/intel/iommu.c| 1 - > include/trace/events/intel_iommu.h | 2 -- > 3 files changed, 1 insertion(+), 4 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] iommu/arm-smmu: Updates for 5.12
On Mon, Feb 01, 2021 at 03:46:33PM +, Will Deacon wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git > tags/arm-smmu-updates Pulled, thanks Will. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux v5.11-rc5
Hi Linus, The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04: Linux 5.11-rc5 (2021-01-24 16:47:14 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.11-rc5 for you to fetch changes up to 29b32839725f8c89a41cb6ee054c85f3116ea8b5: iommu/vt-d: Do not use flush-queue when caching-mode is on (2021-01-28 13:59:02 +0100) IOMMU Fixes for Linux v5.11-rc5 Including: - AMD IOMMU Fix to make sure features are detected before they are queried. - Intel IOMMU address alignment check fix for an IOLTB flushing command. - Performance fix for Intel IOMMU to make sure the code does not do full IOTLB flushes all the time. Those flushes are very expensive on emulated IOMMUs. Lu Baolu (1): iommu/vt-d: Correctly check addr alignment in qi_flush_dev_iotlb_pasid() Nadav Amit (1): iommu/vt-d: Do not use flush-queue when caching-mode is on Suravee Suthikulpanit (1): iommu/amd: Use IVHD EFR for early initialization of IOMMU features drivers/iommu/amd/amd_iommu.h | 7 ++--- drivers/iommu/amd/amd_iommu_types.h | 4 +++ drivers/iommu/amd/init.c| 56 +++-- drivers/iommu/intel/dmar.c | 2 +- drivers/iommu/intel/iommu.c | 32 - 5 files changed, 92 insertions(+), 9 deletions(-) Please pull. Thanks, Joerg signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/2] iommu/ipmmu-vmsa: refactoring and allow SDHI devices
On Thu, Jan 28, 2021 at 10:02:58PM +0900, Yoshihiro Shimoda wrote: > Yoshihiro Shimoda (2): > iommu/ipmmu-vmsa: refactor ipmmu_of_xlate() > iommu/ipmmu-vmsa: Allow SDHI devices > > drivers/iommu/ipmmu-vmsa.c | 53 > +++--- > 1 file changed, 22 insertions(+), 31 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/2] iommu/vt-d: Some misc tweaks in SVA
On Tue, Jan 26, 2021 at 04:07:28PM +0800, Lu Baolu wrote: > Lu Baolu (2): > iommu/vt-d: Clear PRQ overflow only when PRQ is empty > iommu/vt-d: Use INVALID response code instead of FAILURE > > drivers/iommu/intel/svm.c | 18 -- > 1 file changed, 12 insertions(+), 6 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 2/9] iommu: Add iova and size as parameters in iotlb_sync_map
On Thu, Jan 28, 2021 at 01:19:29PM +, Will Deacon wrote: > Heads-up, but I already queued this patch as part of its original series: > > https://lore.kernel.org/r/20210107122909.16317-1-yong...@mediatek.com > > since it's part of the Mediatek series for 5.12. > > Would you like me to drop that, or can we stick with passing iova and size > for now, with a view to refactoring it later on? I think its okay for now, we can refactor it later. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: Check dev->iommu in iommu_dev_xxx functions
On Tue, Jan 26, 2021 at 01:06:29PM +, Shameer Kolothum wrote: > The device iommu probe/attach might have failed leaving dev->iommu > to NULL and device drivers may still invoke these functions resulting > a crash in iommu vendor driver code. Hence make sure we check that. > > Signed-off-by: Shameer Kolothum > --- > drivers/iommu/iommu.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index ffeebda8d6de..cb68153c5cc0 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -2867,7 +2867,7 @@ bool iommu_dev_has_feature(struct device *dev, enum > iommu_dev_features feat) This function has been removed from the iommu-tree. Can you please rebase this patch against the latest 'core' branch when I pushed it later this week (maybe even later today)? A Fixes tag would be nice too. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH RFC 2/9] iommu: Add iova and size as parameters in iotlb_sync_map
Hi Chuck, thanks for your optimizations! On Wed, Jan 27, 2021 at 03:00:32PM -0500, Chuck Lever wrote: > From: Yong Wu > > iotlb_sync_map allow IOMMU drivers tlb sync after completing the whole > mapping. This patch adds iova and size as the parameters in it. then the > IOMMU driver could flush tlb with the whole range once after iova mapping > to improve performance. > > Signed-off-by: Yong Wu > Reviewed-by: Robin Murphy > Signed-off-by: Chuck Lever > --- > drivers/iommu/iommu.c |4 ++-- > drivers/iommu/tegra-gart.c |7 +-- > include/linux/iommu.h |3 ++- > 3 files changed, 9 insertions(+), 5 deletions(-) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index c304a6a30d42..3d099a31ddca 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -2443,7 +2443,7 @@ static int _iommu_map(struct iommu_domain *domain, > unsigned long iova, > > ret = __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL); > if (ret == 0 && ops->iotlb_sync_map) > - ops->iotlb_sync_map(domain); > + ops->iotlb_sync_map(domain, iova, size); How about using 'struct iommu_iotlb_gather' instead of directly passing the iova/size parameters here? The iotlb_sync() call-back uses it already. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/2] iommu: fix the failure of deferred attach for iommu attach device
On Tue, Jan 26, 2021 at 07:53:35PM +0800, Lianbo Jiang wrote: > Lianbo Jiang (2): > dma-iommu: use static-key to minimize the impact in the fast-path > iommu: use the __iommu_attach_device() directly for deferred attach > > drivers/iommu/dma-iommu.c | 29 +++-- > drivers/iommu/iommu.c | 10 ++ > include/linux/iommu.h | 1 + > 3 files changed, 22 insertions(+), 18 deletions(-) Sorry, missed that there was a newer version. Applied this instead of v2. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Correctly check addr alignment in qi_flush_dev_iotlb_pasid()
On Tue, Jan 19, 2021 at 12:35:00PM +0800, Lu Baolu wrote:
> An incorrect address mask is being used in the qi_flush_dev_iotlb_pasid()
> to check the address alignment. This leads to a lot of spurious kernel
> warnings:
>
> [ 485.837093] DMAR: Invalidate non-aligned address 7f76f47f9000, order 0
> [ 485.837098] DMAR: Invalidate non-aligned address 7f76f47f9000, order 0
> [ 492.494145] qi_flush_dev_iotlb_pasid: 5734 callbacks suppressed
> [ 492.494147] DMAR: Invalidate non-aligned address 7f772880, order 11
> [ 492.508965] DMAR: Invalidate non-aligned address 7f772880, order 11
>
> Fix it by checking the alignment in right way.
>
> Fixes: 288d08e780088 ("iommu/vt-d: Handle non-page aligned address")
> Reported-and-tested-by: Guo Kaijie
> Signed-off-by: Lu Baolu
> Cc: Liu Yi L
> ---
> drivers/iommu/intel/dmar.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied for 5.11, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/2 v2] iommu: fix the failure of deferred attach for iommu attach device
On Tue, Jan 19, 2021 at 07:16:14PM +0800, Lianbo Jiang wrote: > Lianbo Jiang (2): > dma-iommu: use static-key to minimize the impact in the fast-path > iommu: use the __iommu_attach_device() directly for deferred attach > > drivers/iommu/dma-iommu.c | 29 +++-- > drivers/iommu/iommu.c | 12 > include/linux/iommu.h | 2 ++ > 3 files changed, 25 insertions(+), 18 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Preset Access/Dirty bits for IOVA over FL
On Fri, Jan 15, 2021 at 08:42:02AM +0800, Lu Baolu wrote: > The Access/Dirty bits in the first level page table entry will be set > whenever a page table entry was used for address translation or write > permission was successfully translated. This is always true when using > the first-level page table for kernel IOVA. Instead of wasting hardware > cycles to update the certain bits, it's better to set them up at the > beginning. > > Suggested-by: Ashok Raj > Signed-off-by: Lu Baolu > --- > drivers/iommu/intel/iommu.c | 14 -- > include/linux/intel-iommu.h | 2 ++ > 2 files changed, 14 insertions(+), 2 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Add qi_submit trace event
On Thu, Jan 14, 2021 at 05:04:00PM +0800, Lu Baolu wrote: > This adds a new trace event to track the submissions of requests to the > invalidation queue. This event will provide the information like: > - IOMMU name > - Invalidation type > - Descriptor raw data > > A sample output like: > | qi_submit: iotlb_inv dmar1: 0x100e2 0x0 0x0 0x0 > | qi_submit: dev_tlb_inv dmar1: 0x13 0x7001 0x0 0x0 > | qi_submit: iotlb_inv dmar2: 0x800f2 0xf9a5 0x0 0x0 > > This will be helpful for queued invalidation related debugging. > > Signed-off-by: Lu Baolu > --- > drivers/iommu/intel/dmar.c | 3 +++ > include/trace/events/intel_iommu.h | 37 ++ > 2 files changed, 40 insertions(+) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Consolidate duplicate cache invaliation code
On Thu, Jan 14, 2021 at 04:50:21PM +0800, Lu Baolu wrote: > The pasid based IOTLB and devTLB invalidation code is duplicate in > several places. Consolidate them by using the common helpers. > > Signed-off-by: Lu Baolu > --- > drivers/iommu/intel/pasid.c | 18 ++-- > drivers/iommu/intel/svm.c | 55 ++--- > 2 files changed, 11 insertions(+), 62 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 00/13] iommu/amd: Add Generic IO Page Table Framework Support
Hi Suravee, On Tue, Dec 15, 2020 at 01:36:52AM -0600, Suravee Suthikulpanit wrote: > Suravee Suthikulpanit (13): > iommu/amd: Re-define amd_iommu_domain_encode_pgtable as inline > iommu/amd: Prepare for generic IO page table framework > iommu/amd: Move pt_root to struct amd_io_pgtable > iommu/amd: Convert to using amd_io_pgtable > iommu/amd: Declare functions as extern > iommu/amd: Move IO page table related functions > iommu/amd: Restructure code for freeing page table > iommu/amd: Remove amd_iommu_domain_get_pgtable > iommu/amd: Rename variables to be consistent with struct > io_pgtable_ops > iommu/amd: Refactor fetch_pte to use struct amd_io_pgtable > iommu/amd: Introduce iommu_v1_iova_to_phys > iommu/amd: Introduce iommu_v1_map_page and iommu_v1_unmap_page > iommu/amd: Adopt IO page table framework for AMD IOMMU v1 page table Applied this series, thanks for the work! Given testing goes well you can consider this queued for 5.12. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
