<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/iommu/amd, branch v5.15.208</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.208'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-01-19T12:10:13+00:00</updated>
<entry>
<title>Revert "iommu/amd: Skip enabling command/event buffers for kdump"</title>
<updated>2026-01-19T12:10:13+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2026-01-09T10:48:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f3cc921c237c04ee832516ac0cb002da89dec6d0'/>
<id>urn:sha1:f3cc921c237c04ee832516ac0cb002da89dec6d0</id>
<content type='text'>
This reverts commit bb8f9de71c9bd442ec5e1d52ce830428860892f0 which is
commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb upstream.

This causes problems in older kernel trees as SNP host kdump is not
supported in them, so drop it from the stable branches.

Reported-by: Ashish Kalra &lt;ashish.kalra@amd.com&gt;
Link: https://lore.kernel.org/r/dacdff7f-0606-4ed5-b056-2de564404d51@amd.com
Cc: Vasant Hegde &lt;vasant.hegde@amd.com&gt;
Cc: Sairaj Kodilkar &lt;sarunkod@amd.com&gt;
Cc: Joerg Roedel &lt;joerg.roedel@amd.com&gt;
Cc: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Skip enabling command/event buffers for kdump</title>
<updated>2025-12-06T21:09:21+00:00</updated>
<author>
<name>Ashish Kalra</name>
<email>ashish.kalra@amd.com</email>
</author>
<published>2025-08-25T21:46:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bb8f9de71c9bd442ec5e1d52ce830428860892f0'/>
<id>urn:sha1:bb8f9de71c9bd442ec5e1d52ce830428860892f0</id>
<content type='text'>
[ Upstream commit 9be15fbfc6c5c89c22cf6e209f66ea43ee0e58bb ]

After a panic if SNP is enabled in the previous kernel then the kdump
kernel boots with IOMMU SNP enforcement still enabled.

IOMMU command buffers and event buffer registers remain locked and
exclusive to the previous kernel. Attempts to enable command and event
buffers in the kdump kernel will fail, as hardware ignores writes to
the locked MMIO registers as per AMD IOMMU spec Section 2.12.2.1.

Skip enabling command buffers and event buffers for kdump boot as they
are already enabled in the previous kernel.

Reviewed-by: Vasant Hegde &lt;vasant.hegde@amd.com&gt;
Tested-by: Sairaj Kodilkar &lt;sarunkod@amd.com&gt;
Signed-off-by: Ashish Kalra &lt;ashish.kalra@amd.com&gt;
Link: https://lore.kernel.org/r/576445eb4f168b467b0fc789079b650ca7c5b037.1756157913.git.ashish.kalra@amd.com
Signed-off-by: Joerg Roedel &lt;joerg.roedel@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Add map/unmap_pages() iommu_domain_ops callback support</title>
<updated>2025-10-19T14:21:26+00:00</updated>
<author>
<name>Vasant Hegde</name>
<email>vasant.hegde@amd.com</email>
</author>
<published>2022-08-25T06:39:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9407809b44dc62e3ae81b3032aedbf5021370e3f'/>
<id>urn:sha1:9407809b44dc62e3ae81b3032aedbf5021370e3f</id>
<content type='text'>
commit 6b080c4e815ceba3c08ffa980c858595c07e786a upstream.

Implement the map_pages() and unmap_pages() callback for the AMD IOMMU
driver to allow calls from iommu core to map and unmap multiple pages.
Also deprecate map/unmap callbacks.

Finally gatherer is not updated by iommu_v1_unmap_pages(). Hence pass
NULL instead of gather to iommu_v1_unmap_pages.

Suggested-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Vasant Hegde &lt;vasant.hegde@amd.com&gt;
Link: https://lore.kernel.org/r/20220825063939.8360-4-vasant.hegde@amd.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
[ partial bacport of the original patch, just what is needed to fix a
  bug in 5.15.y only ]
Fixes: fc65d0acaf23 ("iommu/amd: Selective flush on unmap")
Signed-off-by: Zhichuang Sun &lt;zhichuang@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Avoid stack buffer overflow from kernel cmdline</title>
<updated>2025-08-28T14:24:37+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees@kernel.org</email>
</author>
<published>2025-08-04T15:40:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0ad8509b468fa1058f4f400a1829f29e4ccc4de8'/>
<id>urn:sha1:0ad8509b468fa1058f4f400a1829f29e4ccc4de8</id>
<content type='text'>
[ Upstream commit 8503d0fcb1086a7cfe26df67ca4bd9bd9e99bdec ]

While the kernel command line is considered trusted in most environments,
avoid writing 1 byte past the end of "acpiid" if the "str" argument is
maximum length.

Reported-by: Simcha Kosman &lt;simcha.kosman@cyberark.com&gt;
Closes: https://lore.kernel.org/all/AS8P193MB2271C4B24BCEDA31830F37AE84A52@AS8P193MB2271.EURP193.PROD.OUTLOOK.COM
Fixes: b6b26d86c61c ("iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameter")
Signed-off-by: Kees Cook &lt;kees@kernel.org&gt;
Reviewed-by: Ankit Soni &lt;Ankit.Soni@amd.com&gt;
Link: https://lore.kernel.org/r/20250804154023.work.970-kees@kernel.org
Signed-off-by: Joerg Roedel &lt;joerg.roedel@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Ensure GA log notifier callbacks finish running before module unload</title>
<updated>2025-06-27T10:05:32+00:00</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2025-03-15T03:10:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c9bfb30b75c35b072f52f35ec4af3221addab855'/>
<id>urn:sha1:c9bfb30b75c35b072f52f35ec4af3221addab855</id>
<content type='text'>
[ Upstream commit 94c721ea03c7078163f41dbaa101ac721ddac329 ]

Synchronize RCU when unregistering KVM's GA log notifier to ensure all
in-flight interrupt handlers complete before KVM-the module is unloaded.

Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Link: https://lore.kernel.org/r/20250315031048.2374109-1-seanjc@google.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid</title>
<updated>2025-05-09T07:39:37+00:00</updated>
<author>
<name>Pavel Paklov</name>
<email>Pavel.Paklov@cyberprotect.ru</email>
</author>
<published>2025-03-25T09:22:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=466d9da267079a8d3b69fa72dfa3a732e1f6dbb5'/>
<id>urn:sha1:466d9da267079a8d3b69fa72dfa3a732e1f6dbb5</id>
<content type='text'>
commit 8dee308e4c01dea48fc104d37f92d5b58c50b96c upstream.

There is a string parsing logic error which can lead to an overflow of hid
or uid buffers. Comparing ACPIID_LEN against a total string length doesn't
take into account the lengths of individual hid and uid buffers so the
check is insufficient in some cases. For example if the length of hid
string is 4 and the length of the uid string is 260, the length of str
will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer
which size is 256.

The same applies to the hid string with length 13 and uid string with
length 250.

Check the length of hid and uid strings separately to prevent
buffer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter")
Cc: stable@vger.kernel.org
Signed-off-by: Pavel Paklov &lt;Pavel.Paklov@cyberprotect.ru&gt;
Link: https://lore.kernel.org/r/20250325092259.392844-1-Pavel.Paklov@cyberprotect.ru
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Return an error if vCPU affinity is set for non-vCPU IRTE</title>
<updated>2025-05-02T05:44:30+00:00</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2025-04-04T19:38:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c71ab87a2523a996640801aa1fdcb2625ec1347f'/>
<id>urn:sha1:c71ab87a2523a996640801aa1fdcb2625ec1347f</id>
<content type='text'>
[ Upstream commit 07172206a26dcf3f0bf7c3ecaadd4242b008ea54 ]

Return -EINVAL instead of success if amd_ir_set_vcpu_affinity() is
invoked without use_vapic; lying to KVM about whether or not the IRTE was
configured to post IRQs is all kinds of bad.

Fixes: d98de49a53e4 ("iommu/amd: Enable vAPIC interrupt remapping mode by default")
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Message-ID: &lt;20250404193923.1413163-6-seanjc@google.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Fix sysfs leak in iommu init</title>
<updated>2024-07-05T07:14:17+00:00</updated>
<author>
<name>Kun(llfl)</name>
<email>llfl@linux.alibaba.com</email>
</author>
<published>2024-05-09T00:42:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=05a61b03a81fd9970e519b38de5b4814e7d9349f'/>
<id>urn:sha1:05a61b03a81fd9970e519b38de5b4814e7d9349f</id>
<content type='text'>
[ Upstream commit a295ec52c8624883885396fde7b4df1a179627c3 ]

During the iommu initialization, iommu_init_pci() adds sysfs nodes.
However, these nodes aren't remove in free_iommu_resources() subsequently.

Fixes: 39ab9555c241 ("iommu: Add sysfs bindings for struct iommu_device")
Signed-off-by: Kun(llfl) &lt;llfl@linux.alibaba.com&gt;
Reviewed-by: Suravee Suthikulpanit &lt;suravee.suthikulpanit@amd.com&gt;
Link: https://lore.kernel.org/r/c8e0d11c6ab1ee48299c288009cf9c5dae07b42d.1715215003.git.llfl@linux.alibaba.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Introduce pci segment structure</title>
<updated>2024-07-05T07:14:16+00:00</updated>
<author>
<name>Vasant Hegde</name>
<email>vasant.hegde@amd.com</email>
</author>
<published>2022-07-06T11:37:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d37895aeacdddb4890fa38d4728cb408ba18cd9e'/>
<id>urn:sha1:d37895aeacdddb4890fa38d4728cb408ba18cd9e</id>
<content type='text'>
[ Upstream commit 404ec4e4c169fb64da6b2a38b471c13ac0897c76 ]

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.

Current code assumes that system contains only one pci segment (segment 0)
and creates global data structures such as device table, rlookup table,
etc.

Introducing per PCI segment data structure, which contains segment
specific data structures. This will eventually replace the global
data structures.

Also update `amd_iommu-&gt;pci_seg` variable to point to PCI segment
structure instead of PCI segment ID.

Co-developed-by: Suravee Suthikulpanit &lt;suravee.suthikulpanit@amd.com&gt;
Signed-off-by: Suravee Suthikulpanit &lt;suravee.suthikulpanit@amd.com&gt;
Signed-off-by: Vasant Hegde &lt;vasant.hegde@amd.com&gt;
Link: https://lore.kernel.org/r/20220706113825.25582-3-vasant.hegde@amd.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Stable-dep-of: a295ec52c862 ("iommu/amd: Fix sysfs leak in iommu init")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>iommu/amd: Mark interrupt as managed</title>
<updated>2024-03-26T22:21:19+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2024-01-22T23:34:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b96bc1b25963e23615a81a238d61d812f32af42f'/>
<id>urn:sha1:b96bc1b25963e23615a81a238d61d812f32af42f</id>
<content type='text'>
[ Upstream commit 0feda94c868d396fac3b3cb14089d2d989a07c72 ]

On many systems that have an AMD IOMMU the following sequence of
warnings is observed during bootup.

```
pci 0000:00:00.2  can't derive routing for PCI INT A
pci 0000:00:00.2: PCI INT A: not connected
```

This series of events happens because of the IOMMU initialization
sequence order and the lack of _PRT entries for the IOMMU.

During initialization the IOMMU driver first enables the PCI device
using pci_enable_device().  This will call acpi_pci_irq_enable()
which will check if the interrupt is declared in a PCI routing table
(_PRT) entry. According to the PCI spec [1] these routing entries
are only required under PCI root bridges:
	The _PRT object is required under all PCI root bridges

The IOMMU is directly connected to the root complex, so there is no
parent bridge to look for a _PRT entry. The first warning is emitted
since no entry could be found in the hierarchy. The second warning is
then emitted because the interrupt hasn't yet been configured to any
value.  The pin was configured in pci_read_irq() but the byte in
PCI_INTERRUPT_LINE return 0xff which means "Unknown".

After that sequence of events pci_enable_msi() is called and this
will allocate an interrupt.

That is both of these warnings are totally harmless because the IOMMU
uses MSI for interrupts.  To avoid even trying to probe for a _PRT
entry mark the IOMMU as IRQ managed. This avoids both warnings.

Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration.html?highlight=_prt#prt-pci-routing-table [1]
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Fixes: cffe0a2b5a34 ("x86, irq: Keep balance of IOAPIC pin reference count")
Reviewed-by: Vasant Hegde &lt;vasant.hegde@amd.com&gt;
Link: https://lore.kernel.org/r/20240122233400.1802-1-mario.limonciello@amd.com
Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
