linux-stable.git/Documentation/arch/arm64, branch linux-rolling-stable

cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()

2026-07-24T14:21:20+00:00

commit f9a82544c7174851f5c7524622f5966dcafd3a47 upstream.

On arm64, when booting with `maxcpus` greater than the number of present
CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present'
but have not yet been registered via register_cpu(). Consequently,
the per-cpu device objects for these CPUs are not yet initialized.

In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling
_cpu_up() for these unregistered CPUs eventually leads to
sysfs_create_group() being called with a NULL kobject (or a kobject
without a directory), triggering the following warning in
fs/sysfs/group.c:

  WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181
  [...]
  Call trace:
    internal_create_group+0x41c/0x4bc (P)
    sysfs_create_group+0x18/0x24
    topology_add_dev+0x1c/0x28
    cpuhp_invoke_callback+0x104/0x20c
    __cpuhp_invoke_callback_range+0x94/0x11c
    _cpu_up+0x200/0x37c

When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
enumerated CPUs as "present" regardless of their status in the MADT. This
causes issues with SMT hotplug control. For instance, with QEMU's
"-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
follows:

1. The first four CPUs: `Enabled` set but `Online Capable` not set.

2. The remaining four CPUs: `Online Capable` set but `Enabled` not set
   to support potential hot-plugging.

Fix this by:

1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
   entry before calling set_cpu_present() during SMP initialization.

2. Properly managing the present mask in acpi_map_cpu() and
   acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
   other architectures like x86 and LoongArch.

3. Update the arm64 CPU hotplug documentation to no longer state that all
   online-capable vCPUs are marked as present by the kernel at boot time.

This ensures that only physically available or explicitly enabled CPUs
are in the present mask, keeping the SMT control logic consistent with
the actual hardware state.

Cc: Catalin Marinas 
Cc: Jonathan Cameron 
Cc: James Morse 
Cc: Yicong Yang 
Cc: stable@vger.kernel.org
Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure
Fixes: eed4583bcf9a ("arm64: Kconfig: Enable HOTPLUG_SMT")
Reviewed-by: Catalin Marinas 
Suggested-by: Catalin Marinas 
Signed-off-by: Jinjie Ruan 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU

2026-06-19T11:50:58+00:00

commit 1940e70a8144bf75e6df26bf6f600862ea7f7ea1 upstream.

Commit fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM
Neoverse N2 errata") states that Microsoft Azure Cobalt 100 CPU "is a
Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and
therefore suffers from all the same errata.".

So enable the workaround for the latest broadcast TLB invalidation bug
on these parts.

Signed-off-by: Will Deacon 
[Mark: backport to v7.1.y]
Signed-off-by: Mark Rutland 
Signed-off-by: Greg Kroah-Hartman

arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU

2026-06-19T11:50:58+00:00

commit ec7216f92e4ebd485b1c6dc6aa3f6064b71a5768 upstream.

NVIDIA Olympus cores are affected by the TLBI completion issue tracked as
CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses
ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB
sequence and ensure affected memory write effects are globally observed.

Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same
mitigation is enabled on affected Olympus systems. Also document the
NVIDIA Olympus erratum in the arm64 silicon errata table and list it in
the Kconfig help text.

Signed-off-by: Shanker Donthineni 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Mark Rutland 
Acked-by: Mark Rutland 
Signed-off-by: Will Deacon 
[Mark: backport to v7.1.y]
Signed-off-by: Mark Rutland 
Signed-off-by: Greg Kroah-Hartman

arm64: errata: Mitigate TLBI errata on various Arm CPUs

2026-06-19T11:50:58+00:00

commit cfd391e74134db664feb499d43af286380b10ba8 upstream.

A number of CPUs developed by Arm suffer from errata whereby a broadcast
TLBI;DSB sequence may complete before the global observation of writes
which are translated by an affected TLB entry.

These errata ONLY affect the completion of memory accesses which have
been translated by an invalidated TLB entry, and these errata DO NOT
affect the actual invalidation of TLB entries. TLB entries are removed
correctly.

This issue has been assigned CVE ID CVE-2025-10263.

To mitigate this issue, Arm recommends that software follows any
affected TLBI;DSB sequence with an additional TLBI;DSB, which will
ensure that all memory write effects affected by the first TLBI have
been globally observed. The additional TLBI can use any operation that
is broadcast to affected CPUs, and the additional DSB can use any option
that is sufficient to complete the additional TLBI.

The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate
the issue. Enable this workaround for affected CPUs, and update the
silicon errata documentation accordingly.

Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number.

Signed-off-by: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Will Deacon 
[Mark: backport to v7.1.y]
Signed-off-by: Mark Rutland 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2026-04-20T23:46:22+00:00

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->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

Merge branch 'for-next/c1-pro-erratum-4193714' into for-next/core

2026-04-20T12:12:35+00:00

* 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

Merge tag 'iommu-updates-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux

2026-04-15T22:05:51+00:00

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 & 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()
  ...

arm64: errata: Work around early CME DVMSync acknowledgement

2026-04-10T18:46:14+00:00

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 
Cc: Mark Rutland 
Cc: James Morse 
Cc: Mark Brown 
Reviewed-by: Will Deacon 
Signed-off-by: Catalin Marinas

arm64: mpam: Add initial MPAM documentation

2026-03-27T15:32:52+00:00

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 
Reviewed-by: Shaopeng Tan 
Reviewed-by: Jonathan Cameron 
Acked-by: Catalin Marinas 
Signed-off-by: Ben Horgan 
Reviewed-by: Gavin Shan 
Tested-by: Gavin Shan 
Tested-by: Shaopeng Tan 
Tested-by: Jesse Chick 
Signed-off-by: James Morse

arm_mpam: Quirk CMN-650's CSU NRDY behaviour

2026-03-27T15:32:42+00:00

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 
Tested-by: Gavin Shan 
Tested-by: Shaopeng Tan 
Tested-by: Jesse Chick 
Reviewed-by: Zeng Heng 
Reviewed-by: Gavin Shan 
Co-developed-by: Ben Horgan 
Signed-off-by: Ben Horgan 
Signed-off-by: James Morse