The patch series 461473-1, posted by [email protected] to the linux-acpi list on 1 October 2026, routes TLBI domain configuration through firmware tables rather than through the ARM architecture directly. The sender's address and the list name are the two facts that matter here. Everything else is plumbing.

Phoronix frames the feature as "an upcoming Arm architecture capability" and notes that "No performance numbers were shared." The kernel patch is the document that decides what this actually is. The number 461473-1 in the linux-acpi thread, not the linux-arm-kernel thread, is what separates a firmware-mediated scope control from a pure ISA extension. The two pages do not agree on where the feature lives.

The constraint is the firmware, not the core count. If TLBI domains are enumerated through ACPI, the hypervisor or BIOS must expose domain topology before the kernel can target invalidation to a subset of cores. A buyer of a high-core-count Arm server is not getting a free latency win from the silicon alone. What the filing proves is that the kernel path exists and that the configuration source is firmware, not architecture.

No cycle count, no latency figure, no benchmark separates targeted invalidation from system-wide invalidation. The LLVM 23 and Binutils 2.46 toolchain dependency means a new instruction encoding must exist before any kernel path can be exercised. The Arm Architecture Reference Manual does not yet contain TLBI Domains. The filing is a patch, not a measurement.

The firmware is the constraint, not the core count. TLBI domain topology must be exposed in ACPI tables before the kernel can scope invalidation, and no Arm silicon is confirmed to ship with this capability.

The patch routes TLBI domain configuration through ACPI firmware rather than the ARM ISA. The fab must encode domain boundaries in firmware tables, and the OS must parse them before any scoped TLBI instruction executes. No cycle-level measurement exists for targeted versus system-wide invalidation.