[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(_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(_iommu_lock, flags);
> list_for_each_entry(iommu, _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, , spec);
> -fail:
> + if (iommu->dev->of_node == spec->np) {
> + insert_iommu_master(dev, , spec);
> + spin_unlock_irqrestore(_iommu_lock, flags);
> + return 0;
> + }
> spin_unlock_irqrestore(_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(_iommu_lock, flags);
- list_for_each_entry(iommu, _iommu_devices, dev_node)
- if (iommu->dev->of_node == spec->np)
+ list_for_each_entry(it, _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 (1): iommu/vt-d: Enable ATS for the devices in SATC table Yong Wu (4): iommu/mediatek: Remove for_each_m4u in tlb_sync_all iommu/mediatek: Remove
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
Re: [PATCH 00/12] [PULL REQUEST] Intel IOMMU updates for Linux v5.18
On Fri, Mar 04, 2022 at 06:37:01PM +0800, Lu Baolu wrote: > It's based on this series: > > https://lore.kernel.org/linux-iommu/yhy%2fawftokqll...@8bytes.org/ > > which contains some cleanup in vt-d driver as well. > > If I re-base the series onto the vt-d branch, there will also be > conflicts when you merge the core and vt-d branch. > > I can re-base anyway if you think that's not a problem. Alright, I merged the core branch into the vt-d branch and applied your changes on-top, thanks. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux v5.17-rc6
Hi Linus, The following changes since commit 754e0b0e35608ed5206d6a67a791563c631cec07: Linux 5.17-rc4 (2022-02-13 12:13:30 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.17-rc6 for you to fetch changes up to 9826e393e4a8c3df474e7f9eacd3087266f74005: iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find (2022-02-28 14:01:57 +0100) IOMMU Fixes for Linux v5.17-rc6 Including: - Fix a double list_add() in Intel VT-d code - Add missing put_device() in Tegra SMMU driver - Two AMD IOMMU fixes: - Memory leak in IO page-table freeing code - Add missing recovery from event-log overflow Adrian Huang (1): iommu/vt-d: Fix double list_add when enabling VMD in scalable mode Lennert Buytenhek (1): iommu/amd: Recover from event log overflow Miaoqian Lin (1): iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find Suravee Suthikulpanit (1): iommu/amd: Fix I/O page table memory leak drivers/iommu/amd/amd_iommu.h | 1 + drivers/iommu/amd/amd_iommu_types.h | 1 + drivers/iommu/amd/init.c| 10 ++ drivers/iommu/amd/io_pgtable.c | 12 ++-- drivers/iommu/amd/iommu.c | 10 -- drivers/iommu/intel/iommu.c | 2 +- drivers/iommu/tegra-smmu.c | 4 +++- 7 files changed, 30 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 v5 00/34] MT8195 IOMMU SUPPORT
On Fri, Mar 04, 2022 at 05:57:19PM +0800, Yong Wu wrote: > Thanks for this info. I will re-send this patchset after the next -rc1. > > Could you help apply Dafna's patchset at this time? This patchset > depends on it and it won't conflict with the others. Alright, picked up Dafna's patch-set. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/5] iommu/mediatek: Fix tlb flush logic
On Wed, Dec 08, 2021 at 02:07:39PM +0200, Dafna Hirschfeld wrote: > Sebastian Reichel (1): > iommu/mediatek: Always check runtime PM status in tlb flush range > callback > > Yong Wu (4): > iommu/mediatek: Remove for_each_m4u in tlb_sync_all > iommu/mediatek: Remove the power status checking in tlb flush all > iommu/mediatek: Add tlb_lock in tlb_flush_all > iommu/mediatek: Always tlb_flush_all when each PM resume > > drivers/iommu/mtk_iommu.c | 42 --- > 1 file changed, 22 insertions(+), 20 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/iova: Improve 32-bit free space estimate
On Fri, Mar 04, 2022 at 07:36:46AM +0800, Miles Chen wrote: > Hi Robin, > > > For various reasons based on the allocator behaviour and typical > > use-cases at the time, when the max32_alloc_size optimisation was > > introduced it seemed reasonable to couple the reset of the tracked > > size to the update of cached32_node upon freeing a relevant IOVA. > > However, since subsequent optimisations focused on helping genuine > > 32-bit devices make best use of even more limited address spaces, it > > is now a lot more likely for cached32_node to be anywhere in a "full" > > 32-bit address space, and as such more likely for space to become > > available from IOVAs below that node being freed. > > > > At this point, the short-cut in __cached_rbnode_delete_update() really > > doesn't hold up any more, and we need to fix the logic to reliably > > provide the expected behaviour. We still want cached32_node to only move > > upwards, but we should reset the allocation size if *any* 32-bit space > > has become available. > > > > Reported-by: Yunfei Wang > > Signed-off-by: Robin Murphy > > Would you mind adding: > > Cc: Applied without stable tag for now. If needed, please consider re-sending it for stable when this patch is merged upstream. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/5] iommu/amd: Cleanup and fixes
On Tue, Mar 01, 2022 at 02:26:21PM +0530, Vasant Hegde wrote: > This series contains various cleanup and trivial fixes. > > Changes in v2: > - Fixed error log message in patch 1 as suggested by Joerg. > > > 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 Applied, thanks Vasant and Suravee. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 00/12] [PULL REQUEST] Intel IOMMU updates for Linux v5.18
Hi Baolu, On Tue, Mar 01, 2022 at 10:01:47AM +0800, Lu Baolu wrote: > This includes patches queued for v5.18. It includes: > > - [PATCH 1 ~ 11] Various cleanups, no intentional functional changes. > - [PATCH 12] Enable ATS in SoC-integrated devices listed in ACPI/SATC > table. > > Please consider them for v5.18. I would, but this shows non-trivial conflicts when I am applying it to the x86/vt-d branch. Can you please re-base the changes and send again? Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 00/34] MT8195 IOMMU SUPPORT
On Tue, Mar 01, 2022 at 03:49:18PM +0800, Yong Wu wrote: > https://patchwork.kernel.org/project/linux-mediatek/list/?series=592275 Okay, thanks for the clarification. So I can't include linux-next in my tree, so I think the best option is to wait until v5.18-rc1 (or rather -rc3, which is where I start merging new stuff) is out and merge it then. Another option would be if there is a branch which only contains the dependencies of this patch-set, which I could pull into my tree, but it is already pretty late in the cycle. So please re-send when the next -rc1 is out and I will pick it up then. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] iommu/vt-d: Fix double list_add when enabling VMD in scalable mode
On Mon, Feb 21, 2022 at 01:33:48PM +0800, Lu Baolu wrote:
> Fixes: 474dd1c65064 ("iommu/vt-d: Fix clearing real DMA device's
> scalable-mode context entries")
> Cc: sta...@vger.kernel.org # v5.14+
> Signed-off-by: Adrian Huang
> Link: https://lore.kernel.org/r/20220216091307.703-1-adrianhuang0...@gmail.com
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied for v5.17, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 0/5] iommu/amd: Cleanup and fixes
On Mon, Feb 21, 2022 at 10:29:11AM +0530, Vasant Hegde wrote: > This series contains various cleanup and trivial fixes. > > Suravee Suthikulpanit (2): > iommu/amd: Improve error handling for amd_iommu_init_pci > iommu/amd: Improve amd_iommu_v2_exit() > > Vasant Hegde (3): > iommu/amd: Call memunmap in error path > iommu/amd: Clean up function declarations > iommu/amd: Remove unused struct fault.devid > > drivers/iommu/amd/amd_iommu.h | 4 > drivers/iommu/amd/init.c | 16 > drivers/iommu/amd/iommu_v2.c | 35 +-- > 3 files changed, 29 insertions(+), 26 deletions(-) Besides the error messages in the first patch this looks good to me. Please re-send with the updates and I consider it for v5.18. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/5] iommu/amd: Improve error handling for amd_iommu_init_pci
On Mon, Feb 21, 2022 at 10:29:12AM +0530, Vasant Hegde wrote:
> From: Suravee Suthikulpanit
>
> Add error messages to prevent silent failure.
>
> Signed-off-by: Suravee Suthikulpanit
> Signed-off-by: Vasant Hegde
> ---
> drivers/iommu/amd/init.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> index 1eacd43cb436..770ac679b682 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -1942,9 +1942,10 @@ static int __init amd_iommu_init_pci(void)
>
> for_each_iommu(iommu) {
> ret = iommu_init_pci(iommu);
> - if (ret)
> - break;
> -
> + if (ret) {
> + pr_err("IOMMU:%d Failed to initialize!\n",
> iommu->index);
Please make that message "IOMMU%d: Failed to initialize IOMMU Hardware
(error=%d)!\n".
> + goto out;
> + }
> /* Need to setup range after PCI init */
> iommu_set_cwwb_range(iommu);
> }
> @@ -1960,6 +1961,10 @@ static int __init amd_iommu_init_pci(void)
>* active.
>*/
> ret = amd_iommu_init_api();
> + if (ret) {
> + pr_err("IOMMU: Failed to initialize api!\n");
And that "IOMMU: Failed to initialize IOMMU-API interface (error=%d)!\n"
> + goto out;
> + }
>
> init_device_table_dma();
>
> @@ -1969,6 +1974,7 @@ static int __init amd_iommu_init_pci(void)
> if (!ret)
> print_iommu_info();
>
> +out:
> return ret;
> }
>
> --
> 2.27.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 00/34] MT8195 IOMMU SUPPORT
Hi Yong Wu, On Thu, Feb 17, 2022 at 07:34:19PM +0800, Yong Wu wrote: > Yong Wu (34): > dt-bindings: mediatek: mt8195: Add binding for MM IOMMU > dt-bindings: mediatek: mt8195: Add binding for infra IOMMU > iommu/mediatek: Fix 2 HW sharing pgtable issue > iommu/mediatek: Add list_del in mtk_iommu_remove > iommu/mediatek: Remove clk_disable in mtk_iommu_remove > iommu/mediatek: Add mutex for m4u_group and m4u_dom in data > iommu/mediatek: Add mutex for data in the mtk_iommu_domain > iommu/mediatek: Adapt sharing and non-sharing pgtable case > iommu/mediatek: Add 12G~16G support for multi domains > iommu/mediatek: Add a flag DCM_DISABLE > iommu/mediatek: Add a flag NON_STD_AXI > iommu/mediatek: Remove the granule in the tlb flush > iommu/mediatek: Always enable output PA over 32bits in isr > iommu/mediatek: Add SUB_COMMON_3BITS flag > iommu/mediatek: Add IOMMU_TYPE flag > iommu/mediatek: Contain MM IOMMU flow with the MM TYPE > iommu/mediatek: Adjust device link when it is sub-common > iommu/mediatek: Allow IOMMU_DOMAIN_UNMANAGED for PCIe VFIO > iommu/mediatek: Add a PM_CLK_AO flag for infra iommu > iommu/mediatek: Add infra iommu support > iommu/mediatek: Add PCIe support > iommu/mediatek: Add mt8195 support > iommu/mediatek: Only adjust code about register base > iommu/mediatek: Just move code position in hw_init > iommu/mediatek: Separate mtk_iommu_data for v1 and v2 > iommu/mediatek: Remove mtk_iommu.h > iommu/mediatek-v1: Just rename mtk_iommu to mtk_iommu_v1 > iommu/mediatek: Add mtk_iommu_bank_data structure > iommu/mediatek: Initialise bank HW for each a bank > iommu/mediatek: Change the domid to iova_region_id > iommu/mediatek: Get the proper bankid for multi banks > iommu/mediatek: Initialise/Remove for multi bank dev > iommu/mediatek: Backup/restore regsiters for multi banks > iommu/mediatek: mt8195: Enable multi banks for infra iommu This doesn't apply cleanly, can you please send a version rebased to v5.17-rc4? Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 0/9] iommu cleanup and refactoring
On Wed, Feb 16, 2022 at 10:52:40AM +0800, Lu Baolu wrote: > Lu Baolu (9): > iommu/vt-d: Remove guest pasid related callbacks > iommu: Remove guest pasid related interfaces and definitions > iommu/vt-d: Remove aux-domain related callbacks > iommu: Remove aux-domain related interfaces and iommu_ops > iommu: Remove apply_resv_region > drm/nouveau/device: Get right pgsize_bitmap of iommu_domain > iommu: Use right way to retrieve iommu_ops > iommu: Remove unused argument in is_attach_deferred > iommu: Split struct iommu_ops Applied to core branch, thanks Baolu! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/tegra-smmu: Fix missing put_device() call in tegra_smmu_find
On Fri, Jan 07, 2022 at 08:09:11AM +, Miaoqian Lin wrote:
> The reference taken by 'of_find_device_by_node()' must be released when
> not needed anymore.
> Add the corresponding 'put_device()' in the error handling path.
>
> Fixes: 765a9d1d02b2 ("iommu/tegra-smmu: Fix mc errors on tegra124-nyan")
> Signed-off-by: Miaoqian Lin
> ---
> drivers/iommu/tegra-smmu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied for v5.17, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit
On Mon, Feb 07, 2022 at 03:02:48PM -0800, Fenghua Yu wrote: > PASIDs are process wide. It was attempted to use refcounted PASIDs to > free them when the last thread drops the refcount. This turned out to > be complex and error prone. Given the fact that the PASID space is 20 > bits, which allows up to 1M processes to have a PASID associated > concurrently, PASID resource exhaustion is not a realistic concern. > > Therefore it was decided to simplify the approach and stick with lazy > on demand PASID allocation, but drop the eager free approach and make > a allocated PASID lifetime bound to the life time of the process. > > Get rid of the refcounting mechanisms and replace/rename the interfaces > to reflect this new approach. > > Suggested-by: Dave Hansen > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck Acked-by: Joerg Roedel ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 00/10] iommu cleanup and refactoring
Hi Baolu, On Tue, Feb 15, 2022 at 10:05:42AM +0800, Lu Baolu wrote: > Do you want me to send a new version with below changes: > > - Remove WARN_ON() in dev_iommu_ops(); > - Merge above two patches. > > Or, you can change above yourself? Please make the changes and send a new version. I will apply it to the iommu core branch then. The build-tests with this patch-set went well and I havn't spotted anything else in my review, so I think it is in good shape for linux-next testing. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 5/8] iommu/amd: Use iommu_attach/detach_device()
On Mon, Feb 14, 2022 at 11:00:59AM -0400, Jason Gunthorpe wrote: > On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote: > > > Device drivers calling into iommu_attach_device() is seldom a good > > idea. In this case the sound device has some generic hardware > > interface so that an existing sound driver can be re-used. Making this > > driver call iommu-specific functions for some devices is something hard > > to justify. > > Er, so this is transparent to the generic sound device? I guess > something fixed up the dma_api on that device to keep working? Right, this is completly transparent to the sound device. The IOMMU code will not set dma_ops on the device because it uses a direct mapping and so the standard implementation will be used. > But, then, the requirement is that nobody is using the dma API when we > make this change? That is the tricky part. DMA-API keeps working after the change is made, because the new domain is also direct mapped. The new domain just has the ability to assign host page-tables to device PASIDs, so that DMA requests with a PASID TLP will be remapped. It was actually a requirement for this code that when it jumps in, the DMA-API mappings stay live. And the reason a direct mapping is used at all is that the page-table walker of the IOMMU is a two-dimensional walker, which will treat the addresses found in the host page-tables as IO-virtual an translates them through the underlying page-table. So to use host-pagetables the underlying mapping must be direct mapped. > I don't think it matters how big/small the group is, only that when we > change the domain we know everything flowing through the domain is > still happy. Yes, that matters. The group size matters too for DMA-API performance. If two devices compete for the same lock in the allocator and/or the same cached magazines, things will slow down. That only matters for high-throughput devices, but still... Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 3/8] iommu: Extend iommu_at[de]tach_device() for multi-device groups
On Mon, Feb 14, 2022 at 11:46:26AM -0400, Jason Gunthorpe wrote: > On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote: > > > Arguably, iommu_attach_device() could be renamed something like > > iommu_attach_group_for_dev(), since that's effectively the semantic that all > > the existing API users want anyway (even VFIO at the high level - the group > > is the means for the user to assign their GPU/NIC/whatever device to their > > process, not the end in itself). That's just a lot more churn. > > Right Okay, good point. I can live with an iommu_attach_group_for_dev() interface, it is still better than making iommu_attach_device() silently operate on whole groups. > VFIO needs them because its uAPI is tied, but even so we keep talking > about ways to narrow the amount of group API it consumes. > > We should not set the recommended/good kAPI based on VFIOs uAPI > design. Agree here too. The current way groups are implemented can be turned into a VFIO specific interface to keep its semantics and kABI. But the IOMMU core code still needs the concept of alias groups. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] iommu/iova: Separate out rcache init
On Thu, Feb 03, 2022 at 05:59:20PM +0800, John Garry wrote: > Currently the rcache structures are allocated for all IOVA domains, even if > they do not use "fast" alloc+free interface. This is wasteful of memory. > > In addition, fails in init_iova_rcaches() are not handled safely, which is > less than ideal. > > Make "fast" users call a separate rcache init explicitly, which includes > error checking. > > Signed-off-by: John Garry Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 3/8] iommu: Extend iommu_at[de]tach_device() for multi-device groups
On Mon, Feb 14, 2022 at 09:03:13AM -0400, Jason Gunthorpe wrote: > Groups should disappear into an internal implementation detail, not be > so prominent in the API. Not going to happen, IOMMU groups are ABI and todays device assignment code, including user-space, relies on them. Groups implement and important aspect of hardware IOMMUs that the API can not abstract away: That there are devices which share the same request-id. This is not an issue for devices concerned by iommufd, but for legacy device assignment it is. The IOMMU-API needs to handle both in a clean API, even if it means that drivers need to lookup the sub-group of a device first. And I don't see how a per-device API can handle both in a device-centric way. For sure it is not making it 'device centric but operate on groups under the hood'. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 5/8] iommu/amd: Use iommu_attach/detach_device()
On Mon, Feb 14, 2022 at 10:02:36AM -0400, Jason Gunthorpe wrote: > That works for VFIO, but it doesn't work for other in-kernel > drivers.. Is there something ensuring the group is only the GPU and > sound device? Is the GPU never an addin card? GPUs supporting this functionality are always iGPUs, AFAIK. > I'd say the right way to code this after Lu's series to have both the > GPU and sound driver call iommu_attach_device() during their probe()'s > and specify the identity domain as the attaching domain. > > That would be quite similar to how the Tegra drivers got arranged. > > And then maybe someone could better guess what the "sound driver" is > since it would be marked with an iommu_attach_device() call. Device drivers calling into iommu_attach_device() is seldom a good idea. In this case the sound device has some generic hardware interface so that an existing sound driver can be re-used. Making this driver call iommu-specific functions for some devices is something hard to justify. With sub-groups on the other hand it would be a no-brainer, because the sound device would be in a separate sub-group. Basically any device in the same group as the GPU would be in a separate sub-group. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 00/10] iommu cleanup and refactoring
On Mon, Feb 14, 2022 at 09:55:28AM +0800, Lu Baolu wrote: > v3: > - Remove ops check when dev_iommu_ops() is used. > - This version of series is available on github: >https://github.com/LuBaolu/intel-iommu/commits/iommu-domain-ops-v3 > > Lu Baolu (10): > 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: Use dev_iommu_ops() helper > iommu: Split struct iommu_ops Really cool, thanks for doing this, Baolu! I am currently running some tests on this series to make sure there are no build breakages. And I agree with Jason that: iommu: Use right way to retrieve iommu_ops and iommu: Use dev_iommu_ops() helper can be combined into one patch. Splitting iommu_ops was something I have been thinking about for some time, so thanks again for doing this. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 5/8] iommu/amd: Use iommu_attach/detach_device()
On Mon, Feb 14, 2022 at 09:15:44AM -0400, Jason Gunthorpe wrote: > But how does the sound device know that this has been done to it? > > eg how do we know the sound device hasn't been bound to VFIO or > something at this point? The iommu_attach_group() call will fail when the group (which includes GPU and sound device) it not in its default-domain. So if VFIO attached the group to its own domain, there is a failure in this init function. Note that this function is intended to be called by the driver currently controling this device, so there should also be no race with VFIO trying to grab the device in parallel. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/1] iommu/vt-d: Move intel_iommu_ops to header file
On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote: > diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h > index 69230fd695ea..1036c1900b5c 100644 > --- a/include/linux/intel-iommu.h > +++ b/include/linux/intel-iommu.h > @@ -813,6 +813,8 @@ bool context_present(struct context_entry *context); > struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus, >u8 devfn, int alloc); > > +extern const struct iommu_ops intel_iommu_ops; > + The intel_iommu_ops symbol is only used in drivers/iommu/intel, so I would prefer a header in that directory. But I leave that up to Baolu to decide. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/msm: simplify with dev_err_probe()
On Sun, Feb 06, 2022 at 09:29:45PM +0100, David Heidelberg wrote: > Use the dev_err_probe() helper to simplify error handling during probe. > This also handle scenario, when EDEFER is returned and useless error is > printed. > > Fixes warnings as: > msm_iommu 750.iommu: could not get smmu_pclk > > Signed-off-by: David Heidelberg > --- > drivers/iommu/msm_iommu.c | 24 ++-- > 1 file changed, 10 insertions(+), 14 deletions(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/rockchip: : Use standard driver registration
On Fri, Feb 04, 2022 at 10:34:05PM +0100, Heiko Stuebner wrote: > Am Freitag, 4. Februar 2022, 21:16:41 CET schrieb Robin Murphy: > > It's been a long time since there was any reason to register IOMMU > > drivers early. Convert to the standard platform driver helper. > > > > CC: Heiko Stuebner > > Signed-off-by: Robin Murphy > > Reviewed-by: Heiko Stuebner Applied both, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: Remove trivial ops->capable implementations
On Thu, Feb 10, 2022 at 12:29:05PM +, Robin Murphy wrote: > Implementing ops->capable to always return false is pointless since it's > the default behaviour anyway. Clean up the unnecessary implementations. > > Signed-off-by: Robin Murphy > --- > > Spinning this out of my bus ops stuff (currently 30 patches and > counting...) since it would be better off alongside Baolu's cleanup > series to avoid conflicts, and I want to depend on those patches for > dev_iommu_ops() anyway. > > drivers/iommu/msm_iommu.c | 6 -- > drivers/iommu/tegra-gart.c | 6 -- > drivers/iommu/tegra-smmu.c | 6 -- > 3 files changed, 18 deletions(-) Applied, thanks Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/2] iommu/ipmmu-vmsa: Add support for R-Car Gen4
On Tue, Feb 08, 2022 at 09:20:28AM +0900, Yoshihiro Shimoda wrote: > This patch series is based on renesas-drivers-2022-01-11-v5.16 [1]. > Note that we have to prepare the following registers' setting > in a bootloader (U-Boot) because the registers are protected. > Otherwise, data mismatch happened if dmatest with the ipmmu is running. > > => mw eed01500 0xc000; mw eed41500 0xc000 > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tag/?h=renesas-drivers-2022-01-11-v5.16 > > Changes from v2: > - Add Reviewed-by tag in patch 1 and 2 (Geert-san, thanks!) > - Revise commit description in patch 1. > > https://lore.kernel.org/all/20220204125653.1194249-1-yoshihiro.shimoda...@renesas.com/ > > Changes from v1: > - Add Reviewed-by tag in patch 1. (Geert-san, thanks!) > - Revise a comment in patch 2. > > https://lore.kernel.org/all/20220125125602.4144793-1-yoshihiro.shimoda...@renesas.com/ > > Y > > Yoshihiro Shimoda (2): > dt-bindings: iommu: renesas,ipmmu-vmsa: add r8a779f0 support > iommu/ipmmu-vmsa: Add support for R-Car Gen4 Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 06/10] drm/nouveau/device: Get right pgsize_bitmap of iommu_domain
On Mon, Feb 14, 2022 at 09:55:34AM +0800, Lu Baolu wrote: > The supported page sizes of an iommu_domain are saved in the pgsize_bitmap > field. Retrieve the value from the right place. > > Signed-off-by: Lu Baolu > Reviewed-by: Robin Murphy > Link: > https://lore.kernel.org/r/20211218074546.1772553-1-baolu...@linux.intel.com > Reviewed-by: Christoph Hellwig > Reviewed-by: Jason Gunthorpe Acked-by: Joerg Roedel I guess this is picked up by the DRM maintainers? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 07/10] iommu: Use right way to retrieve iommu_ops
On Mon, Feb 14, 2022 at 09:55:35AM +0800, Lu Baolu wrote:
> +static inline const struct iommu_ops *dev_iommu_ops(struct device *dev)
> +{
> + /*
> + * Assume that valid ops must be installed if iommu_probe_device()
> + * has succeeded. The device ops are essentially for internal use
> + * within the IOMMU subsystem itself, so we should be able to trust
> + * ourselves not to misuse the helper.
> + */
> + WARN_ON(!dev || !dev->iommu || !dev->iommu->iommu_dev ||
> + !dev->iommu->iommu_dev->ops);
There is no need for this WARN_ON, the code will oops anyway when one of
the pointers checked here is NULL.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/ipmmu-vmsa: Check for error num after setting mask
On Mon, Feb 14, 2022 at 12:32:21PM +, Robin Murphy wrote: > In this particular case it cannot fail on any system the driver actually > runs on - it's a platform device so the dma_mask pointer is always > initialised, then dma_direct_supported() on arm64 will always return true > for any mask wider than 32 bits, while arm_dma_supported() will also always > pass since a 32-bit system cannot have memory above 40 bits either. > > There's no great harm in adding the check for the sake of consistency, I > guess, but it's purely cosmetic and not fixing anything. Okay, thanks Robin and Nikita for looking to quickly into this. I will apply it for 5.18 just to be on the safe side if the above assumptions change. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] IOMMU: Intel: DMAR: Replace acpi_bus_get_device()
On Tue, Feb 01, 2022 at 07:11:40PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Replace acpi_bus_get_device() that is going to be dropped with > acpi_fetch_acpi_dev(). > > No intentional functional impact. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/iommu/intel/dmar.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied with adjusted subject, thanks Rafael. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Fix I/O page table memory leak
On Thu, Feb 10, 2022 at 09:47:45AM -0600, Suravee Suthikulpanit wrote:
> The current logic updates the I/O page table mode for the domain
> before calling the logic to free memory used for the page table.
> This results in IOMMU page table memory leak, and can be observed
> when launching VM w/ pass-through devices.
>
> Fix by freeing the memory used for page table before updating the mode.
>
> Cc: Joerg Roedel
> Reported-by: Daniel Jordan
> Tested-by: Daniel Jordan
> Signed-off-by: Suravee Suthikulpanit
> Fixes: e42ba0633064 ("iommu/amd: Restructure code for freeing page table")
> Link: https://lore.kernel.org/all/20220118194720.urjgi73b7c3tq...@oracle.com/
> ---
> drivers/iommu/amd/io_pgtable.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/ipmmu-vmsa: Check for error num after setting mask
Adding more potential reviewers.
On Thu, Jan 06, 2022 at 10:43:02AM +0800, Jiasheng Jiang wrote:
> Because of the possible failure of the dma_supported(), the
> dma_set_mask_and_coherent() may return error num.
> Therefore, it should be better to check it and return the error if
> fails.
>
> Fixes: 1c894225bf5b ("iommu/ipmmu-vmsa: IPMMU device is 40-bit bus master")
> Signed-off-by: Jiasheng Jiang
> ---
> drivers/iommu/ipmmu-vmsa.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index aaa6a4d59057..7df5da44a004 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -1003,7 +1003,9 @@ static int ipmmu_probe(struct platform_device *pdev)
> bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
> mmu->features = of_device_get_match_data(>dev);
> memset(mmu->utlb_ctx, IPMMU_CTX_INVALID, mmu->features->num_utlbs);
> - dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(40));
> + ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(40));
> + if (ret)
> + return ret;
>
> /* Map I/O memory and request IRQ. */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> --
> 2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 3/8] iommu: Extend iommu_at[de]tach_device() for multi-device groups
On Thu, Jan 06, 2022 at 10:20:48AM +0800, Lu Baolu wrote:
> int iommu_attach_device(struct iommu_domain *domain, struct device *dev)
> {
> struct iommu_group *group;
> - int ret;
> + int ret = 0;
> +
> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
> + return -EINVAL;
>
> group = iommu_group_get(dev);
> if (!group)
> return -ENODEV;
>
> - /*
> - * Lock the group to make sure the device-count doesn't
> - * change while we are attaching
> - */
> mutex_lock(>mutex);
> - ret = -EINVAL;
> - if (iommu_group_device_count(group) != 1)
> - goto out_unlock;
> + if (group->owner_cnt) {
> + /*
> + * Group has been used for kernel-api dma or claimed explicitly
> + * for exclusive occupation. For backward compatibility, device
> + * in a singleton group is allowed to ignore setting the
> + * drv.no_kernel_api_dma field.
> + */
> + if ((group->domain == group->default_domain &&
> + iommu_group_device_count(group) != 1) ||
> + group->owner) {
> + ret = -EBUSY;
> + goto unlock_out;
> + }
> + }
>
> - ret = __iommu_attach_group(domain, group);
> + if (!group->attach_cnt) {
> + ret = __iommu_attach_group(domain, group);
> + if (ret)
> + goto unlock_out;
> + } else {
> + if (group->domain != domain) {
> + ret = -EPERM;
> + goto unlock_out;
> + }
> + }
>
> -out_unlock:
> + group->owner_cnt++;
> + group->attach_cnt++;
> +
> +unlock_out:
> mutex_unlock(>mutex);
> iommu_group_put(group);
This extends iommu_attach_device() to behave as iommu_attach_group(),
changing the domain for the whole group. Wouldn't it be better to scrap
the iommu_attach_device() interface instead and only rely on
iommu_attach_group()? This way it is clear that a call changes the whole
group.
IIUC this work is heading towards allowing multiple domains in one group
as long as the group is owned by one entity. That is a valid
requirement, but the way to get there is in my eyes:
1) Introduce a concept of a sub-group (or whatever we want to
call it), which groups devices together which must be in the
same domain because they use the same request ID and thus
look all the same to the IOMMU.
2) Keep todays IOMMU groups to group devices together which can
bypass the IOMMU when talking to each other, like
multi-function devices and devices behind a no-ACS bridge.
3) Rework group->domain and group->default_domain, eventually
moving them to sub-groups.
This is an important distinction to make and also the reason the
iommu_attach/detach_device() interface will always be misleading. Item
1) in this list will also be beneficial to other parts of the iommu
code, namely iommu-dma code which can have finer-grained DMA-API domains
with sub-groups instead of groups.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 5/8] iommu/amd: Use iommu_attach/detach_device()
On Thu, Jan 06, 2022 at 10:33:45AM -0400, Jason Gunthorpe wrote: > But I'm not sure how this can work with multi-device groups - this > seems to assigns a domain setup for direct map, so perhaps this only > works if all devices are setup for direct map? Right, at boot all devices in this group are already setup for using a direct map. There are usually two devices in those groups, the GPU itself and the sound device for HDMI sound output. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] iommu/vt-d: Fix PCI bus rescan device hot add
Hi Jacob, On Wed, Feb 09, 2022 at 01:52:49PM -0800, Jacob Pan wrote: > Another option Ashok and I discussed is that we can make DMAR cache persist > (which should be for explicitly listed devices in each DRHD) across PCI > remove-rescan cycle, then we don't need the DMAR PCI bus notifier at all. > > This bug only impacts RCIEP device hotplug, which is not the most reasonable > use case, we have the space to look into a proper fix. Even better if you can make the notifier obsolete. Looking forward to the fix. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[git pull] IOMMU Fixes for Linux v5.17-rc2
Hi Linus, The following changes since commit 26291c54e111ff6ba87a164d85d4a4e134b7315c: Linux 5.17-rc2 (2022-01-30 15:37:07 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v5.17-rc2 for you to fetch changes up to 9b45a7738eec52bf0f5d8d3d54e822962781c5f2: iommu/amd: Fix loop timeout issue in iommu_ga_log_enable() (2022-02-04 12:57:26 +0100) IOMMU Fixes for Linux v5.17-rc2 Including: - Warning fixes and a fix for a potential use-after-free in IOMMU core code - Another potential memory leak fix for the Intel VT-d driver - Fix for an IO polling loop timeout issue in the AMD IOMMU driver Guoqing Jiang (1): iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping() Joerg Roedel (1): iommu/amd: Fix loop timeout issue in iommu_ga_log_enable() John Garry (1): iommu: Fix some W=1 warnings Vijayanand Jitta (1): iommu: Fix potential use-after-free during probe drivers/iommu/amd/init.c| 2 ++ drivers/iommu/intel/irq_remapping.c | 13 ++--- drivers/iommu/ioasid.c | 1 + drivers/iommu/iommu.c | 33 +++-- drivers/iommu/omap-iommu.c | 2 +- 5 files changed, 33 insertions(+), 18 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
[PATCH v2] iommu/amd: Fix loop timeout issue in iommu_ga_log_enable()
From: Joerg Roedel
The polling loop for the register change in iommu_ga_log_enable() needs
to have a udelay() in it. Otherwise the CPU might be faster than the
IOMMU hardware and wrongly trigger the WARN_ON() further down the code
stream. Use a 10us for udelay(), has there is some hardware where
activation of the GA log can take more than a 100ms.
A future optimization should move the activation check of the GA log
to the point where it gets used for the first time. But that is a
bigger change and not suitable for a fix.
Fixes: 8bda0cfbdc1a ("iommu/amd: Detect and initialize guest vAPIC log")
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd/init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index dc338acf3338..b10fb52ea442 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -834,6 +835,7 @@ static int iommu_ga_log_enable(struct amd_iommu *iommu)
status = readl(iommu->mmio_base + MMIO_STATUS_OFFSET);
if (status & (MMIO_STATUS_GALOG_RUN_MASK))
break;
+ udelay(10);
}
if (WARN_ON(i >= LOOP_TIMEOUT))
--
2.34.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
