Xen 4.22 was released on July 30, 2026, about eight months after 4.21, and the theme of this one is keeping a single guest from spoiling the machine for everyone else. Xenstore gains per domain quotas and watch depth limits, so a domain that goes strange cannot consume shared bookkeeping without bound. On x86, Xen now supports the Bus Lock Threshold that AMD introduced with Zen 5, which lets the hypervisor put a ceiling on the slow atomic operations a guest can force on the whole socket. Arm gets guest suspend to RAM through standard PSCI, RISC-V gets the SSTC timer extension, and a pile of long deprecated interfaces is finally gone.
The short answer
Xen 4.22 landed on July 30, 2026, roughly eight months after 4.21. Xenstore gains per domain quotas and watch depth support, which caps what a single guest can consume from a resource every other guest shares. On x86, Xen now supports AMD's Zen 5 Bus Lock Threshold, so the hypervisor can limit the slow atomic operations a guest imposes on the whole socket. Arm gains guest suspend and resume to RAM through standard PSCI, keeps advancing Armv8-R MPU support and moves to FF-A 1.2. RISC-V gets the SSTC timer extension and device tree domain build helpers. Long deprecated interfaces have been removed.
Hypervisor releases rarely have a headline feature, and this one does not either. What Xen 4.22 has instead is a set of changes that all point the same direction: making sure one domain cannot degrade the machine for the others. That is a less exciting sentence than a new architecture port, and it is the thing people running production hosts actually care about.
Xenstore quotas are the change to read first
Xenstore is the shared key value store that Xen domains use to find out about their own devices, negotiate with the toolstack, and watch each other's state. It is small, it is chatty, and it is shared by everything on the host. That combination has always meant that a domain behaving oddly, whether through a bug in a guest agent or through a driver that retries forever, can occupy space and watch slots that other domains need.
Xen 4.22 adds per domain quotas and watch depth support so the hypervisor can bound that. Each domain gets a ceiling, and a domain that hits its ceiling is the only one affected.
If your host runs one workload you trust, this is invisible. If your host runs domains for other people, this is the reason to schedule the upgrade. Multi tenant fairness is exactly the class of problem where the fix is boring and the absence of the fix shows up at three in the morning.
Bus locks, and why one guest can slow down a whole socket
The x86 addition is support for the Bus Lock Threshold that AMD shipped with Zen 5.
The underlying problem is old and specific. An atomic read modify write normally locks one cache line, which is fast and stays local to the core. When the operand crosses a cache line boundary the processor cannot use that mechanism, so it locks the memory bus instead. Every core on the socket stalls for the duration. A single guest running misaligned atomics in a tight loop can therefore make every neighbour on the machine slower, and from the hypervisor's point of view it is not doing anything unusual: it is executing ordinary instructions.
Bus Lock Threshold gives the hypervisor a counter. A guest is allowed a budget of bus locks, and when the budget runs out control comes back to the hypervisor, which can then decide what to do about the domain responsible. Intel parts have had comparable detection for a few generations, so this is Xen catching up on AMD hardware rather than a new concept.
Arm, RISC-V and the automotive pull
On Arm, guests can now be suspended and resumed to RAM through standard PSCI calls, which is the ordinary way an operating system asks firmware to put the system to sleep. Doing it through the standard interface matters because it means guest kernels do not need Xen specific code to participate in host power management. Armv8-R MPU support continues to advance, aimed at safety critical deployments where there is no MMU to lean on, and the Firmware Framework for Arm implementation moves to the v1.2 specification.
RISC-V picks up internal support for the SSTC timer extension, which gives a supervisor direct control of its own timer comparison register instead of trapping to the layer below for every timer programming operation. It also gains CONFIG_DOMAIN_BUILD_HELPERS, which simplifies building guest domains from device trees. RISC-V in Xen is still enablement work rather than a finished story, and the direction is towards full guest virtualization as the relevant ISA extensions and kernel support settle.
The names attached to this release explain the priorities. Ford Motor Company, Honda R&D, Renesas Electronics, EPAM and Vates are credited, with the announcement calling out functional safety testing and software in the loop tooling for automotive. Cody Zuschlag, the Xen Project community manager, framed 4.22 as reflecting the community's "steady momentum" and continued investment.
That is a different centre of gravity from the Xen of a decade ago. The hypervisor that once mattered mainly because a large public cloud ran on it is now being funded substantially by people who want a small, auditable hypervisor inside a vehicle.
What we would do with it
Read the removal list before anything else. Xen 4.22 drops long deprecated legacy interfaces, and in our experience removals cause more upgrade pain than features do. Anything in your toolstack, your monitoring, or your guest configuration that has been quietly relying on an old interface will tell you about it at the worst possible moment.
Beyond that, the calculus is straightforward. Single tenant host, no Zen 5, no rush. Multi tenant host, or Zen 5 hardware, or an Arm platform where guest power management has been awkward: this is a release with something in it for you. And if you are on a downstream such as XCP-ng, the version that matters is the one your distribution ships, not the one upstream tagged today.
Xen 4.22 is available from xenproject.org. Xen Summit 2026 runs September 15 to 17 in Munich.
Sources and further reading
- Xen Project releases Xen 4.22, the official announcement
- Phoronix: Xen 4.22 released with AMD Zen 5 BLT support, improved RISC-V virtualization
- The Xen Project download page
- Xen Project delivers Xen 4.21, the previous release announcement
Frequently asked questions
What is the Xenstore quota change, in practical terms?
Xenstore is the small shared configuration database every Xen domain talks to. It holds device information, power state, guest agent handshakes and the watches that let one domain be notified when another writes a key. It is shared, which means it has always been a place where one badly behaved domain could consume a resource that every other domain depends on. Xen 4.22 adds per domain quotas and watch depth support, so the hypervisor can cap how much of that shared bookkeeping any single guest is allowed to hold. On a host with one trusted workload this changes nothing. On a host that rents domains to people you have never met, it is the difference between a contained problem and a host wide one.
What does Bus Lock Threshold actually do?
An atomic instruction normally works by locking a single cache line, which is cheap and local. When the operand straddles two cache lines the processor cannot do that, so it falls back to locking the bus itself, which serialises memory access for every core on the socket for thousands of cycles. One guest running a loop of misaligned atomics can therefore slow down every other guest on the same physical machine, without doing anything the hypervisor traditionally intercepts. AMD added a Bus Lock Threshold with Zen 5 so the hypervisor can give each guest a budget of bus locks and take control when the budget is exhausted. Xen 4.22 adds support for the feature. Intel processors have had comparable detection for several generations, so this closes an asymmetry rather than inventing a new idea.
When did 4.21 ship, and what is the release cadence?
Xen 4.21 was released on November 19, 2025, and 4.20 on March 5, 2025. The project has historically aimed at roughly two releases a year, so the gap of about eight months between 4.21 and 4.22 is a little longer than the nominal cadence. Xen releases are not time based in the way a Linux kernel merge window is, and the schedule slips when the feature set warrants it. The next in person gathering is Xen Summit 2026, scheduled for September 15 to 17 in Munich, which is usually where the direction of the following release becomes visible.
Who is funding and testing Xen these days?
The 4.22 announcement credits Ford Motor Company, Honda R&D, Renesas Electronics, EPAM and Vates, with particular emphasis on functional safety testing and on software in the loop tooling for automotive adoption. That list tells you where the money is. Xen is no longer primarily a public cloud hypervisor story, and the work going in reflects a mix of embedded, automotive and safety critical use alongside the traditional server side. The Armv8-R MPU work and the FF-A 1.2 update in this release are squarely in that category, as is the continued RISC-V enablement.
Should I upgrade right away?
Not on the day of release, unless you are testing. Xen 4.22 removes long deprecated legacy interfaces, and removals are the changes that break people. Read the release notes for anything your toolstack or your guest configuration still touches, then stage the upgrade the way you would any hypervisor change. If you run a multi tenant host, the Xenstore quota work is the reason to plan the upgrade rather than defer it indefinitely. If you run XCP-ng or another downstream, wait for that project to pick 4.22 up, because the downstream integration is where most of the risk actually lives.