kernel/git/stable/linux.git/drivers/iommu/amd/init.c, branch master

Merge branches 'apple/dart', 'arm/smmu/updates', 'arm/smmu/bindings', 'rockchip', 'verisilicon', 'riscv', 'intel/vt-d', 'amd/amd-vi' and 'core' into next

2026-06-12T12:57:23+00:00

iommu/amd: Fix premature break in init_iommu_one()

2026-05-28T07:28:58+00:00

In init_iommu_one(), when processing IOMMU EFR attributes, the code checks whether GASUP is enabled. If GASUP is not enabled, the code falls back to legacy guest IR mode and then breaks out of the switch statement. This break incorrectly skips the subsequent initialization steps that follow the GASUP check. These initializations are independent of GASUP support and must always be performed. Fix this by replacing the early break with a conditional else block, ensuring that the XTSUP check is only skipped when GASUP is not available. Fixes: a44092e326d4 ("iommu/amd: Use IVHD EFR for early initialization of IOMMU features") Reported-by: Sudheer Dantuluri Tested-by: Dheeraj Kumar Srivastava Signed-off-by: Vasant Hegde Signed-off-by: Joerg Roedel

iommu/amd: Adhere to IVINFO[VASIZE] for address limits

2026-05-19T08:49:03+00:00

ACPI IVRS IVHD’s IVINFO field reports the maximum virtual address size (VASIZE) supported by the IOMMU. The AMD IOMMU driver currently caps this with pagetable level reported by EFR[HATS] when configuring paging domains (hw_max_vasz_lg2). On systems where firmware or VM advertises smaller or different limits, the driver may over-advertise capabilities and create domains outside the hardware’s actual bounds. Reviewed-by: Jason Gunthorpe Reviewed-by: Vasant Hegde Signed-off-by: Ankit Soni Signed-off-by: Joerg Roedel

iommu/amd: Add support for Hygon family 18h model 4h IOAPIC

2026-05-11T07:42:56+00:00

The SB IOAPIC is on the device 0xb from Hygon family 18h model 4h. Signed-off-by: Fu Hao Tested-by: Tingyin Duan Signed-off-by: Joerg Roedel

iommu/amd: Remove dead code for exclusion ranges in IVMD

2026-05-11T07:36:51+00:00

Exclusion ranges in IVMD are treated as unity mappings with r&w permissions since commit 0bbe4ced53e3 ("iommu/amd: Fix the overwritten field in IVMD header"), using 1:1 mappings. And IOMMU Exclusion Base & Range Limit Registers (0x0020/0x0028) are actually no longer used. As a result, several definitions and code paths became dead code: - exclusion_start/exclusion_length in struct amd_iommu are never assigned, - iommu_set_exclusion_range() always returns 0 now. - MMIO_EXCL_ENABLE_MASK & MMIO_EXCL_ALLOW_MASK are only used by the removed iommu_set_exclusion_range(). - DEV_ENTRY_EX is no longer set in any DTE. - IOMMU_UNITY_MAP_FLAG_EXCL_RANGE is no longer set, thus the IOMMU_RESV_RESERVED branch in amd_iommu_get_resv_regions() is no longer reachable. Just remove all of the dead code. No functional change. Signed-off-by: Yu Zhang Reviewed-by: Suravee Suthikulpanit Reviewed-by: Jacob Pan Signed-off-by: Joerg Roedel

iommu/amd: Explicitly bail from enable_iommus_vapic() when in legacy mode

2026-05-11T07:31:20+00:00

Bail early from enable_iommus_vapic() if IOMMUs are configured for either of the legacy modes, as it's absurdly difficult to see that iommu_ga_log_enable() is guaranteed to fail because iommu_init_ga_log() skips allocating the ga_log. Opportunistically have iommu_ga_log_enable() WARN if it's called without IOMMUs being configured to support AVIC/vAPIC. Cc: Suravee Suthikulpanit Signed-off-by: Sean Christopherson Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel

iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family 0x19

2026-04-27T11:49:36+00:00

Due to CVE-2023-20585, the PPR log buffer must use the maximum supported size (512K) on Genoa (Family 0x19, model >= 0x10) systems when SNP is enabled, to mitigate a potential security vulnerability. Note that Family 0x19 models below 0x10 (Milan) do not support PPR when SNP is enabled. Hence the PPR log size increase is only applied for model >= 0x10. All other systems continue to use the default PPR log buffer size (8K). Apply the errata fix by making the following changes: - Introduce global new variable (amd_iommu_pprlog_size) to have PPR log buffer size. Adjust variable size for Genoa family. - Extend 'amd_iommu_apply_erratum_snp()' to also set the PPR log buffer size to maximum for Family 0x19 model >= 0x10 when SNP is enabled. - Rename PPR_* macros to make it more readable. Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html Cc: Borislav Petkov Cc: Suravee Suthikulpanit Cc: Joerg Roedel Signed-off-by: Vasant Hegde Tested-by: Dheeraj Kumar Srivastava Signed-off-by: Joerg Roedel

iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19

2026-04-27T11:49:16+00:00

Due to CVE-2023-20585, the Event log buffer must use the maximum supported size (512K) on Milan/Genoa (Family 0x19) systems when SNP is enabled, to mitigate a potential security vulnerability. All other systems continue to use the default Event log buffer size (8K). Apply the errata fix by making the following changes: * Introduce new global variable (amd_iommu_evtlog_size) to have event log buffer size. Adjust variable size for family 0x19. * Since 'iommu_snp_enable()' must be called after the core IOMMU subsystem is initialized, it cannot be moved to the early init stage. The SNP errata must also be applied after the 'iommu_snp_enable()' check. Therefore, 'alloc_event_buffer()' and 'iommu_enable_event_buffer()' are now called in the IOMMU_ENABLED state, after the errata is applied. * Adjust alloc_event_buffer() and iommu_enable_event_buffer() to handle all IOMMU instances. * Also rename EVT_* macros to make it more readable. Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html Cc: Borislav Petkov Cc: Suravee Suthikulpanit Cc: Joerg Roedel Signed-off-by: Vasant Hegde Tested-by: Dheeraj Kumar Srivastava Signed-off-by: Joerg Roedel

iommu/amd: Add NUMA node affinity for IOMMU log buffers

2026-03-17T12:26:38+00:00

Currently, PPR Log and GA logs for AMD IOMMU are allocated using iommu_alloc_pages_sz(), which does not account for NUMA affinity. This can lead to remote memory access latencies if the memory is allocated on a different node than the IOMMU hardware. Switch to iommu_alloc_pages_node_sz() to ensure that these data structures are allocated on the same NUMA node as the IOMMU device. If the node information is unavailable, it defaults to NUMA_NO_NODE. Signed-off-by: Li RongQing Reviewed-by: Vasant Hegde Reviewed-by: Ankit Soni Signed-off-by: Joerg Roedel

Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses

2026-02-22T16:26:33+00:00

Conversion performed via this Coccinelle script: // SPDX-License-Identifier: GPL-2.0-only // Options: --include-headers-for-types --all-includes --include-headers --keep-comments virtual patch @gfp depends on patch && !(file in "tools") && !(file in "samples")@ identifier ALLOC = {kmalloc_obj,kmalloc_objs,kmalloc_flex, kzalloc_obj,kzalloc_objs,kzalloc_flex, kvmalloc_obj,kvmalloc_objs,kvmalloc_flex, kvzalloc_obj,kvzalloc_objs,kvzalloc_flex}; @@ ALLOC(... - , GFP_KERNEL ) $ make coccicheck MODE=patch COCCI=gfp.cocci Build and boot tested x86_64 with Fedora 42's GCC and Clang: Linux version 6.19.0+ (user@host) (gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7), GNU ld version 2.44-12.fc42) #1 SMP PREEMPT_DYNAMIC 1970-01-01 Linux version 6.19.0+ (user@host) (clang version 20.1.8 (Fedora 20.1.8-4.fc42), LLD 20.1.8) #1 SMP PREEMPT_DYNAMIC 1970-01-01 Signed-off-by: Kees Cook Signed-off-by: Linus Torvalds