[git pull] IOMMU Updates for Linux v5.13

2021-04-30 Thread Joerg Roedel
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

2021-04-22 Thread Joerg Roedel
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

2021-04-16 Thread Joerg Roedel
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

2021-04-16 Thread Joerg Roedel
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

2021-04-15 Thread Joerg Roedel
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

2021-04-15 Thread Joerg Roedel
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

2021-04-15 Thread Joerg Roedel
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()'

2021-04-15 Thread Joerg Roedel
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

2021-04-15 Thread Joerg Roedel
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

2021-04-15 Thread Joerg Roedel
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

2021-04-15 Thread Joerg Roedel
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

2021-04-15 Thread Joerg Roedel
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

2021-04-08 Thread Joerg Roedel
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

2021-04-08 Thread Joerg Roedel
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

2021-04-08 Thread Joerg Roedel
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

2021-04-08 Thread Joerg Roedel
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"

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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()

2021-04-07 Thread Joerg Roedel
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()

2021-04-07 Thread Joerg Roedel
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

2021-04-07 Thread Joerg Roedel
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

2021-04-06 Thread Joerg Roedel
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"

2021-03-19 Thread Joerg Roedel
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

2021-03-19 Thread Joerg Roedel
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()

2021-03-19 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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()

2021-03-18 Thread Joerg Roedel
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()

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-18 Thread Joerg Roedel
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

2021-03-17 Thread Joerg Roedel
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

2021-03-17 Thread Joerg Roedel
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

2021-03-17 Thread Joerg Roedel
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

2021-03-17 Thread Joerg Roedel
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()

2021-03-17 Thread Joerg Roedel
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

2021-03-17 Thread Joerg Roedel
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

2021-03-16 Thread Joerg Roedel
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

2021-03-16 Thread Joerg Roedel
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

2021-03-05 Thread Joerg Roedel
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

2021-03-04 Thread Joerg Roedel
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

2021-03-04 Thread Joerg Roedel
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

2021-03-04 Thread Joerg Roedel
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()

2021-03-04 Thread Joerg Roedel
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

2021-03-04 Thread Joerg Roedel
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

2021-02-22 Thread Joerg Roedel
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

2021-02-12 Thread Joerg Roedel
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

2021-02-12 Thread Joerg Roedel
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

2021-02-08 Thread Joerg Roedel
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()

2021-02-08 Thread Joerg Roedel
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

2021-02-05 Thread Joerg Roedel
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

2021-02-05 Thread Joerg Roedel
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

2021-02-05 Thread Joerg Roedel
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

2021-02-04 Thread Joerg Roedel
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

2021-02-04 Thread Joerg Roedel
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

2021-02-04 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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]

2021-02-02 Thread Joerg Roedel
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

2021-02-02 Thread Joerg Roedel
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

2021-01-29 Thread Joerg Roedel
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

2021-01-29 Thread Joerg Roedel
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

2021-01-29 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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()

2021-01-28 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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

2021-01-28 Thread Joerg Roedel
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

2021-01-27 Thread Joerg Roedel
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


  1   2   3   4   5   6   7   8   9   10   >