
/news/amd-refreshes-ualink-kernel-patches-to-prep-linux-for-ualoe-on-helios-bb469650
AMD Refreshes UALink Kernel Patches To Prep Linux For UALoE On Helios
AMD's second round of UALink patches fixes 32-bit builds and drops the sysfs configuration API in favour of out-of-band tooling, targeting UALink over Ethernet on Helios.
AMD has posted a second revision of its UALink bring-up patches for the mainline Linux kernel, closing out August with an updated take on the large series it published earlier in the month. The goal is unchanged: get Ultra Accelerator Link support — specifically UALink over Ethernet, or "UALoE" — ready in Linux for AMD's Helios servers built around Instinct MI455X accelerators, 6th Gen EPYC "Venice" processors, and Pensando AI NICs.
What UALink is for
UALink is the open standard for a high-speed networking protocol that connects GPUs and other AI accelerators inside scale-up pods. Instead of scaling out across many nodes with general-purpose Ethernet or InfiniBand, UALink lets accelerators in a pod share memory and communicate with low latency — the same niche NVIDIA fills with NVLink and NVSwitch, but as a multi-vendor standard. On Linux, the hardware is useless without kernel-side plumbing, and that is what this patch series is building.
What changed in v2
The updated series — 95 patches for the initial UALink infrastructure, plus a second series with updated documentation — carries two notable changes:
- 32-bit kernel builds are fixed. The first posting evidently broke builds on 32-bit architectures, an early but predictable review finding for a series this size, and one that would have blocked it from being picked up by subsystem maintainers.
- The sysfs-based configuration API is gone. AMD has dropped the interface that let users configure UALink through the kernel's sysfs filesystem and is opting for out-of-band tooling, at least initially. UALink configuration — deciding how accelerators are linked and how the fabric is set up — will happen outside the kernel's usual in-band sysfs path, presumably via user-space tooling talking to the management stack or the Pensando AI NICs.
The sysfs removal is the more interesting decision. Kernel-side sysfs interfaces tend to invite long review debates about API stability and whether configuration belongs in the kernel at all. Moving configuration out of band sidesteps that for now and keeps the initial kernel footprint smaller. The trade-off: early adopters will depend on AMD's tooling rather than standard kernel interfaces. Whether a proper kernel configuration interface returns later is not addressed in the posting.
The AMDGPU connection
The series also wires UALink support into the AMDGPU kernel driver, so the same driver that manages Instinct accelerators gains awareness of the UALink fabric. That integration matters for MI455X-based pods: the accelerators need to expose their UALink capabilities to software that orchestrates workloads across them.
Timing and what it means for Helios
The v2 series arrived too late for the Linux 7.3 merge window. If review proceeds without major redesign, the target is Linux 7.4. That leaves a gap: Helios servers will ship before UALink support is in a mainline kernel release. AMD is presumably relying on patched, vendor-blessed Linux distributions for near-term Helios deployments, though no confirmed software details for those distributions have been shared.
That pattern is familiar. Large fabric and interconnect bring-ups routinely land in mainline well after the first hardware ships, with early systems running vendor kernels until upstream catches up. For anyone planning Helios deployments, the distribution you pick — not the upstream kernel — determines whether UALink works on day one.
Why this patch series matters
Linux support is the gate for UALink adoption. An open scale-up interconnect standard only competes with NVLink if the software stack around it is genuinely open and upstream; otherwise it's just another proprietary fabric with a spec attached. AMD committing a 95-patch infrastructure series to mainline, with AMDGPU integration and Ethernet-based transport (UALoE rides standard Ethernet rather than requiring exotic physical layers), signals that the company intends UALink to be a first-class citizen in the kernel rather than a fork-only feature.
Open questions to watch as review continues: whether the out-of-band configuration story satisfies maintainers, whether the 7.4 target holds, and what AMD's actual management tooling for UALink looks like once published. For now, the kernel-side foundation is taking shape, and a second revision suggests AMD is responding to review feedback rather than dumping a finished design on the mailing list and walking away.
Comments
Sign in or create an account to leave a comment.
0 comments
No comments yet.