Re: [PATCH v12 0/2] iommu/mediatek: TTBR up to 35bit support
On Wed, Jul 06, 2022 at 12:50:31PM +0100, Will Deacon wrote: > On Thu, Jun 30, 2022 at 05:29:24PM +0800, yf.w...@mediatek.com wrote: > > This patchset adds MediaTek TTBR up to 35bit support for single normal zone. > > > > Changes in v12: > > - Update [PATCH 1/2]: remove GENMASK(31, 7) > > - Update [PATCH 2/2]: remove MMU_PT_ADDR_MASK definition. > > For both patches: > > Acked-by: Will Deacon > > Joerg -- please can you pick these up for 5.20? Applied to arm/mediatek, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 RESEND 00/35] iommu/amd: Add multiple PCI segments support
On Wed, Jul 06, 2022 at 05:07:50PM +0530, Vasant Hegde wrote:
>As discussed in other thread, I have updated "From:" tag and
>resending patchset. No changes in the actual patch content.
>This patchset is based on top on "iommu/x86/amd" branch.
>Base commit : 0d10fe75911787 ("iommu/amd: Use try_cmpxchg64 in ")
Replaced it in my tree, thanks. I now also added a hook calling
checkpatch, which should catch such problems before I push the tree out.
Thanks,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Handle return of iommu_device_sysfs_add
On Fri, Jul 01, 2022 at 02:20:08AM -0400, Bo Liu wrote: > As iommu_device_sysfs_add() can fail, we should check the return value. > > Signed-off-by: Bo Liu > --- > drivers/iommu/amd/init.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/iova: change IOVA_MAG_SIZE to 127 to save memory
On Sun, Jul 03, 2022 at 07:44:50PM +0800, Feng Tang wrote: > kmalloc will round up the request size to power of 2, and current > iova_magazine's size is 1032 (1024+8) bytes, so each instance > allocated will get 2048 bytes from kmalloc, causing around 1KB > waste. > > Change IOVA_MAG_SIZE from 128 to 127 to make size of 'iova_magazine' > 1024 bytes so that no memory will be wasted. > > Signed-off-by: Feng Tang > Acked-by: Robin Murphy Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/1] iommu/vt-d: Fixes for v5.19-rc4
On Sat, Jun 25, 2022 at 09:34:29PM +0800, Lu Baolu wrote: > Hi Joerg, > > One fix is queued for v5.19. It aims to fix: > > - RID2PASID setup/teardown failures for pci alias devices > > Please consider it for the iommu/fix branch. > > Best regards, > Lu Baolu > > Lu Baolu (1): > iommu/vt-d: Fix RID2PASID setup/teardown failure Queued, thanks Baolu and sorry for the delay. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/exynos: Make driver independent of the system page size
On Thu, Jun 23, 2022 at 11:36:29AM +0200, Marek Szyprowski wrote: > drivers/iommu/exynos-iommu.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/3] iommu: More internal ops cleanup
On Tue, Jun 21, 2022 at 04:14:24PM +0100, Robin Murphy wrote: > Robin Murphy (3): > iommu: Use dev_iommu_ops() for probe_finalize > iommu: Make .release_device optional > iommu: Clean up release_device checks Applied to core branch, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Fix PCI bus rescan device hot add
On Fri, Jun 24, 2022 at 02:12:28PM +0800, Baolu Lu wrote: > It makes sense as far as I am aware. By putting IOMMUs in pass-through > mode, there will be no run-time costs and things could be simplified a > lot. > > Besides the refactoring efforts, we still need this quick fix so that > the fix could be propagated to various stable and vendors' downstream trees. Patch is applied now for 5.19. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] MAINTAINERS: Remove iommu@lists.linux-foundation.org
From: Joerg Roedel The IOMMU mailing list has moved to io...@lists.linux.dev and the old list should bounce by now. Remove it from the MAINTAINERS file. Signed-off-by: Joerg Roedel --- MAINTAINERS | 11 --- 1 file changed, 11 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 66bffb24a348..ead381fdfc5a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -426,7 +426,6 @@ F: drivers/acpi/*thermal* ACPI VIOT DRIVER M: Jean-Philippe Brucker L: linux-a...@vger.kernel.org -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Maintained F: drivers/acpi/viot.c @@ -960,7 +959,6 @@ F: drivers/video/fbdev/geode/ AMD IOMMU (AMD-VI) M: Joerg Roedel R: Suravee Suthikulpanit -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git @@ -5979,7 +5977,6 @@ DMA MAPPING HELPERS M: Christoph Hellwig M: Marek Szyprowski R: Robin Murphy -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Supported W: http://git.infradead.org/users/hch/dma-mapping.git @@ -5992,7 +5989,6 @@ F:kernel/dma/ DMA MAPPING BENCHMARK M: Xiang Chen -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev F: kernel/dma/map_benchmark.c F: tools/testing/selftests/dma/ @@ -7577,7 +7573,6 @@ F:drivers/gpu/drm/exynos/exynos_dp* EXYNOS SYSMMU (IOMMU) driver M: Marek Szyprowski -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Maintained F: drivers/iommu/exynos-iommu.c @@ -,7 +9994,6 @@ F:drivers/hid/intel-ish-hid/ INTEL IOMMU (VT-d) M: David Woodhouse M: Lu Baolu -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git @@ -10379,7 +10373,6 @@ F: include/linux/iomap.h IOMMU DRIVERS M: Joerg Roedel M: Will Deacon -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git @@ -12539,7 +12532,6 @@ F: drivers/i2c/busses/i2c-mt65xx.c MEDIATEK IOMMU DRIVER M: Yong Wu -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Supported @@ -16591,7 +16583,6 @@ F: drivers/i2c/busses/i2c-qcom-cci.c QUALCOMM IOMMU M: Rob Clark -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev L: linux-arm-...@vger.kernel.org S: Maintained @@ -19217,7 +19208,6 @@ F: arch/x86/boot/video* SWIOTLB SUBSYSTEM M: Christoph Hellwig -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Supported W: http://git.infradead.org/users/hch/dma-mapping.git @@ -21893,7 +21883,6 @@ XEN SWIOTLB SUBSYSTEM M: Juergen Gross M: Stefano Stabellini L: xen-de...@lists.xenproject.org (moderated for non-subscribers) -L: iommu@lists.linux-foundation.org L: io...@lists.linux.dev S: Supported F: arch/x86/xen/*swiotlb* -- 2.36.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 0/7] iommu/amd: Add Generic IO Page Table Framework Support for v2 Page Table
On Tue, Jun 28, 2022 at 02:35:51PM +0530, Vasant Hegde wrote:
> Sorry. I didn't get last statement ("device identity maps DMA requests
> without PASID").
> Can you please elaborate?
When using v1 page-tables, each device supporting ATS/PRI/PASID needs to
be direct-mapped, because the v1 page-tables basically act as a stage-2
page table for the PASID ones.
But when the non-pasid case moves to the pasid==0 page-table, then there
is not stage-2 anymore and a device can be used with ATS/PRI/PASID while
non-PASID requests are translated too, no?
I didn't get how this is handled in the current patch-set.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 7/7] iommu/amd: Introduce amd_iommu_pgtable command-line option
On Tue, Jun 28, 2022 at 01:23:52PM +0530, Vasant Hegde wrote: > I think it will complicate the parsing logic. We do have `amd_iommu=off` > option. > How are we going to handle `amd_iommu=off,[pgtable_v1/v2]` ? In that case everything except 'off' will be ignored. The driver might set its internal variables, but this has no effect as the driver never initializes. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux v5.19-rc3
Hi Linus, The following changes since commit a111daf0c53ae91e71fd2bfe7497862d14132e3e: Linux 5.19-rc3 (2022-06-19 15:06:47 -0500) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.19-rc3 for you to fetch changes up to c242507c1b895646b4a25060df13b6214805759f: MAINTAINERS: Add new IOMMU development mailing list (2022-06-24 15:36:11 +0200) IOMMU Fixes for Linux v5.19-rc3 Including: - Add a new IOMMU mailing list to the MAINTAINERS file to prepare for the a list migration happening on July 5th. The old list needs to stay in place until the switch happens to guarantee seemless archiving of list email. - Fix compatible device-tree string for rcar-gen4 in Renesas IOMMU driver. Joerg Roedel (1): MAINTAINERS: Add new IOMMU development mailing list Yoshihiro Shimoda (1): iommu/ipmmu-vmsa: Fix compatible for rcar-gen4 MAINTAINERS| 11 +++ drivers/iommu/ipmmu-vmsa.c | 2 +- 2 files changed, 12 insertions(+), 1 deletion(-) 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 v2] iommu/dma: Add config for PCI SAC address trick
On Thu, Jun 23, 2022 at 12:41:00PM +0100, Robin Murphy wrote: > On 2022-06-23 12:33, Joerg Roedel wrote: > > On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote: > > > Thanks for your bravery! > > > > It already starts, with that patch I am getting: > > > > xhci_hcd :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT > > domain=0x000f address=0xff00ffefe000 flags=0x] > > > > In my kernel log. The device is an AMD XHCI controller and seems to > > funciton normally after boot. The message disappears with > > iommu.forcedac=0. > > > > Need to look more into that... > > Given how amd_iommu_domain_alloc() sets the domain aperture, presumably the > DMA address allocated was 0xffefe000? Odd that it gets bits punched > out in the middle rather than simply truncated off the top as I would have > expected :/ So even more weird, as a workaround I changed the AMD IOMMU driver to allocate a 4-level page-table and limit the DMA aperture to 48 bits. I still get the same message. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] MAINTAINERS: Add new IOMMU development mailing list
On Fri, Jun 24, 2022 at 05:59:39AM -0700, Christoph Hellwig wrote: > Shouldn't this also remove the old list given it has only a few days > to live? No, the new list is not yet archived on lore. There will be a hard switch of the archive on July 5th, and after that the old list can be removed. Regards, -- Jörg Rödel jroe...@suse.de SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] MAINTAINERS: Add new IOMMU development mailing list
From: Joerg Roedel The IOMMU mailing list will move from lists.linux-foundation.org to lists.linux.dev. The hard switch of the archive will happen on July 5th, but add the new list now already so that people start using the list when sending patches. After July 5th the old list will disappear. Cc: sta...@vger.kernel.org Signed-off-by: Joerg Roedel --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3cf9842d9233..36d1bc999815 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -427,6 +427,7 @@ ACPI VIOT DRIVER M: Jean-Philippe Brucker L: linux-a...@vger.kernel.org L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Maintained F: drivers/acpi/viot.c F: include/linux/acpi_viot.h @@ -960,6 +961,7 @@ AMD IOMMU (AMD-VI) M: Joerg Roedel R: Suravee Suthikulpanit L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git F: drivers/iommu/amd/ @@ -5962,6 +5964,7 @@ M:Christoph Hellwig M: Marek Szyprowski R: Robin Murphy L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Supported W: http://git.infradead.org/users/hch/dma-mapping.git T: git git://git.infradead.org/users/hch/dma-mapping.git @@ -5974,6 +5977,7 @@ F:kernel/dma/ DMA MAPPING BENCHMARK M: Xiang Chen L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev F: kernel/dma/map_benchmark.c F: tools/testing/selftests/dma/ @@ -7558,6 +7562,7 @@ F:drivers/gpu/drm/exynos/exynos_dp* EXYNOS SYSMMU (IOMMU) driver M: Marek Szyprowski L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Maintained F: drivers/iommu/exynos-iommu.c @@ -9977,6 +9982,7 @@ INTEL IOMMU (VT-d) M: David Woodhouse M: Lu Baolu L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git F: drivers/iommu/intel/ @@ -10356,6 +10362,7 @@ IOMMU DRIVERS M: Joerg Roedel M: Will Deacon L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git F: Documentation/devicetree/bindings/iommu/ @@ -12504,6 +12511,7 @@ F: drivers/i2c/busses/i2c-mt65xx.c MEDIATEK IOMMU DRIVER M: Yong Wu L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/iommu/mediatek* @@ -16545,6 +16553,7 @@ F: drivers/i2c/busses/i2c-qcom-cci.c QUALCOMM IOMMU M: Rob Clark L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev L: linux-arm-...@vger.kernel.org S: Maintained F: drivers/iommu/arm/arm-smmu/qcom_iommu.c @@ -19170,6 +19179,7 @@ F: arch/x86/boot/video* SWIOTLB SUBSYSTEM M: Christoph Hellwig L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Supported W: http://git.infradead.org/users/hch/dma-mapping.git T: git git://git.infradead.org/users/hch/dma-mapping.git @@ -21844,6 +21854,7 @@ M: Juergen Gross M: Stefano Stabellini L: xen-de...@lists.xenproject.org (moderated for non-subscribers) L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Supported F: arch/x86/xen/*swiotlb* F: drivers/xen/*swiotlb* -- 2.36.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] MAINTAINERS: Add new IOMMU development mailing list
On Thu, Jun 23, 2022 at 11:30:06PM -0700, Christoph Hellwig wrote: > iommu@lists.linux-foundation.org is also listed for various other > MAINTAINERS entries. Can you please send a list to update all of them > to Linus ASAP, including for 5.19 and -stable? Right, will do, thanks for the heads-up. -- Jörg Rödel jroe...@suse.de SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/vt-d: Fix PCI bus rescan device hot add
Hi Baolu, On Wed, May 25, 2022 at 09:40:26AM +0800, Baolu Lu wrote: > How do you like it? If you agree, I can queue it in my next pull request > for fixes. Would it help to tie DMAR and IOMMU components together, so that selecting DMAR for IRQ remapping also selects IOMMU? The IOMMU can be in PT mode and I think it would simplify a lot of things. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/dma: Add config for PCI SAC address trick
On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote: > Thanks for your bravery! It already starts, with that patch I am getting: xhci_hcd :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000f address=0xff00ffefe000 flags=0x] In my kernel log. The device is an AMD XHCI controller and seems to funciton normally after boot. The message disappears with iommu.forcedac=0. Need to look more into that... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 3/7] iommu/amd: Fix sparse warning
On Thu, Jun 23, 2022 at 10:42:52AM +0100, Robin Murphy wrote: > TBH it's probably time to retire iommu_ops->pgsize_bitmap anyway. At the > very least it would be logical to move it to iommu_domain_ops now, but maybe > we could skip ahead and just rely on drivers initialising > domain->pgsize_bitmap directly in their .domain_alloc? > > (and FWIW I'm leaning towards the same for the domain->ops as well; the more > I look at ops->default_domain_ops, the more it starts looking like a stupid > mess... my stupid mess... sorry about that) Good idea, that would be even better. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 7/7] iommu/amd: Do not support IOMMUv2 APIs when SNP is enabled
On Wed, Jun 22, 2022 at 12:11:31PM -0500, Suravee Suthikulpanit wrote:
> bool amd_iommu_v2_supported(void)
> {
> - return amd_iommu_v2_present;
> + /*
> + * Since DTE[Mode]=0 is prohibited on SNP-enabled system
> + * (i.e. EFR[SNPSup]=1), IOMMUv2 page table cannot be used without
> + * setting up IOMMUv1 page table.
> + */
> + return amd_iommu_v2_present && !amd_iommu_snp_en;
IOMMU_v2 APIs could actually be supported with GIOV and IOMMUv2
page-tables in-use, no?
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 1/7] iommu/amd: Warn when found inconsistency EFR mask
On Wed, Jun 22, 2022 at 12:11:25PM -0500, Suravee Suthikulpanit wrote:
> #ifdef CONFIG_IRQ_REMAP
> +/*
> + * Iterate through all the IOMMUs to verify if the specified
> + * EFR bitmask of IOMMU feature are set.
> + * Warn and return false if found inconsistency.
> + */
> static bool check_feature_on_all_iommus(u64 mask)
> {
> bool ret = false;
> struct amd_iommu *iommu;
>
> for_each_iommu(iommu) {
> - ret = iommu_feature(iommu, mask);
> - if (!ret)
> + bool tmp = iommu_feature(iommu, mask);
> +
> + if ((ret != tmp) &&
> + !list_is_first(&iommu->list, &amd_iommu_list)) {
> + pr_err(FW_BUG "Found inconsistent EFR mask (%#llx) on
> iommu%d (%04x:%02x:%02x.%01x).\n",
> +mask, iommu->index, iommu->pci_seg->id,
> PCI_BUS_NUM(iommu->devid),
> +PCI_SLOT(iommu->devid), PCI_FUNC(iommu->devid));
> return false;
> + }
> + ret = tmp;
It is better to implement this by introducing a global feature mask,
which represents the minial set of features supported by any IOMMU in
the system.
The warning is then something like:
if ((global_feature_mask & iommu_features) != global_feature_mask)
pr_warn(...);
This also makes the global variable to track SNP support obsolete.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 0/7] iommu/amd: Add Generic IO Page Table Framework Support for v2 Page Table
On Fri, Jun 03, 2022 at 04:51:00PM +0530, Vasant Hegde wrote: > - Part 1 (patch 1-4 and 6) > Refactor the current IOMMU page table code to adopt the generic IO page > table framework, and add AMD IOMMU Guest (v2) page table management code. > > - Part 2 (patch 5) > Add support for the AMD IOMMU Guest IO Protection feature (GIOV) > where requests from the I/O device without a PASID are treated as > if they have PASID of 0. > > - Part 3 (patch 7) > Introduce new "amd_iommu_pgtable" command-line to allow users > to select the mode of operation (v1 or v2). Something I didn't get entirely from the review is support level of the amd_iommu_v2 driver. I think it will continue to work and the requirement that the device identity maps DMA requests without PASID is removed, right? Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 7/7] iommu/amd: Introduce amd_iommu_pgtable command-line option
On Fri, Jun 03, 2022 at 04:51:07PM +0530, Vasant Hegde wrote: > + 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 > + Can we handle this somehow in the amd_iommu= option? Something like amd_iommu=pgtbl_v2|pgtbl_v1? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 4/7] iommu/amd: Initial support for AMD IOMMU v2 page table
On Fri, Jun 03, 2022 at 04:51:04PM +0530, Vasant Hegde wrote:
> +/* Allocate page table */
> +static u64 *v2_alloc_pte(u64 *pgd, unsigned long iova,
> + unsigned long pg_size, bool *updated)
> +{
> + u64 *pte, *page;
> + int level, end_level;
> +
> + BUG_ON(!is_power_of_2(pg_size));
> +
> + level = get_pgtable_level() - 1;
> + end_level = page_size_to_level(pg_size);
> + pte = &pgd[PM_LEVEL_INDEX(level, iova)];
> + iova = PAGE_SIZE_ALIGN(iova, PAGE_SIZE);
> +
> + while (level >= end_level) {
> + u64 __pte, __npte;
> +
> + __pte = *pte;
> +
> + if (IOMMU_PTE_PRESENT(__pte) && is_large_pte(__pte)) {
> + /* Unmap large pte */
> + cmpxchg64(pte, *pte, 0ULL);
> + *updated = true;
> + continue;
> + }
> +
> + if (!IOMMU_PTE_PRESENT(__pte)) {
> + page = alloc_pgtable_page();
> + if (!page)
> + return NULL;
> +
> + __npte = set_pgtable_attr(page);
> + /* pte could have been changed somewhere. */
> + if (cmpxchg64(pte, __pte, __npte) != __pte)
> + free_pgtable_page(page);
> + else if (IOMMU_PTE_PRESENT(__pte))
> + *updated = true;
> +
> + continue;
> + }
> +
> + level -= 1;
> + pte = get_pgtable_pte(__pte);
> + pte = &pte[PM_LEVEL_INDEX(level, iova)];
> + }
I know that the V1 page-table code also uses loops for the allocation
path, but the main reason there is the variable amount of page-table
levels. The v2 page-tables have a fixed amount levels, so it is better
to unroll this loop here (and other loops iterating over page-table
levels). This makes the code more clear.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 3/7] iommu/amd: Fix sparse warning
On Fri, Jun 03, 2022 at 04:51:03PM +0530, Vasant Hegde wrote: > Fix below sparse warning: > CHECK drivers/iommu/amd/iommu.c > drivers/iommu/amd/iommu.c:73:24: warning: symbol 'amd_iommu_ops' was not > declared. Should it be static? > > Also we are going to introduce v2 page table which has different > pgsize_bitmaps. Hence remove 'const' qualifier. I am not a fan of removing the consts. Please use separate ops structures for v2 page-tables and make then const as well. This probably also has some optimization potential in the future when we can make the ops call-back functions page-table specific. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 00/35] iommu/amd: Add multiple PCI segments support
Hi Vasant, On Wed, May 11, 2022 at 12:51:06PM +0530, Vasant Hegde wrote: > .../admin-guide/kernel-parameters.txt | 34 +- > drivers/iommu/amd/amd_iommu.h | 13 +- > drivers/iommu/amd/amd_iommu_types.h | 133 +++- > drivers/iommu/amd/init.c | 687 +++--- > drivers/iommu/amd/iommu.c | 563 -- > drivers/iommu/amd/iommu_v2.c | 67 +- > drivers/iommu/amd/quirks.c| 4 +- > 7 files changed, 904 insertions(+), 597 deletions(-) So this is applied now to the IOMMU tree, thanks for the work. Something that bothered me while looking at this was the almost complete lack of locking while accessing the global data structures. Some of them are lock-less, so it is partially fine, and most of them are used read-only during system runtime. But I would appreciate if you and/or Suravee could look over that again and check again if there needs to be more locking. The current situation will fire back at the point where you want to implement IOMMU hotplug. Note that device hotplug is already possible today, either with real devices or SR-IOV. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Use try_cmpxchg64 in alloc_pte and free_clear_pte
On Wed, May 25, 2022 at 04:54:16PM +0200, Uros Bizjak wrote: > Use try_cmpxchg64 instead of cmpxchg64 (*ptr, old, new) != old in > alloc_pte and free_clear_pte. cmpxchg returns success in ZF flag, so this > change saves a compare after cmpxchg (and related move instruction > in front of cmpxchg). Also, remove racy explicit assignment to pteval > when cmpxchg fails, this is what try_cmpxchg does implicitly from > *pte in an atomic way. > > Signed-off-by: Uros Bizjak > Cc: Joerg Roedel > Cc: Suravee Suthikulpanit > Cc: Will Deacon > --- > drivers/iommu/amd/io_pgtable.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 0/5] mtk_iommu: Specify phandles to infracfg and pericfg
Hi Matthias, On Wed, Jun 22, 2022 at 04:12:47PM +0200, Matthias Brugger wrote: > I wanted to check if you took also 3 and 4, as these should go through my > tree. Unfortunately you haven't pushed your tree (yet). In case you took the > whole series, can you please drop the dts patches. I'll apply them now on my > v5.19-next/dts64 branch. Yes, I applied the whole series, will drop patches 3 and 4 now. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/ipmmu-vmsa: Fix compatible for rcar-gen4
On Fri, Jun 17, 2022 at 10:01:07AM +0900, Yoshihiro Shimoda wrote:
> Fix compatible string for R-Car Gen4.
>
> Fixes: ae684caf465b ("iommu/ipmmu-vmsa: Add support for R-Car Gen4")
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/iommu/ipmmu-vmsa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied for 5.19, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 0/5] mtk_iommu: Specify phandles to infracfg and pericfg
On Thu, Jun 16, 2022 at 01:08:25PM +0200, AngeloGioacchino Del Regno wrote: > AngeloGioacchino Del Regno (5): > dt-bindings: iommu: mediatek: Add mediatek,infracfg phandle > iommu/mediatek: Lookup phandle to retrieve syscon to infracfg > arm64: dts: mediatek: mt8173: Add mediatek,infracfg phandle for IOMMU > arm64: dts: mediatek: mt2712e: Add mediatek,infracfg phandle for IOMMU > iommu/mediatek: Cleanup pericfg lookup flow > > .../bindings/iommu/mediatek,iommu.yaml| 17 +++ > arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 2 + > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 1 + > drivers/iommu/mtk_iommu.c | 50 +++ > 4 files changed, 49 insertions(+), 21 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: Remove usage of the deprecated ida_simple_xxx API
On Thu, Jun 16, 2022 at 10:05:55PM -0400, Bo Liu wrote: > Use ida_alloc_xxx()/ida_free() instead of > ida_simple_get()/ida_simple_remove(). > The latter is deprecated and more verbose. > > Signed-off-by: Bo Liu > --- > drivers/iommu/iommu.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Sorry, just applied this similar change: https://lore.kernel.org/r/20220608021655.1538087-1-liuk...@huawei.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: Fix race condition during iova_domain initialization
On Wed, Jun 22, 2022 at 02:27:57PM +0100, Robin Murphy wrote: > Apologies, I did spot this before, I've just been tied up with other things > and dropping everything non-critical on the floor, so didn't get round to > replying before it slipped my mind again. > > In summary, I hate it, but mostly because the whole situation of calling > iommu_probe_device off the back of driver probe is fundamentally broken. I'm > still a few steps away from fixing that properly, at which point I can just > as well rip all these little bodges out again. If it really does need > mitigating in the meantime (i.e. this is real-world async probe, not just > some contrived testcase), then I can't easily think of any cleaner hack, so, > > Acked-by: Robin Murphy Alright, applied this now. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/dma: Add config for PCI SAC address trick
On Thu, Jun 09, 2022 at 04:12:10PM +0100, Robin Murphy wrote: > firmware bindings by now. Let's be brave and default it to off in the I don't have an overall good feeling about this, but as you said, let's be brave. This is applied now to the core branch. If it causes too much trouble we can still revert it (and re-revert it later, ...) Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu: Directly use ida_alloc()/free()
On Wed, Jun 08, 2022 at 02:16:55AM +, Ke Liu wrote: > Use ida_alloc()/ida_free() instead of deprecated > ida_simple_get()/ida_simple_remove(). > > Signed-off-by: Ke Liu > Reviewed-by: Jason Gunthorpe > Signed-off-by: Michael S. Tsirkin > --- > v2 subject change to iommu > --- > drivers/iommu/iommu.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: Fix race condition during iova_domain initialization
Please re-send with
Robin Murphy
in Cc.
On Mon, May 30, 2022 at 08:07:45PM +0800, yf.w...@mediatek.com wrote:
> From: Yunfei Wang
>
> When many devices share the same iova domain, iommu_dma_init_domain()
> may be called at the same time. The checking of iovad->start_pfn will
> all get false in iommu_dma_init_domain() and both enter init_iova_domain()
> to do iovad initialization.
>
> Fix this by protecting init_iova_domain() with iommu_dma_cookie->mutex.
>
> Exception backtrace:
> rb_insert_color(param1=0xFF80CD2BDB40, param3=1) + 64
> init_iova_domain() + 180
> iommu_setup_dma_ops() + 260
> arch_setup_dma_ops() + 132
> of_dma_configure_id() + 468
> platform_dma_configure() + 32
> really_probe() + 1168
> driver_probe_device() + 268
> __device_attach_driver() + 524
> __device_attach() + 524
> bus_probe_device() + 64
> deferred_probe_work_func() + 260
> process_one_work() + 580
> worker_thread() + 1076
> kthread() + 332
> ret_from_fork() + 16
>
> Signed-off-by: Ning Li
> Signed-off-by: Yunfei Wang
> ---
> drivers/iommu/dma-iommu.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 09f6e1c0f9c0..b38c5041eeab 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -63,6 +63,7 @@ struct iommu_dma_cookie {
>
> /* Domain for flush queue callback; NULL if flush queue not in use */
> struct iommu_domain *fq_domain;
> + struct mutexmutex;
> };
>
> static DEFINE_STATIC_KEY_FALSE(iommu_deferred_attach_enabled);
> @@ -309,6 +310,7 @@ int iommu_get_dma_cookie(struct iommu_domain *domain)
> if (!domain->iova_cookie)
> return -ENOMEM;
>
> + mutex_init(&domain->iova_cookie->mutex);
> return 0;
> }
>
> @@ -549,26 +551,33 @@ static int iommu_dma_init_domain(struct iommu_domain
> *domain, dma_addr_t base,
> }
>
> /* start_pfn is always nonzero for an already-initialised domain */
> + mutex_lock(&cookie->mutex);
> if (iovad->start_pfn) {
> if (1UL << order != iovad->granule ||
> base_pfn != iovad->start_pfn) {
> pr_warn("Incompatible range for DMA domain\n");
> - return -EFAULT;
> + ret = -EFAULT;
> + goto done_unlock;
> }
>
> - return 0;
> + ret = 0;
> + goto done_unlock;
> }
>
> init_iova_domain(iovad, 1UL << order, base_pfn);
> ret = iova_domain_init_rcaches(iovad);
> if (ret)
> - return ret;
> + goto done_unlock;
>
> /* If the FQ fails we can simply fall back to strict mode */
> if (domain->type == IOMMU_DOMAIN_DMA_FQ && iommu_dma_init_fq(domain))
> domain->type = IOMMU_DOMAIN_DMA;
>
> - return iova_reserve_iommu_regions(dev, domain);
> + ret = iova_reserve_iommu_regions(dev, domain);
> +
> +done_unlock:
> + mutex_unlock(&cookie->mutex);
> + return ret;
> }
>
> /**
> --
> 2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] MAINTAINERS: Add new IOMMU development mailing list
From: Joerg Roedel The IOMMU mailing list will move from lists.linux-foundation.org to lists.linux.dev. The hard switch of the archive will happen on July 5th, but add the new list now already so that people start using the list when sending patches. Signed-off-by: Joerg Roedel --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1fc9ead83d2a..b5bac297d63d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10354,6 +10354,7 @@ IOMMU DRIVERS M: Joerg Roedel M: Will Deacon L: iommu@lists.linux-foundation.org +L: io...@lists.linux.dev S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git F: Documentation/devicetree/bindings/iommu/ -- 2.36.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] drivers: iommu: Directly use ida_alloc()/free()
On Fri, May 27, 2022 at 07:03:07AM +, keliu wrote: > Use ida_alloc()/ida_free() instead of deprecated > ida_simple_get()/ida_simple_remove() . > > Signed-off-by: keliu Please change the subject to: "iommu: Directly use ida_alloc()/free()" to match the IOMMU tree conventions. Also include all acks and reviewed-by tags when re-sending. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/amd: Set translation valid bit only when IO page tables are in used
On Thu, May 26, 2022 at 10:29:09AM +0700, Suravee Suthikulpanit wrote: > Actually, I am referring to when user uses the IOMMU v2 table for shared > virtual address > in current iommu_v2 driver (e.g. amd_iommu_init_device(), > amd_iommu_bind_pasid). >From what I can see this is not handled yet and needs an additional check. I think the best solution is to set iommu->iommu_v2 to false when the SNP feature bit is set. But that is probably not enough, all functions that are called from the IOMMUv2 driver need to fail. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Updates for Linux v5.19
Hi Linus, Apologies for the late pull request, I know you prefer the main stuff in the first week. Some vacation and a public holiday came in between here. So here are the IOMMU updates for 5.19. Some patches are probably arleady merged via the VFIO tree, namely everyting from the vfio-notifier-fix topic branch. Also, there will be a merge conflict in MAINTAINERS and drivers/iommu/amd/iommu.c. The latter one is resolved by removing the function in question, for the former I attached my resolution. With that in mind: The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v5.19 for you to fetch changes up to b0dacee202efbf1a5d9f5cdfd82049e8b5b085d2: Merge branches 'apple/dart', 'arm/mediatek', 'arm/msm', 'arm/smmu', 'ppc/pamu', 'x86/vt-d', 'x86/amd' and 'vfio-notifier-fix' into next (2022-05-20 12:27:17 +0200) IOMMU Updates for Linux v5.19 Including: - Intel VT-d driver updates - Domain force snooping improvement. - Cleanups, no intentional functional changes. - ARM SMMU driver updates - Add new Qualcomm device-tree compatible strings - Add new Nvidia device-tree compatible string for Tegra234 - Fix UAF in SMMUv3 shared virtual addressing code - Force identity-mapped domains for users of ye olde SMMU legacy binding - Minor cleanups - Patches to fix a BUG_ON in the vfio_iommu_group_notifier - Groundwork for upcoming iommufd framework - Introduction of DMA ownership so that an entire IOMMU group is either controlled by the kernel or by user-space - MT8195 and MT8186 support in the Mediatek IOMMU driver - Patches to make forcing of cache-coherent DMA more coherent between IOMMU drivers - Fixes for thunderbolt device DMA protection - Various smaller fixes and cleanups Bjorn Andersson (2): dt-bindings: arm-smmu: Add compatible for Qualcomm SC8280XP iommu/arm-smmu-qcom: Add SC8280XP support Christophe Leroy (1): iommu/fsl_pamu: Prepare cleanup of powerpc's asm/prom.h Jason Gunthorpe (5): vfio: Delete the unbound_list iommu: Introduce the domain op enforce_cache_coherency() vfio: Move the Intel no-snoop control off of IOMMU_CACHE iommu: Redefine IOMMU_CAP_CACHE_COHERENCY as the cap flag for IOMMU_CACHE vfio: Require that devices support DMA cache coherence Jason Gunthorpe via iommu (1): iommu: iommu_group_claim_dma_owner() must always assign a domain Jean-Philippe Brucker (1): iommu/arm-smmu-v3-sva: Fix mm use-after-free Joerg Roedel (4): Merge tag 'arm-smmu-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/smmu iommu/amd: Increase timeout waiting for GA log enablement Merge tag 'v5.18-rc7' into arm/smmu Merge branches 'apple/dart', 'arm/mediatek', 'arm/msm', 'arm/smmu', 'ppc/pamu', 'x86/vt-d', 'x86/amd' and 'vfio-notifier-fix' into next Lu Baolu (17): iommu: Add DMA ownership management interfaces driver core: Add dma_cleanup callback in bus_type amba: Stop sharing platform_dma_configure() bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management PCI: pci_stub: Set driver_managed_dma PCI: portdrv: Set driver_managed_dma vfio: Set DMA ownership for VFIO devices vfio: Remove use of vfio_group_viable() vfio: Remove iommu group notifier iommu: Remove iommu group changes notifier iommu/vt-d: Change return type of dmar_insert_one_dev_info() iommu/vt-d: Fold dmar_insert_one_dev_info() into its caller iommu/vt-d: Size Page Request Queue to avoid overflow condition iommu/vt-d: Block force-snoop domain attaching if no SC support iommu/vt-d: Check domain force_snooping against attached devices iommu/vt-d: Remove domain_update_iommu_snooping() iommu/vt-d: Remove hard coding PGSNP bit in PASID entries Mario Limonciello (3): iommu/amd: Enable swiotlb in all cases dma-iommu: Check that swiotlb is active before trying to use it iommu/amd: Indicate whether DMA remap support is enabled Matthew Rosato (1): iommu/s390: Tolerate repeat attach_dev calls Miles Chen (1): iommu/mediatek: Fix NULL pointer dereference when printing dev_name Muhammad Usama Anjum (1): iommu/vt-d: Remove unneeded validity check on dev Rob Herring (1): dt-bindings: iommu: Drop client no
[PATCH] iommu/amd: Increase timeout waiting for GA log enablement
From: Joerg Roedel
On some systems it can take a long time for the hardware to enable the
GA log of the AMD IOMMU. The current wait time is only 0.1ms, but
testing showed that it can take up to 14ms for the GA log to enter
running state after it has been enabled.
Sometimes the long delay happens when booting the system, sometimes
only on resume. Adjust the timeout accordingly to not print a warning
when hardware takes a longer than usual.
There has already been an attempt to fix this with commit
9b45a7738eec ("iommu/amd: Fix loop timeout issue in
iommu_ga_log_enable()")
But that commit was based on some wrong math and did not fix the issue
in all cases.
Cc: "D. Ziegfeld"
Cc: Jörg-Volker Peetz
Fixes: 8bda0cfbdc1a ("iommu/amd: Detect and initialize guest vAPIC log")
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index b4a798c7b347..d8060503ba51 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -84,7 +84,7 @@
#define ACPI_DEVFLAG_LINT1 0x80
#define ACPI_DEVFLAG_ATSDIS 0x1000
-#define LOOP_TIMEOUT 10
+#define LOOP_TIMEOUT 200
/*
* ACPI table definitions
*
--
2.36.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 00/35] iommu/amd: Add multiple PCI segments support
Hi Vasant, On Fri, May 20, 2022 at 03:25:38PM +0530, Vasant Hegde wrote: > Ping. Did you get a chance to look into this series? Sorry, too late for this round. The changes are pretty invasive and merging them at -rc7 stage would not give them enough testing before being merged. Please send me a reminder after the next merge window. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/amd: Set translation valid bit only when IO page tables are in used
On Fri, May 20, 2022 at 09:54:51AM +0100, Robin Murphy wrote: > The .def_domain type op already allows drivers to do exactly this sort of > override. You could also conditionally reject IOMMU_DOMAIN_PASSTHROUGH in > .domain_alloc for good measure, provided that (for now at least*) SNP is a > global thing rather than per-instance. Yeah, that could work. I am just not sure the IOMMU core behaves well in all situations when allocation IOMMU_DOMAIN_PASSTHROUGH suddenly starts to fail. I would feel better if this is checked and tested :) Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH] dma-iommu: Add iommu_dma_max_mapping_size()
On Wed, May 18, 2022 at 03:13:53PM +0200, Christoph Hellwig wrote: > On Tue, May 17, 2022 at 01:02:00PM +0100, Robin Murphy wrote: > >> So how to inform the SCSI driver of this caching limit then so that it may > >> limit the SGL length? > > > > Driver-specific mechanism; block-layer-specific mechanism; redefine this > > whole API to something like dma_opt_mapping_size(), as a limit above which > > mappings might become less efficient or start to fail (callback to my > > thoughts on [1] as well, I suppose); many options. Just not imposing a > > ridiculously low *maximum* on everyone wherein mapping calls "should not be > > larger than the returned value" when that's clearly bollocks. > > Well, for swiotlb it is a hard limit. So if we want to go down that > route we need two APIs, one for the optimal size and one for the > hard limit. I agree with Robin, and if it really helps some drivers I am all for doing a dma_opt_mapping_size() instead. Limiting DMA mapping sizes to make drivers perform better gets a clear NAK from my side. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/5] iommu: Add blocking_domain_ops field in iommu_ops
On Mon, May 16, 2022 at 09:57:56AM +0800, Lu Baolu wrote: > const struct iommu_domain_ops *default_domain_ops; > + const struct iommu_domain_ops *blocking_domain_ops; I don't understand why extra domain-ops are needed for this. I think it would be more straight-forward to implement allocation of IOMMU_DOMAIN_BLOCKED domains in each driver and let the details be handled in the set_dev() call-back. The IOMMU driver can make sure DMA is blocked for a device when it encounters a IOMMU_DOMAIN_BLOCKED domain. For IOMMUs that have no explicit way to block DMA could just use an unmanaged domain with an empty page-table. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/amd: Set translation valid bit only when IO page tables are in used
Hi Suravee, On Mon, May 16, 2022 at 07:27:51PM +0700, Suravee Suthikulpanit wrote: > Due to the new restriction (please see the IOMMU spec Rev 3.06-PUB - Apr 2021 > https://www.amd.com/system/files/TechDocs/48882_IOMMU.pdf) where the use of > DTE[Mode]=0 is not supported on systems that are SNP-enabled (i.e. > EFR[SNPSup]=1), > the IOMMU HW looks at the DTE[TV] bit to determine if it needs to handle the > v1 page table. > When the HW encounters DTE entry with TV=1, V=1, Mode=0, it would generate > ILLEGAL_DEV_TABLE_ENTRY event. Ah, that is the part I was missing, thanks. > - I am still trying to see what is the best way to force Linux to not allow > Mode=0 (i.e. iommu=pt mode). Any thoughts? I think this needs a general approach. First start in the AMD IOMMU driver: 1) Do not set DTE.TV=1 bit iff SNP-Support is enabled 2) Fail to allocate passthrough domains when SNP support is enabled. Then test how the IOMMU core layer handles that. In fact the IOMMU layer needs to adjust its decisions so that: 1) It uses translated-mode by default 2) passthrough domains are disallowed and can not be chosen, not on the kernel command line and not at runtime. Ideally this needs some kind of arch-callback to set the appropriate defaults. > - Also, it seems that the current iommu v2 page table use case, where > GVA->GPA=SPA > will no longer be supported on system w/ SNPSup=1. Any thoughts? Support for that is not upstream yet, it should be easy to disallow this configuration and just use the v1 page-tables when SNP is active. This can be handled entirely inside the AMD IOMMU driver. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/s390: tolerate repeat attach_dev calls
On Thu, May 19, 2022 at 02:29:29PM -0400, Matthew Rosato wrote:
> Since commit 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must
> always assign a domain") s390-iommu will get called to allocate multiple
> unmanaged iommu domains for a vfio-pci device -- however the current
> s390-iommu logic tolerates only one. Recognize that multiple domains can
> be allocated and handle switching between DMA or different iommu domain
> tables during attach_dev.
>
> Signed-off-by: Matthew Rosato
> ---
> drivers/iommu/s390-iommu.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
Applied to the vfio-notifier-fix topic branch, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] vfio: Remove VFIO_TYPE1_NESTING_IOMMU
On Tue, May 17, 2022 at 02:26:56PM -0600, Alex Williamson wrote: > I'd be in favor of applying this, but it seems Robin and Eric are > looking for a stay of execution and I'd also be looking for an ack from > Joerg. Thanks, This is mainly an ARM-SMMU thing, so I defer my ack to Will and Robin. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu: iommu_group_claim_dma_owner() must always assign a domain
On Wed, May 18, 2022 at 04:14:46PM -0300, Jason Gunthorpe wrote:
> Fixes: 0286300e6045 ("iommu: iommu_group_claim_dma_owner() must always assign
> a domain")
> Reported-by: Eric Farman
> Signed-off-by: Jason Gunthorpe
> ---
> drivers/vfio/vfio.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
That fix will be taken care of by Alex? Or does it need to go through
the IOMMU tree?
Regards,
--
Jörg Rödel
jroe...@suse.de
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RESEND PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
Hi Alex, On Wed, May 04, 2022 at 10:29:56AM -0600, Alex Williamson wrote: > Done, and thanks for the heads-up. Please try to cc me when the > vfio-notifier-fix branch is merged back into your next branch. Thanks, This has happened now, the vfio-notifier-fix branch got the fix and is merged back into my next branch. 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.19
On Tue, May 10, 2022 at 05:01:06PM +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 0/8] [PULL REQUEST] Intel IOMMU updates for Linux v5.19
On Tue, May 10, 2022 at 10:33:59AM +0800, Lu Baolu wrote: > This includes patches queued for v5.19. It includes: > > - Domain force snooping improvement. > - Cleanups, no intentional functional changes. > > Please consider them for v5.19. > > [This series cannot be directly applied to vt-d branch. Some domain > force snooping patches have been merged on the core branch. You may > also need to add those patches to the vt-d branch, or just merge > this series into the core branch.] Alright, merged the core branch into x86/vt-d and applied these patches on-top. Thanks Baolu. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/dma: Explicitly sort PCI DMA windows
On Mon, May 09, 2022 at 11:16:08AM +0100, Robin Murphy wrote: > drivers/iommu/dma-iommu.c | 13 - > drivers/pci/of.c | 8 +--- > 2 files changed, 13 insertions(+), 8 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/amd: Set translation valid bit only when IO page tables are in used
On Mon, May 09, 2022 at 02:48:15AM -0500, Suravee Suthikulpanit wrote: > On AMD system with SNP enabled, IOMMU hardware checks the host translation > valid (TV) and guest translation valid (GV) bits in the device > table entry (DTE) before accessing the corresponded page tables. > > However, current IOMMU driver sets the TV bit for all devices > regardless of whether the host page table is in used. > This results in ILLEGAL_DEV_TABLE_ENTRY event for devices, which > do not the host page table root pointer set up. Hmm, this sound weird. In the early AMD IOMMUs it was recommended to set TV=1 and V=1 and the rest to 0 to block all DMA from a device. I wonder how this triggers ILLEGAL_DEV_TABLE_ENTRY errors now. It is (was?) legal to set V=1 TV=1, mode=0 and leave the page-table empty. When then IW=0 and IR=0, DMA is blocked. From what I remember this is a valid setting in a DTE. Do you have an example DTE which triggers this error message? Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dma: Fix iova map result check bug
On Sat, May 07, 2022 at 04:52:03PM +0800, yf.w...@mediatek.com wrote: > drivers/iommu/dma-iommu.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu/mediatek: Fix NULL pointer dereference when printing dev_name
On Thu, May 05, 2022 at 09:27:30PM +0800, Miles Chen wrote: > drivers/iommu/mtk_iommu.c| 6 ++ > drivers/iommu/mtk_iommu_v1.c | 7 +++ > 2 files changed, 13 insertions(+) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu: iommu_group_claim_dma_owner() must always assign a domain
On Mon, May 09, 2022 at 01:19:19PM -0300, Jason Gunthorpe wrote: > drivers/iommu/iommu.c | 127 ++ > 1 file changed, 91 insertions(+), 36 deletions(-) Applied, thanks. Will back-merge the branch into next now. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux v5.18-rc5
Hi Linus, The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b: Linux 5.18-rc4 (2022-04-24 14:51:22 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iomm-fixes-v5.18-rc5 for you to fetch changes up to 392bf51946c2463436a1ba237c1ec5865b234825: iommu: Make sysfs robust for non-API groups (2022-05-04 15:13:39 +0200) IOMMU Fixes for Linux v5.18-rc5 Including: - Fix for a regression in IOMMU core code which could cause NULL-ptr dereferences - Arm SMMU fixes for 5.18 - Fix off-by-one in SMMUv3 SVA TLB invalidation - Disable large mappings to workaround nvidia erratum - Intel VT-d fixes - Handle PCI stop marker messages in IOMMU driver to meet the requirement of I/O page fault handling framework. - Calculate a feasible mask for non-aligned page-selective IOTLB invalidation. - Two fixes for Apple DART IOMMU driver - Fix potential NULL-ptr dereference - Set module owner Ashish Mhetre (1): iommu: arm-smmu: disable large page mappings for Nvidia arm-smmu David Stevens (1): iommu/vt-d: Calculate mask for non-aligned flushes Hector Martin (1): iommu/dart: Add missing module owner to ops structure Joerg Roedel (1): Merge tag 'arm-smmu-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into iommu/fixes Lu Baolu (1): iommu/vt-d: Drop stop marker messages Nicolin Chen (1): iommu/arm-smmu-v3: Fix size calculation in arm_smmu_mm_invalidate_range() Robin Murphy (1): iommu: Make sysfs robust for non-API groups Yang Yingliang (1): iommu/dart: check return value after calling platform_get_resource() drivers/iommu/apple-dart.c | 10 - drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 9 +++- drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c| 30 + drivers/iommu/intel/iommu.c | 27 +++--- drivers/iommu/intel/svm.c | 4 drivers/iommu/iommu.c | 9 +++- 6 files changed, 79 insertions(+), 10 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: Make sysfs robust for non-API groups
On Wed, May 04, 2022 at 01:39:58PM +0100, Robin Murphy wrote:
> Groups created by VFIO backends outside the core IOMMU API should never
> be passed directly into the API itself, however they still expose their
> standard sysfs attributes, so we can still stumble across them that way.
> Take care to consider those cases before jumping into our normal
> assumptions of a fully-initialised core API group.
>
> Fixes: 3f6634d997db ("iommu: Use right way to retrieve iommu_ops")
> Reported-by: Jan Stancek
> Tested-by: Jan Stancek
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Robin Murphy
> ---
>
> /me has a vested interest in not going backwards on dev_iommu_ops() :)
>
> drivers/iommu/iommu.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RESEND PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
On Wed, May 04, 2022 at 08:51:35AM -0300, Jason Gunthorpe wrote: > Nicolin and Eric have been testing with this series on ARM for a long > time now, it is not like it is completely broken. Yeah, I am also optimistic this can be fixed soon. But the rule is that the next branch should only contain patches which I would send to Linus. And with a known issue in it I wouldn't, so it is excluded at least from my next branch for now. The topic branch is still alive and I will merge it again when the fix is in. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [bug] NULL pointer deref after 3f6634d997db ("iommu: Use right way to retrieve iommu_ops")
Hi Robin, On Wed, May 04, 2022 at 12:14:07PM +0100, Robin Murphy wrote: > Oof, this can probably be hit with vfio-noiommu too, and by the look of > things, `echo auto > /sys/kernel/iommu_groups/0/type` would likely blow > up as well. Does the patch below work for you? Thanks for the quick patch! I am delaying to send iommu-fixes upstream for now in the hope the fix can make it into the branch asap. Please send it out as a separate patch as soon as it is successfully tested. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu: fix an incorrect NULL check on list iterator
On Sun, May 01, 2022 at 09:28:23PM +0800, Xiaomeng Tong wrote:
> The bug is here:
> if (!iommu || iommu->dev->of_node != spec->np) {
>
> The list iterator value 'iommu' will *always* be set and non-NULL by
> list_for_each_entry(), so it is incorrect to assume that the iterator
> value will be NULL if the list is empty or no element is found (in fact,
> it will point to a invalid structure object containing HEAD).
>
> To fix the bug, use a new value 'iter' as the list iterator, while use
> the old value 'iommu' as a dedicated variable to point to the found one,
> and remove the unneeded check for 'iommu->dev->of_node != spec->np'
> outside the loop.
>
> Cc: sta...@vger.kernel.org
> Fixes: f78ebca8ff3d6 ("iommu/msm: Add support for generic master bindings")
> Signed-off-by: Xiaomeng Tong
> ---
> changes since v1:
> - add a new iter variable (suggested by Joerg Roedel)
This is now applied. I had to manually apply it because the patch was
malformed at line 36 and git-am complained.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RESEND PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
On Mon, May 02, 2022 at 12:12:04PM -0400, Qian Cai wrote: > Reverting this series fixed an user-after-free while doing SR-IOV. > > BUG: KASAN: use-after-free in __lock_acquire Hrm, okay. I am going exclude this series from my next branch for now until this has been sorted out. Alex, I suggest you do the same. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 00/36] MT8195 and MT8186 IOMMU SUPPORT
On Tue, May 03, 2022 at 03:13:51PM +0800, Yong Wu wrote: > Yong Wu (36): > dt-bindings: mediatek: mt8195: Add binding for MM IOMMU > dt-bindings: mediatek: mt8195: Add binding for infra IOMMU > dt-bindings: mediatek: mt8186: Add binding for MM iommu > iommu/mediatek: Fix 2 HW sharing pgtable issue > iommu/mediatek: Add list_del in mtk_iommu_remove > iommu/mediatek: Remove clk_disable in mtk_iommu_remove > iommu/mediatek: Add mutex for m4u_group and m4u_dom in data > iommu/mediatek: Add mutex for data in the mtk_iommu_domain > iommu/mediatek: Adapt sharing and non-sharing pgtable case > iommu/mediatek: Add 12G~16G support for multi domains > iommu/mediatek: Add a flag DCM_DISABLE > iommu/mediatek: Add a flag STD_AXI_MODE > iommu/mediatek: Remove the granule in the tlb flush > iommu/mediatek: Always enable output PA over 32bits in isr > iommu/mediatek: Add SUB_COMMON_3BITS flag > iommu/mediatek: Add IOMMU_TYPE flag > iommu/mediatek: Contain MM IOMMU flow with the MM TYPE > iommu/mediatek: Adjust device link when it is sub-common > iommu/mediatek: Allow IOMMU_DOMAIN_UNMANAGED for PCIe VFIO > iommu/mediatek: Add a PM_CLK_AO flag for infra iommu > iommu/mediatek: Add infra iommu support > iommu/mediatek: Add PCIe support > iommu/mediatek: Add mt8195 support > iommu/mediatek: Only adjust code about register base > iommu/mediatek: Just move code position in hw_init > iommu/mediatek: Separate mtk_iommu_data for v1 and v2 > iommu/mediatek: Remove mtk_iommu.h > iommu/mediatek-v1: Just rename mtk_iommu to mtk_iommu_v1 > iommu/mediatek: Add mtk_iommu_bank_data structure > iommu/mediatek: Initialise bank HW for each a bank > iommu/mediatek: Change the domid to iova_region_id > iommu/mediatek: Get the proper bankid for multi banks > iommu/mediatek: Initialise/Remove for multi bank dev > iommu/mediatek: Backup/restore regsiters for multi banks > iommu/mediatek: mt8195: Enable multi banks for infra iommu > iommu/mediatek: Add mt8186 iommu support Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/7] dt-bindings: iommu: renesas, ipmmu-vmsa: R-Car V3U is R-Car Gen4
On Mon, May 02, 2022 at 03:34:55PM +0200, Geert Uytterhoeven wrote: > Despite the name, R-Car V3U is the first member of the R-Car Gen4 > family. Hence move its compatible value to the R-Car Gen4 section. > > Signed-off-by: Geert Uytterhoeven > --- > .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Joerg Roedel ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: dart: Add missing module owner to ops structure
On Mon, May 02, 2022 at 06:22:38PM +0900, Hector Martin wrote: > This is required to make loading this as a module work. > > Signed-off-by: Hector Martin > --- > drivers/iommu/apple-dart.c | 1 + > 1 file changed, 1 insertion(+) Applied for v5.18, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 10/37] iommu/amd: Introduce per PCI segment last_bdf
Hi Vasant, On Fri, Apr 29, 2022 at 08:15:49PM +0530, Vasant Hegde wrote: > We still need to parse IVHD to find max devices supported by each PCI segment > (same as the way its doing it today). Hence we need all these variables. >From what I have seen since a few years the IVRS tables enumerate the whole PCI segment, up to device ff:1f.7. This results in the maximum being allocated for all data structures anyway. Therefore we can probably think about skipping the scan to find the largest bdf and just assume it is ff:1f.7, saving us all the size-tracking variables? Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/2] MT8186 IOMMU SUPPORT
On Thu, Apr 07, 2022 at 04:32:28PM +0800, Yong Wu wrote: > Yong Wu (2): > dt-bindings: mediatek: mt8186: Add binding for MM iommu > iommu/mediatek: Add mt8186 iommu support > > .../bindings/iommu/mediatek,iommu.yaml| 4 + > drivers/iommu/mtk_iommu.c | 17 ++ > .../dt-bindings/memory/mt8186-memory-port.h | 217 ++ > 3 files changed, 238 insertions(+) > create mode 100644 include/dt-bindings/memory/mt8186-memory-port.h This patch-set seems to apply cleanly only on 'MT8195 IOMMU SUPPORT', please re-submit it together with the former when you made the changes Matthias requested. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RESEND PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
On Thu, Apr 28, 2022 at 08:54:11AM -0300, Jason Gunthorpe wrote: > Can we get this on a topic branch so Alex can pull it? There are > conflicts with other VFIO patches Right, we already discussed this. Moved the patches to a separate topic branch. It will appear as 'vfio-notifier-fix' once I pushed the changes. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/msm: add a check for the return of kzalloc()
On Thu, Apr 28, 2022 at 04:52:39PM +0800, xkernel.w...@foxmail.com wrote: > From: Xiaoke Wang > > kzalloc() is a memory allocation function which can return NULL when > some internal memory errors happen. So it is better to check it to > prevent potential wrong memory access. > > Besides, to propagate the error to the caller, the type of > insert_iommu_master() is changed to `int`. Several instructions related > to it are also updated. > > Signed-off-by: Xiaoke Wang > --- > ChangeLog: > v1->v2 propagate the error to the caller. > drivers/iommu/msm_iommu.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 00/37] iommu/amd: Add multiple PCI segments support
Hi Vasant, Hi Suravee, On Mon, Apr 25, 2022 at 05:03:38PM +0530, Vasant Hegde wrote: > Newer AMD systems can support multiple PCI segments, where each segment > contains one or more IOMMU instances. However, an IOMMU instance can only > support a single PCI segment. Thanks for doing this, making the AMD IOMMU driver multi-segment aware has been on my todo list for a while too. Overall the series looks good to me, just some minor comments to some patches. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 37/37] iommu/amd: Update amd_iommu_fault structure to include PCI seg ID
On Mon, Apr 25, 2022 at 05:04:15PM +0530, Vasant Hegde wrote: > + seg_id = (iommu_fault->sbdf >> 16) & 0x; > + devid = iommu_fault->sbdf & 0x; This deserves some macros for readability. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 27/37] iommu/amd: Remove global amd_iommu_dev_table
On Mon, Apr 25, 2022 at 05:04:05PM +0530, Vasant Hegde wrote: > From: Suravee Suthikulpanit > > Replace global amd_iommu_dev_table with per PCI segment device table. > Also remove "dev_table_size". > > Co-developed-by: Vasant Hegde > Signed-off-by: Vasant Hegde > Signed-off-by: Suravee Suthikulpanit Patches 27-29 can be merged into one. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 11/37] iommu/amd: Introduce per PCI segment device table size
On Mon, Apr 25, 2022 at 05:03:49PM +0530, Vasant Hegde wrote: > + /* Size of the device table */ > + u32 dev_table_size; Same here and with all other size indicators. If they are always going to have their maximum value anyways, we can drop them. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 10/37] iommu/amd: Introduce per PCI segment last_bdf
On Mon, Apr 25, 2022 at 05:03:48PM +0530, Vasant Hegde wrote: > + /* Largest PCI device id we expect translation requests for */ > + u16 last_bdf; How does the IVRS table look like on these systems? Do they still enumerate the whole PCI Bus/Dev/Fn space? If so I am fine with getting rid of last_bdf alltogether and just allocate the data structures with their maximum size. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 01/37] iommu/amd: Update struct iommu_dev_data defination
On Mon, Apr 25, 2022 at 05:03:39PM +0530, Vasant Hegde wrote: Subject: iommu/amd: Update struct iommu_dev_data defination ^^ Typo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 02/37] iommu/amd: Introduce pci segment structure
Hi Vasant,
On Mon, Apr 25, 2022 at 05:03:40PM +0530, Vasant Hegde wrote:
> +/*
> + * This structure contains information about one PCI segment in the system.
> + */
> +struct amd_iommu_pci_seg {
> + struct list_head list;
The purpose of this list_head needs a comment.
> +
> + /* PCI segment number */
> + u16 id;
> +};
> +/*
> + * List with all PCI segments in the system. This list is not locked because
> + * it is only written at driver initialization time
> + */
> +extern struct list_head amd_iommu_pci_seg_list;
So there will never be hotplug of a PCI segment? Say together with
hotplugging a CPU?
> +static void __init free_pci_segment(void)
This needs plural: free_pci_segments(), as it frees all segments.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/dart: check return value after calling platform_get_resource()
On Mon, Apr 25, 2022 at 05:08:26PM +0800, Yang Yingliang wrote:
> It will cause null-ptr-deref in resource_size(), if platform_get_resource()
> returns NULL, move calling resource_size() after devm_ioremap_resource() that
> will check 'res' to avoid null-ptr-deref.
> And use devm_platform_get_and_ioremap_resource() to simplify code.
>
> Fixes: 46d1fb072e76 ("iommu/dart: Add DART iommu driver")
> Signed-off-by: Yang Yingliang
> ---
> drivers/iommu/apple-dart.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
Applied to iommu/fixes, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: iommu: Drop client node in examples
On Fri, Apr 22, 2022 at 02:21:03PM -0500, Rob Herring wrote: > There's no need to show consumer side in provider examples. The ones > used here are undocumented or undocumented in schemas which results in > warnings. > > Signed-off-by: Rob Herring Applied, thanks Rob. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [GIT PULL] iommu/arm-smmu: Fixes for 5.18
On Fri, Apr 22, 2022 at 12:22:34PM +0100, Will Deacon wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git > tags/arm-smmu-fixes Pulled, thanks Will. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RESEND PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
On Mon, Apr 18, 2022 at 08:49:49AM +0800, Lu Baolu wrote: > Lu Baolu (10): > iommu: Add DMA ownership management interfaces > driver core: Add dma_cleanup callback in bus_type > amba: Stop sharing platform_dma_configure() > bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management > PCI: pci_stub: Set driver_managed_dma > PCI: portdrv: Set driver_managed_dma > vfio: Set DMA ownership for VFIO devices > vfio: Remove use of vfio_group_viable() > vfio: Remove iommu group notifier > iommu: Remove iommu group changes notifier Applied to core branch, thanks Baolu. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] MAINTAINERS: merge DART into ARM/APPLE MACHINE
On Tue, Apr 12, 2022 at 06:12:11PM +0200, Sven Peter wrote: > It's the same people anyway. > > Signed-off-by: Sven Peter > --- > MAINTAINERS | 10 ++ > 1 file changed, 2 insertions(+), 8 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/1] iommu/vt-d: Fixes for v5.18-rc4
On Sat, Apr 23, 2022 at 04:23:29PM +0800, Lu Baolu wrote: > Hi Joerg, > > One fix is queued for v5.18. It aims to fix: > > - Handle PCI stop marker messages in IOMMU driver to meet the >requirement of I/O page fault handling framework. > > Please consider it for the iommu/fix branch. > > Best regards, > Lu Baolu > > Lu Baolu (1): > iommu/vt-d: Drop stop marker messages > > drivers/iommu/intel/svm.c | 4 > 1 file changed, 4 insertions(+) Applied to iommu/fixes, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/1] iommu/vt-d: Fixes for v5.18-rc3
On Sun, Apr 10, 2022 at 09:35:32AM +0800, Lu Baolu wrote: > Hi Joerg, > > One fix is queued for v5.18. It aims to fix: > > - Calculate a feasible mask for non-aligned page-selective >IOTLB invalidation. > > Please consider it for the iommu/fix branch. > > Best regards, > Lu Baolu > > David Stevens (1): > iommu/vt-d: Calculate mask for non-aligned flushes > > drivers/iommu/intel/iommu.c | 27 --- > 1 file changed, 24 insertions(+), 3 deletions(-) Applied to iommu/fixes, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/4] Make the iommu driver no-snoop block feature consistent
On Mon, Apr 11, 2022 at 12:16:04PM -0300, Jason Gunthorpe wrote: > Jason Gunthorpe (4): > iommu: Introduce the domain op enforce_cache_coherency() > vfio: Move the Intel no-snoop control off of IOMMU_CACHE > iommu: Redefine IOMMU_CAP_CACHE_COHERENCY as the cap flag for > IOMMU_CACHE > vfio: Require that devices support DMA cache coherence > > drivers/iommu/amd/iommu.c | 7 +++ > drivers/iommu/intel/iommu.c | 17 + > drivers/vfio/vfio.c | 7 +++ > drivers/vfio/vfio_iommu_type1.c | 30 +++--- > include/linux/intel-iommu.h | 2 +- > include/linux/iommu.h | 7 +-- > 6 files changed, 52 insertions(+), 18 deletions(-) Applied to core branch, thanks everyone. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: remve dead iommu code
On Thu, Apr 07, 2022 at 08:26:04AM +0200, Christoph Hellwig wrote: > Hi all, > > this removes a bit of dead code and methods from the iommu code and the > cleans up the arm-smmu-v3 driver a little bit based on that. > > Diffstat: > drivers/iommu/amd/iommu.c |1 > drivers/iommu/apple-dart.c |1 > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 60 > +++- > drivers/iommu/arm/arm-smmu/arm-smmu.c |1 > drivers/iommu/intel/iommu.c |1 > drivers/iommu/iommu.c | 33 --- > drivers/iommu/mtk_iommu.c |1 > drivers/iommu/virtio-iommu.c|5 -- > include/linux/iommu.h | 17 --- > 9 files changed, 19 insertions(+), 101 deletions(-) This concerns mostly arm-smmu, please also Cc Will Deacon on this one. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/2] Fix issues with untrusted devices and AMD IOMMU
On Mon, Apr 04, 2022 at 03:47:21PM -0500, Mario Limonciello wrote: > Mario Limonciello (2): > iommu/amd: Enable swiotlb in all cases > dma-iommu: Check that swiotlb is active before trying to use it > > drivers/iommu/amd/iommu.c | 7 --- > drivers/iommu/dma-iommu.c | 5 + > 2 files changed, 5 insertions(+), 7 deletions(-) Applied to core branch, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/fsl_pamu: Prepare cleanup of powerpc's asm/prom.h
On Sat, Apr 02, 2022 at 12:08:38PM +0200, Christophe Leroy wrote: > powerpc's asm/prom.h brings some headers that it doesn't > need itself. > > In order to clean it up, first add missing headers in > users of asm/prom.h > > Signed-off-by: Christophe Leroy > --- > drivers/iommu/fsl_pamu.c| 3 +++ > drivers/iommu/fsl_pamu_domain.c | 1 + > 2 files changed, 4 insertions(+) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: add null pointer check
On Tue, Mar 29, 2022 at 05:53:22AM +, cgel@gmail.com wrote:
> From: Lv Ruyi
>
> kmem_cache_zalloc is a memory allocation function which can return NULL
> when some internal memory errors happen. Add null pointer check to avoid
> dereferencing null pointer.
>
> Reported-by: Zeal Robot
> Signed-off-by: Lv Ruyi
> ---
> drivers/iommu/fsl_pamu_domain.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
> index 69a4a62dc3b9..43849c027298 100644
> --- a/drivers/iommu/fsl_pamu_domain.c
> +++ b/drivers/iommu/fsl_pamu_domain.c
> @@ -152,6 +152,10 @@ static void attach_device(struct fsl_dma_domain
> *dma_domain, int liodn, struct d
> }
>
> info = kmem_cache_zalloc(iommu_devinfo_cache, GFP_ATOMIC);
> + if (!info) {
> + spin_unlock_irqrestore(&device_domain_lock, flags);
> + return;
> + }
Such errors need to be propagated.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] Documentation: x86: rework IOMMU documentation
On Fri, Apr 22, 2022 at 04:06:07PM -0400, Alex Deucher wrote: > Add preliminary documentation for AMD IOMMU and combine > with the existing Intel IOMMU documentation and clean > up and modernize some of the existing documentation to > align with the current state of the kernel. > > Signed-off-by: Alex Deucher > --- > > V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., > a device) and document proper DMA API. Also correct the fact that > the AMD IOMMU is not limited to managing PCI devices. > v3: Fix spelling and rework text as suggested by Vasant > v4: Combine Intel and AMD documents into a single document as suggested > by Dave Hansen > v5: Clarify that keywords are related to ACPI, grammatical fixes > v6: Make more stuff common based on feedback from Robin > > Documentation/x86/index.rst | 2 +- > Documentation/x86/intel-iommu.rst | 115 > Documentation/x86/iommu.rst | 143 ++ > 3 files changed, 144 insertions(+), 116 deletions(-) > delete mode 100644 Documentation/x86/intel-iommu.rst > create mode 100644 Documentation/x86/iommu.rst Acked-by: Joerg Roedel Jonathan, will you merge that through the documentation tree? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: fix an incorrect NULL check on list iterator
On Sun, Mar 27, 2022 at 01:35:58PM +0800, Xiaomeng Tong wrote:
> @@ -617,23 +617,17 @@ static int qcom_iommu_of_xlate(struct device *dev,
> {
> struct msm_iommu_dev *iommu;
> unsigned long flags;
> - int ret = 0;
>
> spin_lock_irqsave(&msm_iommu_lock, flags);
> list_for_each_entry(iommu, &qcom_iommu_devices, dev_node)
> - if (iommu->dev->of_node == spec->np)
> - break;
> -
> - if (!iommu || iommu->dev->of_node != spec->np) {
> - ret = -ENODEV;
> - goto fail;
> - }
> -
> - insert_iommu_master(dev, &iommu, spec);
> -fail:
> + if (iommu->dev->of_node == spec->np) {
> + insert_iommu_master(dev, &iommu, spec);
> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
> + return 0;
> + }
> spin_unlock_irqrestore(&msm_iommu_lock, flags);
>
> - return ret;
> + return -ENODEV;
This looks a bit clumsy, a better fix is below:
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 50f57624610f..98d23c52537b 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -610,14 +610,16 @@ static void insert_iommu_master(struct device *dev,
static int qcom_iommu_of_xlate(struct device *dev,
struct of_phandle_args *spec)
{
- struct msm_iommu_dev *iommu;
+ struct msm_iommu_dev *iommu = NULL, *it;
unsigned long flags;
int ret = 0;
spin_lock_irqsave(&msm_iommu_lock, flags);
- list_for_each_entry(iommu, &qcom_iommu_devices, dev_node)
- if (iommu->dev->of_node == spec->np)
+ list_for_each_entry(it, &qcom_iommu_devices, dev_node)
+ if (it->dev->of_node == spec->np) {
+ iommu = it;
break;
+ }
if (!iommu || iommu->dev->of_node != spec->np) {
ret = -ENODEV;
Can you please verify this and re-submit?
Thanks,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/msm: add a check for the return of kzalloc()
On Fri, Mar 25, 2022 at 10:08:01AM +0800, xkernel.w...@foxmail.com wrote:
> From: Xiaoke Wang
>
> kzalloc() is a memory allocation function which can return NULL when
> some internal memory errors happen. So it is better to check it to
> prevent potential wrong memory access.
>
> Signed-off-by: Xiaoke Wang
> ---
> drivers/iommu/msm_iommu.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 3a38352..697ad63 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -597,6 +597,10 @@ static void insert_iommu_master(struct device *dev,
>
> if (list_empty(&(*iommu)->ctx_list)) {
> master = kzalloc(sizeof(*master), GFP_ATOMIC);
> + if (!master) {
> + dev_err(dev, "Failed to allocate iommu_master\n");
> + return;
> + }
This is not enough, if the error happens it also need to be propagated
to the caller.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Remove redundant check
On Mon, Mar 14, 2022 at 12:32:26PM +0530, Vasant Hegde wrote:
> smatch static checker warning:
> drivers/iommu/amd/init.c:1989 amd_iommu_init_pci()
> warn: duplicate check 'ret' (previous on line 1978)
>
> Reported-by: Dan Carpenter
> Fixes: 06687a03805e ("iommu/amd: Improve error handling for
> amd_iommu_init_pci")
> Signed-off-by: Vasant Hegde
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Do not call sleep while holding spinlock
On Sun, Mar 13, 2022 at 09:43:21PM -0500, Suravee Suthikulpanit wrote:
> Smatch static checker warns:
> drivers/iommu/amd/iommu_v2.c:133 free_device_state()
> warn: sleeping in atomic context
>
> Fixes by storing the list of struct device_state in a temporary
> list, and then free the memory after releasing the spinlock.
>
> Reported-by: Dan Carpenter
> Fixes: dc6a709e5123 ("iommu/amd: Improve amd_iommu_v2_exit()")
> Signed-off-by: Suravee Suthikulpanit
> ---
> drivers/iommu/amd/iommu_v2.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
Applied, thanks Suravee.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote: > You might consider using a linear tree instead of the topic branches, > topics are tricky and I'm not sure it helps a small subsystem so much. > Conflicts between topics are a PITA for everyone, and it makes > handling conflicts with rc much harder than it needs to be. I like the concept of a branch per driver, because with that I can just exclude that branch from my next-merge when there are issues with it. Conflicts between branches happen too, but they are quite manageable when the branches have the same base. Overall I am thinking of reorganizing the IOMMU tree, but it will likely not end up to be a single-branch tree, although the number of patches per cycle _could_ just be carried in a single branch. > At least I haven't felt a need for topics while running larger trees, > and would find it stressful to try and squeeze the entire patch flow > into only 3 weeks out of the 7 week cycle. Yeah, so it is 4 weeks in an 9 weeks cycle :) The merge window is 2 weeks and not a lot happens. The 2 weeks after are for stabilization and I usually only pick up fixes. Then come the 4 weeks were new code gets into the tree. In the last week everything gets testing in linux-next to be ready for the merge window. I will pickup fixes in that week, of course. > In any event, I'd like this on a branch so Alex can pull it too, I > guess it means Alex has to merge rc3 to VFIO as well? Sure, I can put these patches in a separate branch for Alex to pull into the VFIO tree. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
On Fri, Apr 08, 2022 at 09:23:52AM -0300, Jason Gunthorpe wrote: > Why rc3? It has been 4 weeks now with no futher comments. Because I start applying new code to branches based on -rc3. In the past I used different -rc's for the topic branches (usually the latest -rc available when I started applying to that branch), but that caused silly merge conflicts from time to time. So I am now basing every topic branch on the same -rc, which is usually -rc3. Rationale is that by -rc3 time the kernel should have reasonably stabilized after the merge window. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux v5.18-rc1
Hi Linus, The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fix-v5.18-rc1 for you to fetch changes up to 71ff461c3f41f6465434b9e980c01782763e7ad8: iommu/omap: Fix regression in probe for NULL pointer dereference (2022-04-08 11:16:29 +0200) IOMMU Fix for Linux v5.18-rc1: - Fix boot regression due to a NULL-ptr dereference on OMAP machines Tony Lindgren (1): iommu/omap: Fix regression in probe for NULL pointer dereference drivers/iommu/omap-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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/omap: Fix regression in probe for NULL pointer dereference
On Thu, Apr 07, 2022 at 08:39:05AM +0300, Tony Lindgren wrote: > Can you guys please get this fix into the -rc series? Or ack it so > I can pick it up into my fixes branch? Sorry for the delay, Covid catched me so I was away from email for almost 2 week. This patch is picked-up now and I will send it upstream for -rc2. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()
On Mon, Mar 14, 2022 at 09:21:25PM -0300, Jason Gunthorpe wrote: > Joerg, are we good for the coming v5.18 merge window now? There are > several things backed up behind this series. I usually don't apply bigger changes like this after -rc7, so it didn't make it. Please re-send after -rc3 is out and I will consider it. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Updates for Linux v5.18
Hi Linus, there is a conflict this time when merging the IOMMU tree updates. It is in drivers/iommu/intel/iommu.c and comes from the fact that the tip-tree patched functions in that file which get removed with these updates. So the merge resolution is to use the changes from the IOMMU tree. With that in mind, here are the IOMMU changes for v5.18: The following changes since commit ffb217a13a2eaf6d5bd974fc83036a53ca69f1e2: Linux 5.17-rc7 (2022-03-06 14:28:31 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v5.18 for you to fetch changes up to e17c6debd4b2d2d474074f83946f8c6522587566: Merge branches 'arm/mediatek', 'arm/msm', 'arm/renesas', 'arm/rockchip', 'arm/smmu', 'x86/vt-d' and 'x86/amd' into next (2022-03-08 12:21:31 +0100) IOMMU Updates for Linux v5.18 Including: - IOMMU Core changes: - Removal of aux domain related code as it is basically dead and will be replaced by iommu-fd framework - Split of iommu_ops to carry domain-specific call-backs separatly - Cleanup to remove useless ops->capable implementations - Improve 32-bit free space estimate in iova allocator - Intel VT-d updates: - Various cleanups of the driver - Support for ATS of SoC-integrated devices listed in ACPI/SATC table - ARM SMMU updates: - Fix SMMUv3 soft lockup during continuous stream of events - Fix error path for Qualcomm SMMU probe() - Rework SMMU IRQ setup to prepare the ground for PMU support - Minor cleanups and refactoring - AMD IOMMU driver: - Some minor cleanups and error-handling fixes - Rockchip IOMMU driver: - Use standard driver registration - MSM IOMMU driver: - Minor cleanup and change to standard driver registration - Mediatek IOMMU driver: - Fixes for IOTLB flushing logic Andy Shevchenko (2): perf/smmuv3: Don't cast parameter in bit operations iommu/vt-d: Move intel_iommu_ops to header file Christophe JAILLET (2): iommu/arm-smmu-v3: Avoid open coded arithmetic in memory allocation iommu/arm-smmu-v3: Simplify memory allocation David Heidelberg (1): iommu/msm: Simplify with dev_err_probe() Jiasheng Jiang (1): iommu/ipmmu-vmsa: Check for error num after setting mask Joerg Roedel (3): Merge branch 'core' into x86/vt-d Merge tag 'arm-smmu-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/smmu Merge branches 'arm/mediatek', 'arm/msm', 'arm/renesas', 'arm/rockchip', 'arm/smmu', 'x86/vt-d' and 'x86/amd' into next John Garry (1): iommu/iova: Separate out rcache init Lu Baolu (17): iommu/vt-d: Remove guest pasid related callbacks iommu: Remove guest pasid related interfaces and definitions iommu/vt-d: Remove aux-domain related callbacks iommu: Remove aux-domain related interfaces and iommu_ops iommu: Remove apply_resv_region drm/nouveau/device: Get right pgsize_bitmap of iommu_domain iommu: Use right way to retrieve iommu_ops iommu: Remove unused argument in is_attach_deferred iommu: Split struct iommu_ops iommu/vt-d: Remove intel_iommu::domains iommu/vt-d: Remove finding domain in dmar_insert_one_dev_info() iommu/vt-d: Remove iova_cache_get/put() iommu/vt-d: Remove domain and devinfo mempool iommu/vt-d: Remove DEFER_DEVICE_DOMAIN_INFO iommu/vt-d: Remove unnecessary includes iommu/vt-d: Remove unnecessary prototypes iommu/vt-d: Fix indentation of goto labels Marco Bonelli (1): iommu/vt-d: Add missing "__init" for rmrr_sanity_check() Miaoqian Lin (1): iommu/arm-smmu: Add missing pm_runtime_disable() in qcom_iommu_device_probe Rafael J. Wysocki (1): iommu/vtd: Replace acpi_bus_get_device() Robin Murphy (5): iommu: Remove trivial ops->capable implementations iommu/rockchip: : Use standard driver registration iommu/msm: Use standard driver registration iommu/iova: Improve 32-bit free space estimate iommu/arm-smmu: Account for PMU interrupts Sebastian Reichel (1): iommu/mediatek: Always check runtime PM status in tlb flush range callback Suravee Suthikulpanit (2): iommu/amd: Improve error handling for amd_iommu_init_pci iommu/amd: Improve amd_iommu_v2_exit() Vasant Hegde (3): iommu/amd: Call memunmap in error path iommu/amd: Clean up function declarations iommu/amd: Remove unused struct fault.devid Yian Chen
Re: [GIT PULL] iommu/arm-smmu: Updates for 5.18
On Tue, Mar 08, 2022 at 10:18:10AM +, Will Deacon wrote: > Hi Joerg, > > Please pull this handful of Arm SMMU updates for 5.18. Summary in the tag. Pulled, thanks Will. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
