<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/Documentation/arch/arm64, branch master</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux</title>
<updated>2026-04-20T23:46:22+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-04-20T23:46:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=13f24586a292e35c9cc71e649dc4e4ea1895c5e5'/>
<id>13f24586a292e35c9cc71e649dc4e4ea1895c5e5</id>
<content type='text'>
Pull more arm64 updates from Catalin Marinas:
 "The main 'feature' is a workaround for C1-Pro erratum 4193714
  requiring IPIs during TLB maintenance if a process is running in user
  space with SME enabled.

  The hardware acknowledges the DVMSync messages before completing
  in-flight SME accesses, with security implications. The workaround
  makes use of the mm_cpumask() to track the cores that need
  interrupting (arm64 hasn't used this mask before).

  The rest are fixes for MPAM, CCA and generated header that turned up
  during the merging window or shortly before.

  Summary:

  Core features:

   - Add workaround for C1-Pro erratum 4193714 - early CME (SME unit)
     DVMSync acknowledgement. The fix consists of sending IPIs on TLB
     maintenance to those CPUs running in user space with SME enabled

   - Include kernel-hwcap.h in list of generated files (missed in a
     recent commit generating the KERNEL_HWCAP_* macros)

  CCA:

   - Fix RSI_INCOMPLETE error check in arm-cca-guest

  MPAM:

   - Fix an unmount-&gt;remount problem with the CDP emulation,
     uninitialised variable and checker warnings"

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
  arm_mpam: resctrl: Fix the check for no monitor components found
  arm_mpam: resctrl: Fix MBA CDP alloc_capable handling on unmount
  virt: arm-cca-guest: fix error check for RSI_INCOMPLETE
  arm64/hwcap: Include kernel-hwcap.h in list of generated files
  arm64: errata: Work around early CME DVMSync acknowledgement
  arm64: cputype: Add C1-Pro definitions
  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()
  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull more arm64 updates from Catalin Marinas:
 "The main 'feature' is a workaround for C1-Pro erratum 4193714
  requiring IPIs during TLB maintenance if a process is running in user
  space with SME enabled.

  The hardware acknowledges the DVMSync messages before completing
  in-flight SME accesses, with security implications. The workaround
  makes use of the mm_cpumask() to track the cores that need
  interrupting (arm64 hasn't used this mask before).

  The rest are fixes for MPAM, CCA and generated header that turned up
  during the merging window or shortly before.

  Summary:

  Core features:

   - Add workaround for C1-Pro erratum 4193714 - early CME (SME unit)
     DVMSync acknowledgement. The fix consists of sending IPIs on TLB
     maintenance to those CPUs running in user space with SME enabled

   - Include kernel-hwcap.h in list of generated files (missed in a
     recent commit generating the KERNEL_HWCAP_* macros)

  CCA:

   - Fix RSI_INCOMPLETE error check in arm-cca-guest

  MPAM:

   - Fix an unmount-&gt;remount problem with the CDP emulation,
     uninitialised variable and checker warnings"

* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm_mpam: resctrl: Make resctrl_mon_ctx_waiters static
  arm_mpam: resctrl: Fix the check for no monitor components found
  arm_mpam: resctrl: Fix MBA CDP alloc_capable handling on unmount
  virt: arm-cca-guest: fix error check for RSI_INCOMPLETE
  arm64/hwcap: Include kernel-hwcap.h in list of generated files
  arm64: errata: Work around early CME DVMSync acknowledgement
  arm64: cputype: Add C1-Pro definitions
  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()
  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-next/c1-pro-erratum-4193714' into for-next/core</title>
<updated>2026-04-20T12:12:35+00:00</updated>
<author>
<name>Catalin Marinas</name>
<email>catalin.marinas@arm.com</email>
</author>
<published>2026-04-20T12:12:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=858fbd7248bd84b2899fb2c29bc7bc2634296edf'/>
<id>858fbd7248bd84b2899fb2c29bc7bc2634296edf</id>
<content type='text'>
* for-next/c1-pro-erratum-4193714:
  : Work around C1-Pro erratum 4193714 (CVE-2026-0995)
  arm64: errata: Work around early CME DVMSync acknowledgement
  arm64: cputype: Add C1-Pro definitions
  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()
  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* for-next/c1-pro-erratum-4193714:
  : Work around C1-Pro erratum 4193714 (CVE-2026-0995)
  arm64: errata: Work around early CME DVMSync acknowledgement
  arm64: cputype: Add C1-Pro definitions
  arm64: tlb: Pass the corresponding mm to __tlbi_sync_s1ish()
  arm64: tlb: Introduce __tlbi_sync_s1ish_{kernel,batch}() for TLB maintenance
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'iommu-updates-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux</title>
<updated>2026-04-15T22:05:51+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-04-15T22:05:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f1d26d72f01556c787b1291729aa7a2ce37656a8'/>
<id>f1d26d72f01556c787b1291729aa7a2ce37656a8</id>
<content type='text'>
Pull iommu updates from Joerg Roedel:
 "Core:

   - Support for RISC-V IO-page-table format in generic iommupt code

  ARM-SMMU Updates:

   - Introduction of an "invalidation array" for SMMUv3, which enables
     future scalability work and optimisations for devices with a large
     number of SMMUv3 instances

   - Update the conditions under which the SMMUv3 driver works around
     hardware errata for invalidation on MMU-700 implementations

   - Fix broken command filtering for the host view of NVIDIA's "cmdqv"
     SMMUv3 extension

   - MMU-500 device-tree binding additions for Qualcomm Eliza &amp; Hawi
     SoCs

  Intel VT-d:

   - Support for dirty tracking on domains attached to PASID

   - Removal of unnecessary read*()/write*() wrappers

   - Improvements to the invalidation paths

  AMD Vi:

   - Race-condition fixed in debugfs code

   - Make log buffer allocation NUMA aware

  RISC-V:

   - IO-TLB flushing improvements

   - Minor fixes"

* tag 'iommu-updates-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: (48 commits)
  iommu/vt-d: Restore IOMMU_CAP_CACHE_COHERENCY
  dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
  iommu/amd: Invalidate IRT cache for DMA aliases
  iommu/riscv: Remove overflows on the invalidation path
  iommu/amd: Fix clone_alias() to use the original device's devid
  iommu/vt-d: Remove the remaining pages along the invalidation path
  iommu/vt-d: Pass size_order to qi_desc_piotlb() not npages
  iommu/vt-d: Split piotlb invalidation into range and all
  iommu/vt-d: Remove dmar_writel() and dmar_writeq()
  iommu/vt-d: Remove dmar_readl() and dmar_readq()
  iommufd/selftest: Test dirty tracking on PASID
  iommu/vt-d: Support dirty tracking on PASID
  iommu/vt-d: Rename device_set_dirty_tracking() and pass dmar_domain pointer
  iommu/vt-d: Block PASID attachment to nested domain with dirty tracking
  iommu/dma: Always allow DMA-FQ when iommupt provides the iommu_domain
  iommu/riscv: Fix signedness bug
  iommu/amd: Fix illegal cap/mmio access in IOMMU debugfs
  iommu/amd: Fix illegal device-id access in IOMMU debugfs
  iommu/tegra241-cmdqv: Update uAPI to clarify HYP_OWN requirement
  iommu/tegra241-cmdqv: Set supports_cmd op in tegra241_vcmdq_hw_init()
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull iommu updates from Joerg Roedel:
 "Core:

   - Support for RISC-V IO-page-table format in generic iommupt code

  ARM-SMMU Updates:

   - Introduction of an "invalidation array" for SMMUv3, which enables
     future scalability work and optimisations for devices with a large
     number of SMMUv3 instances

   - Update the conditions under which the SMMUv3 driver works around
     hardware errata for invalidation on MMU-700 implementations

   - Fix broken command filtering for the host view of NVIDIA's "cmdqv"
     SMMUv3 extension

   - MMU-500 device-tree binding additions for Qualcomm Eliza &amp; Hawi
     SoCs

  Intel VT-d:

   - Support for dirty tracking on domains attached to PASID

   - Removal of unnecessary read*()/write*() wrappers

   - Improvements to the invalidation paths

  AMD Vi:

   - Race-condition fixed in debugfs code

   - Make log buffer allocation NUMA aware

  RISC-V:

   - IO-TLB flushing improvements

   - Minor fixes"

* tag 'iommu-updates-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: (48 commits)
  iommu/vt-d: Restore IOMMU_CAP_CACHE_COHERENCY
  dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
  iommu/amd: Invalidate IRT cache for DMA aliases
  iommu/riscv: Remove overflows on the invalidation path
  iommu/amd: Fix clone_alias() to use the original device's devid
  iommu/vt-d: Remove the remaining pages along the invalidation path
  iommu/vt-d: Pass size_order to qi_desc_piotlb() not npages
  iommu/vt-d: Split piotlb invalidation into range and all
  iommu/vt-d: Remove dmar_writel() and dmar_writeq()
  iommu/vt-d: Remove dmar_readl() and dmar_readq()
  iommufd/selftest: Test dirty tracking on PASID
  iommu/vt-d: Support dirty tracking on PASID
  iommu/vt-d: Rename device_set_dirty_tracking() and pass dmar_domain pointer
  iommu/vt-d: Block PASID attachment to nested domain with dirty tracking
  iommu/dma: Always allow DMA-FQ when iommupt provides the iommu_domain
  iommu/riscv: Fix signedness bug
  iommu/amd: Fix illegal cap/mmio access in IOMMU debugfs
  iommu/amd: Fix illegal device-id access in IOMMU debugfs
  iommu/tegra241-cmdqv: Update uAPI to clarify HYP_OWN requirement
  iommu/tegra241-cmdqv: Set supports_cmd op in tegra241_vcmdq_hw_init()
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: errata: Work around early CME DVMSync acknowledgement</title>
<updated>2026-04-10T18:46:14+00:00</updated>
<author>
<name>Catalin Marinas</name>
<email>catalin.marinas@arm.com</email>
</author>
<published>2026-04-07T10:28:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0baba94a9779c13c857f6efc55807e6a45b1d4e4'/>
<id>0baba94a9779c13c857f6efc55807e6a45b1d4e4</id>
<content type='text'>
C1-Pro acknowledges DVMSync messages before completing the SME/CME
memory accesses. Work around this by issuing an IPI to the affected CPUs
if they are running in EL0 with SME enabled.

Note that we avoid the local DSB in the IPI handler as the kernel runs
with SCTLR_EL1.IESB=1. This is sufficient to complete SME memory
accesses at EL0 on taking an exception to EL1. On the return to user
path, no barrier is necessary either. See the comment in
sme_set_active() and the more detailed explanation in the link below.

To avoid a potential IPI flood from malicious applications (e.g.
madvise(MADV_PAGEOUT) in a tight loop), track where a process is active
via mm_cpumask() and only interrupt those CPUs.

Link: https://lore.kernel.org/r/ablEXwhfKyJW1i7l@J2N7QTR9R3
Cc: Will Deacon &lt;will@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: James Morse &lt;james.morse@arm.com&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Reviewed-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
C1-Pro acknowledges DVMSync messages before completing the SME/CME
memory accesses. Work around this by issuing an IPI to the affected CPUs
if they are running in EL0 with SME enabled.

Note that we avoid the local DSB in the IPI handler as the kernel runs
with SCTLR_EL1.IESB=1. This is sufficient to complete SME memory
accesses at EL0 on taking an exception to EL1. On the return to user
path, no barrier is necessary either. See the comment in
sme_set_active() and the more detailed explanation in the link below.

To avoid a potential IPI flood from malicious applications (e.g.
madvise(MADV_PAGEOUT) in a tight loop), track where a process is active
via mm_cpumask() and only interrupt those CPUs.

Link: https://lore.kernel.org/r/ablEXwhfKyJW1i7l@J2N7QTR9R3
Cc: Will Deacon &lt;will@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: James Morse &lt;james.morse@arm.com&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Reviewed-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: mpam: Add initial MPAM documentation</title>
<updated>2026-03-27T15:32:52+00:00</updated>
<author>
<name>Ben Horgan</name>
<email>ben.horgan@arm.com</email>
</author>
<published>2026-03-13T14:46:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4ce0a2ccc0358f3f746fa50815a599f861fd5d68'/>
<id>4ce0a2ccc0358f3f746fa50815a599f861fd5d68</id>
<content type='text'>
MPAM (Memory Partitioning and Monitoring) is now exposed to user-space via
resctrl. Add some documentation so the user knows what features to expect.

Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Jonathan Cameron &lt;jonathan.cameron@huawei.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MPAM (Memory Partitioning and Monitoring) is now exposed to user-space via
resctrl. Add some documentation so the user knows what features to expect.

Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Jonathan Cameron &lt;jonathan.cameron@huawei.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Quirk CMN-650's CSU NRDY behaviour</title>
<updated>2026-03-27T15:32:42+00:00</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2026-03-13T14:46:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=aeb8595a5f8ba4aac8b5c265a8bcc3f18b473cb5'/>
<id>aeb8595a5f8ba4aac8b5c265a8bcc3f18b473cb5</id>
<content type='text'>
CMN-650 is afflicted with an erratum where the CSU NRDY bit never clears.
This tells us the monitor never finishes scanning the cache. The erratum
document says to wait the maximum time, then ignore the field.

Add a flag to indicate whether this is the final attempt to read the
counter, and when this quirk is applied, ignore the NRDY field.

This means accesses to this counter will always retry, even if the counter
was previously programmed to the same values.

The counter value is not expected to be stable, it drifts up and down with
each allocation and eviction. The CSU register provides the value for a
point in time.

Tested-by: Punit Agrawal &lt;punit.agrawal@oss.qualcomm.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Co-developed-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CMN-650 is afflicted with an erratum where the CSU NRDY bit never clears.
This tells us the monitor never finishes scanning the cache. The erratum
document says to wait the maximum time, then ignore the field.

Add a flag to indicate whether this is the final attempt to read the
counter, and when this quirk is applied, ignore the NRDY field.

This means accesses to this counter will always retry, even if the counter
was previously programmed to the same values.

The counter value is not expected to be stable, it drifts up and down with
each allocation and eviction. The CSU register provides the value for a
point in time.

Tested-by: Punit Agrawal &lt;punit.agrawal@oss.qualcomm.com&gt;
Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Co-developed-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Add workaround for T241-MPAM-6</title>
<updated>2026-03-27T15:32:41+00:00</updated>
<author>
<name>Shanker Donthineni</name>
<email>sdonthineni@nvidia.com</email>
</author>
<published>2026-03-13T14:46:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dc48eb1ff27cc3169c3c5cca5eb20645d04d9e22'/>
<id>dc48eb1ff27cc3169c3c5cca5eb20645d04d9e22</id>
<content type='text'>
The registers MSMON_MBWU_L and MSMON_MBWU return the number of requests
rather than the number of bytes transferred.

Bandwidth resource monitoring is performed at the last level cache, where
each request arrive in 64Byte granularity. The current implementation
returns the number of transactions received at the last level cache but
does not provide the value in bytes. Scaling by 64 gives an accurate byte
count to match the MPAM specification for the MSMON_MBWU and MSMON_MBWU_L
registers. This patch fixes the issue by reporting the actual number of
bytes instead of the number of transactions from __ris_msmon_read().

Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Punit Agrawal &lt;punit.agrawal@oss.qualcomm.com&gt;
Tested-by: Peter Newman &lt;peternewman@google.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The registers MSMON_MBWU_L and MSMON_MBWU return the number of requests
rather than the number of bytes transferred.

Bandwidth resource monitoring is performed at the last level cache, where
each request arrive in 64Byte granularity. The current implementation
returns the number of transactions received at the last level cache but
does not provide the value in bytes. Scaling by 64 gives an accurate byte
count to match the MPAM specification for the MSMON_MBWU and MSMON_MBWU_L
registers. This patch fixes the issue by reporting the actual number of
bytes instead of the number of transactions from __ris_msmon_read().

Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Punit Agrawal &lt;punit.agrawal@oss.qualcomm.com&gt;
Tested-by: Peter Newman &lt;peternewman@google.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Add workaround for T241-MPAM-4</title>
<updated>2026-03-27T15:32:41+00:00</updated>
<author>
<name>Shanker Donthineni</name>
<email>sdonthineni@nvidia.com</email>
</author>
<published>2026-03-13T14:46:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a7efe23ed6dd08259ad1b238e9c33bb511666fd4'/>
<id>a7efe23ed6dd08259ad1b238e9c33bb511666fd4</id>
<content type='text'>
In the T241 implementation of memory-bandwidth partitioning, in the absence
of contention for bandwidth, the minimum bandwidth setting can affect the
amount of achieved bandwidth. Specifically, the achieved bandwidth in the
absence of contention can settle to any value between the values of
MPAMCFG_MBW_MIN and MPAMCFG_MBW_MAX.  Also, if MPAMCFG_MBW_MIN is set
zero (below 0.78125%), once a core enters a throttled state, it will never
leave that state.

The first issue is not a concern if the MPAM software allows to program
MPAMCFG_MBW_MIN through the sysfs interface. This patch ensures program
MBW_MIN=1 (0.78125%) whenever MPAMCFG_MBW_MIN=0 is programmed.

In the scenario where the resctrl doesn't support the MBW_MIN interface via
sysfs, to achieve bandwidth closer to MBW_MAX in the absence of contention,
software should configure a relatively narrow gap between MBW_MIN and
MBW_MAX. The recommendation is to use a 5% gap to mitigate the problem.

Clear the feature MBW_MIN feature from the class to ensure we don't
accidentally change behaviour when resctrl adds support for a MBW_MIN
interface.

Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Fenghua Yu &lt;fenghuay@nvidia.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the T241 implementation of memory-bandwidth partitioning, in the absence
of contention for bandwidth, the minimum bandwidth setting can affect the
amount of achieved bandwidth. Specifically, the achieved bandwidth in the
absence of contention can settle to any value between the values of
MPAMCFG_MBW_MIN and MPAMCFG_MBW_MAX.  Also, if MPAMCFG_MBW_MIN is set
zero (below 0.78125%), once a core enters a throttled state, it will never
leave that state.

The first issue is not a concern if the MPAM software allows to program
MPAMCFG_MBW_MIN through the sysfs interface. This patch ensures program
MBW_MIN=1 (0.78125%) whenever MPAMCFG_MBW_MIN=0 is programmed.

In the scenario where the resctrl doesn't support the MBW_MIN interface via
sysfs, to achieve bandwidth closer to MBW_MAX in the absence of contention,
software should configure a relatively narrow gap between MBW_MIN and
MBW_MAX. The recommendation is to use a 5% gap to mitigate the problem.

Clear the feature MBW_MIN feature from the class to ensure we don't
accidentally change behaviour when resctrl adds support for a MBW_MIN
interface.

Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Fenghua Yu &lt;fenghuay@nvidia.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm_mpam: Add workaround for T241-MPAM-1</title>
<updated>2026-03-27T15:32:41+00:00</updated>
<author>
<name>Shanker Donthineni</name>
<email>sdonthineni@nvidia.com</email>
</author>
<published>2026-03-13T14:46:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=70e81fbedc6570b2397e07a645136af0a0eec907'/>
<id>70e81fbedc6570b2397e07a645136af0a0eec907</id>
<content type='text'>
The MPAM bandwidth partitioning controls will not be correctly configured,
and hardware will retain default configuration register values, meaning
generally that bandwidth will remain unprovisioned.

To address the issue, follow the below steps after updating the MBW_MIN
and/or MBW_MAX registers.

 - Perform 64b reads from all 12 bridge MPAM shadow registers at offsets
   (0x360048 + slice*0x10000 + partid*8). These registers are read-only.
 - Continue iterating until all 12 shadow register values match in a loop.
   pr_warn_once if the values fail to match within the loop count 1000.
 - Perform 64b writes with the value 0x0 to the two spare registers at
   offsets 0x1b0000 and 0x1c0000.

In the hardware, writes to the MPAMCFG_MBW_MAX MPAMCFG_MBW_MIN registers
are transformed into broadcast writes to the 12 shadow registers. The
final two writes to the spare registers cause a final rank of downstream
micro-architectural MPAM registers to be updated from the shadow copies.
The intervening loop to read the 12 shadow registers helps avoid a race
condition where writes to the spare registers occur before all shadow
registers have been updated.

Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Punit Agrawal &lt;punit.agrawal@oss.qualcomm.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The MPAM bandwidth partitioning controls will not be correctly configured,
and hardware will retain default configuration register values, meaning
generally that bandwidth will remain unprovisioned.

To address the issue, follow the below steps after updating the MBW_MIN
and/or MBW_MAX registers.

 - Perform 64b reads from all 12 bridge MPAM shadow registers at offsets
   (0x360048 + slice*0x10000 + partid*8). These registers are read-only.
 - Continue iterating until all 12 shadow register values match in a loop.
   pr_warn_once if the values fail to match within the loop count 1000.
 - Perform 64b writes with the value 0x0 to the two spare registers at
   offsets 0x1b0000 and 0x1c0000.

In the hardware, writes to the MPAMCFG_MBW_MAX MPAMCFG_MBW_MIN registers
are transformed into broadcast writes to the 12 shadow registers. The
final two writes to the spare registers cause a final rank of downstream
micro-architectural MPAM registers to be updated from the shadow copies.
The intervening loop to read the 12 shadow registers helps avoid a race
condition where writes to the spare registers occur before all shadow
registers have been updated.

Tested-by: Gavin Shan &lt;gshan@redhat.com&gt;
Tested-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Tested-by: Punit Agrawal &lt;punit.agrawal@oss.qualcomm.com&gt;
Tested-by: Jesse Chick &lt;jessechick@os.amperecomputing.com&gt;
Reviewed-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Shaopeng Tan &lt;tan.shaopeng@jp.fujitsu.com&gt;
Reviewed-by: Gavin Shan &lt;gshan@redhat.com&gt;
Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Signed-off-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iommu/arm-smmu-v3: Update Arm errata</title>
<updated>2026-03-24T13:46:36+00:00</updated>
<author>
<name>Robin Murphy</name>
<email>robin.murphy@arm.com</email>
</author>
<published>2026-03-19T15:24:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3b793983834e9484a834912548f4786b742abc92'/>
<id>3b793983834e9484a834912548f4786b742abc92</id>
<content type='text'>
MMU-700 r1p1 has subsequently fixed some of the errata for which we've
been applying the workarounds unconditionally, so we can now make those
conditional. However, there have also been some more new cases
identified where we must rely on range invalidation commands, and thus
still nominally avoid DVM being inadvertently enabled.

Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MMU-700 r1p1 has subsequently fixed some of the errata for which we've
been applying the workarounds unconditionally, so we can now make those
conditional. However, there have also been some more new cases
identified where we must rely on range invalidation commands, and thus
still nominally avoid DVM being inadvertently enabled.

Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
