[PATCH] iommu/amd: Increase timeout waiting for GA log enablement

2022-05-20 Thread Joerg Roedel
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

2022-05-20 Thread Joerg Roedel
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

2022-05-20 Thread Joerg Roedel
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()

2022-05-20 Thread Joerg Roedel
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

2022-05-20 Thread Joerg Roedel
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

2022-05-20 Thread Joerg Roedel
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

2022-05-20 Thread Joerg Roedel
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

2022-05-20 Thread Joerg Roedel
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

2022-05-19 Thread Joerg Roedel
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()

2022-05-13 Thread Joerg Roedel
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

2022-05-13 Thread Joerg Roedel
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

2022-05-13 Thread Joerg Roedel
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

2022-05-13 Thread Joerg Roedel
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

2022-05-13 Thread Joerg Roedel
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

2022-05-13 Thread Joerg Roedel
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

2022-05-13 Thread Joerg Roedel
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

2022-05-13 Thread Joerg Roedel
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

2022-05-04 Thread Joerg Roedel
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

2022-05-04 Thread Joerg Roedel
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()

2022-05-04 Thread Joerg Roedel
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")

2022-05-04 Thread Joerg Roedel
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

2022-05-04 Thread Joerg Roedel
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()

2022-05-04 Thread Joerg Roedel
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

2022-05-04 Thread Joerg Roedel
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

2022-05-04 Thread Joerg Roedel
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

2022-05-04 Thread Joerg Roedel
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

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

2022-04-28 Thread Joerg Roedel
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()

2022-04-28 Thread Joerg Roedel
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()

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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()

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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()

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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()

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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

2022-04-28 Thread Joerg Roedel
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()

2022-04-08 Thread Joerg Roedel
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()

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

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

2022-04-08 Thread Joerg Roedel
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()

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

2022-03-24 Thread Joerg Roedel
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

2022-03-08 Thread Joerg Roedel
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2022-02-15 Thread Joerg Roedel
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()

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

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

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

2022-02-14 Thread Joerg Roedel
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()

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

2022-02-14 Thread Joerg Roedel
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()

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

2022-02-14 Thread Joerg Roedel
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()

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

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

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

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

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

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

2022-02-14 Thread Joerg Roedel
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()

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

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

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

2022-02-14 Thread Joerg Roedel
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()

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

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

2022-02-04 Thread Joerg Roedel
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()

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


  1   2   3   4   5   6   7   8   9   10   >