Virtualization · Hypervisor · Ecosystem

Xen Boots on the SpacemiT K3: the First RVA23 RISC-V Board With APLIC, IMSIC and the H-Extension

📅 2026-09-30 ⏱ 8 min read 🔗 Source: XCP-ng Blog (Vates), Xen Summit 2026 session, HiFive Premier P550 support series

For most of 2026 the Xen RISC-V story has been a QEMU story. The hypervisor booted, created guests, and did so entirely in emulation — useful for iteration, but forgiving in ways real silicon is not. On September 29, 2026 that changed twice over: Vates announced in its XCP-ng devblog that Xen now boots on the SpacemiT K3 — the first spec-compliant RVA23 board the project has supported, and, as of today, the only board on the market carrying both APLIC/IMSIC and the H-extension.

The announcement came out of the Xen Summit 2026 in Munich (hosted by Renesas at the HEADS office, September 15–17). In the session “Xen on RISC-V: From Dom0less to xl” (Sept 16, 17:00 CEST), Vates engineers Oleksii Kurochko and Baptiste Le Duc gave a practical status update on the port across its two main use cases — dom0less deployments for embedded and safety-critical workloads, and dom0 with the xl toolstack for traditional virtualization — with a live demo and an honest inventory of what still does not work.

This article walks the two-step path that got there, and what the K3 port means for anyone planning virtualization on RISC-V this year.

Honesty note. Everything below is sourced from Vates' own posts, the Xen Summit 2026 session listing, and the K3's public specifications. We have not run Xen on a K3 ourselves, and neither of the two patch series described here is upstream yet — treat them as working branches, not supported features. The K3's virtualization story has a known rough edge we covered separately: an independent review found that KVM currently oopses on the vendor kernel even though the hardware carries the hypervisor extension. Xen booting on the same board is not evidence that KVM is fixed.

Two Steps, Two Boards, Two Very Different Problems

It is worth separating the two milestones, because the difficulty in each case was completely different.

Step	Board	CPU	The actual problem
1. Sep 3, 2026	HiFive Premier P550	SiFive EIC7700X	Core designed against a pre-ratification hypervisor-extension draft
2. Sep 29, 2026	SpacemiT K3 (CoM260 / Pico-ITX)	8× X100 + 8× A100	Board was simply not available to the project — no spec problem

Step one, described in the September 3 post, was about spec drift. Xen boots and launches a guest domain on a HiFive Premier P550 — real silicon, not QEMU. But the board's heart is not new: SiFive announced the P550 core in June 2021, six months before the RISC-V hypervisor extension was ratified. The EIC7700X therefore pairs a modern SoC with a core that implements only a pre-ratification draft of the hypervisor extension — the EIC7700X manual claims Hypervisor-Level ISA v0.6 — and offers only a PLIC interrupt controller, with no APLIC/IMSIC.

Since Xen implements the ratified extension, getting a guest to boot for real meant gating the CSRs and extensions that this board does not have. That is a different class of work from porting: you are not adding support for a feature, you are carefully declining to touch one.

Step two, on September 29, was about availability. As the Vates post puts it plainly: “right now, the SpacemiT K3 is the only board on the market supporting both APLIC/IMSIC and the H-extension and we don't have one yet.” The project had the software; it lacked the board.

Why the K3 Is the Board the Port Needed

Modern RISC-V virtualization does not rest on the H-extension alone. The Advanced Interrupt Architecture (AIA) is the other half, and it replaces the legacy PLIC with two blocks that a hypervisor cannot do its job without:

Block	Role	Why a hypervisor needs it
APLIC (Advanced Platform-Level Interrupt Controller)	Convert wired interrupts to MSIs; route them per-hart or per-guest	Lets the hypervisor deliver a device interrupt to the right virtual hart without trapping and emulating every line
IMSIC (Incoming MSI Controller)	Per-hart, per-privilege-level MSI mailbox in memory	Enables direct interrupt injection into VS-mode; the RISC-V analogue of a posted interrupt
H-extension (RVA23 mandatory)	VS/VU modes, two-stage address translation (hgatp), `hfence`/`hstatus`	The hardware basis for running a guest OS at all

The K3 is RVA23-compliant, and RVA23 makes the hypervisor extension mandatory — which is exactly why the RVA23 boundary has been the dividing line for virtualization on RISC-V all year. It also matters that the K3 is a shipping board with real distribution: the CoM260 module appears on the Banana Pi BPI-SM10 and the Milk-V Jupiter 2, and the K3 Pico-ITX has reached retail.

The open-source-hardware multiplier. The Vates post is unusually candid about how this port actually happened, and it is a good illustration of how hardware gaps get closed in this ecosystem. Zheng Zhang of ISCAS (Institute of Software, Chinese Academy of Sciences) approached the project wanting to work on Xen RISC-V — and happened to own the one board they were missing. Vates had previously sent a patch series to fix boot issues on the HiFive Premier P550; Zhang picked up those same patches, tested them on hardware the original authors did not have, and reported back. Nobody was on a contract. That is the mechanism.

What “It Boots” Actually Requiring: The CI Work

The September 3 milestone was not only a bench demonstration. The same series added a proper CI job, because — again, in Vates' own framing — “a one-off boot on a bench is not worth much if nobody can reproduce it.” That job is worth understanding as a template, because it describes what RISC-V board bring-up automation looks like today:

A runner container that drives the board's UART and MCU lines — no video, no monitor, just a serial console the harness can read;
Images served over TFTP, so the DUT pulls its own payload;
A smoke test that flashes Xen plus a Linux guest and then watches the console for an expected string — the guest's boot message, which the project describes as “Hello RISC-V World!”;
End to end the pipeline runs: Xen boots, creates a guest domain, launches it, the guest prints its line, and the previously-waiting pipeline goes green.

Two honest caveats attach to this. The P550 series has not been sent to the Xen mailing list yet — Vates says it has other patch series that need upstreaming first and does not want to pile pressure on reviewers. And the longer-term plan for the K3 is a board physically in CI at Vates' office, which requires buying one first. Neither milestone is upstream code today.

Where the Port Stands

Pulling the two posts and the summit abstract together, the state of Xen on RISC-V reads like this:

Capability	Status (as reported)
Xen in QEMU (RISC-V)	Working; the project's long-standing development environment
Xen booting a guest on real hardware	Achieved on HiFive Premier P550 (Sep 3, 2026); patch series not upstream
Xen on an RVA23 board	Achieved on SpacemiT K3 (announced Sep 29, 2026 at Xen Summit)
dom0less deployments	One of the two headline use cases covered in the summit talk (embedded / safety-critical)
dom0 + xl toolstack	Second headline use case; Baptiste Le Duc's work has focused on guest-domain creation via xl from dom0
Board in project CI	Goal, not yet done — pending hardware acquisition
Upstream	Not yet submitted; blockers are the project's own upstreaming backlog

Read the summit title carefully. “From Dom0less to xl” describes the scope of the talk — the port's two main use cases — not a claim that both paths are equally finished. The session abstract is explicit that it walks through “what works, what is still in progress, and what the remaining gaps are.” Anyone planning on Xen-on-RISC-V should watch the recorded session rather than assume feature parity with x86.

The K3's Virtualization Story Is Still Messy — and That Is the Point

There is a real tension in the K3's virtualization support this month, and it deserves to be stated rather than smoothed over. In our K3 Pico-ITX coverage we noted the findings of a 20-minute independent review: the hardware carries the RVH hypervisor extension, but KVM oopses when the module loads on the vendor kernel. Meanwhile Xen boots on the same silicon, using the same H-extension plus the AIA blocks.

Both things can be true, and the difference is informative. KVM's RISC-V support is bound to mainline-oriented kernel paths and to a set of platform assumptions (interrupt controller wiring, timer, AIA detection) that a vendor BSP may not satisfy. Xen's port here was explicitly written to accommodate hardware variation — that gating logic is exactly what the P550 exercise produced. In other words: the P550's pre-ratification core was a liability for one port and an accidental training exercise that made the next port feasible.

It also reinforces a pattern that has held all year on this site: RISC-V board support is still software-bound, not silicon-bound. The silicon shipping today is, in the main, capable. What varies is whether anyone has written and tested the platform glue — and whether that glue is upstream.

Checklist for Anyone Porting a Hypervisor to RISC-V Hardware

Distilled from the two Vates posts and the summit abstract, the practical order of operations looks like this:

Verify the H-extension is ratified-level, not a draft. Ask for the exact hypervisor-extension version the core implements. A v0.6-class draft (as the EIC7700X documents) means CSR gating work before anything else functions.
Check for APLIC and IMSIC, not just “interrupts”. A PLIC-only board can boot a hypervisor but cannot deliver interrupts efficiently to guests. As of Sep 2026, the SpacemiT K3 is the board that has both.
Confirm RVA23 compliance if you want a supportable target. It makes H mandatory and gives you a stable software baseline — the same reason distros drew their line there.
Budget for the CI rig, not just the board. UART + MCU control lines, TFTP image serving, and a console-string assertion turned a bench demo into a reproducible test. Plan for it from day one.
Decide dom0less vs dom0+xl early. They are different integration surfaces: dom0less suits embedded and safety-critical workloads with no toolstack in the loop; dom0+xl suits conventional virtualization but needs the toolstack path working end to end.
Track upstreaming as a first-class deliverable. Both series here are working branches. A port that never lands upstream is a maintenance bill, not a capability.

What This Means for Open RISC-V Readers

For builders, the actionable reading is narrower than “RISC-V virtualization has arrived”. It is:

The K3 just became the most interesting RISC-V board for virtualization work. Not because it is finished, but because it is the only shipping board with the full interrupt-and-hypervisor feature set — which makes it the natural target for porting effort, including yours.
RVA23 is doing real work. The profile's mandatory H-extension is why “RVA23” and “boards you can virtualize” have become nearly the same list.
Expect the glue, not the silicon, to be the bottleneck. Xen works on a board whose CPU predates the spec it implements; KVM does not yet work on a board that is spec-compliant. Software readiness is still the variable.
Nothing here is upstream yet. If you need Xen on RISC-V in production, you are tracking mailing-list series and carrying patches — plan accordingly.

Related coverage on this site: the K3 Pico-ITX mini AI computer (including the KVM oops finding), the K3's RVA23 architecture, OpenSBI K3 platform support, Andes AX66 / Prodigy S8-100 with Linux KVM, and HPL on the K3's VLEN=1024 AI cores.

2026 年大部分时间里，Xen 的 RISC-V 故事都还是 QEMU 的故事：管理程序能启动、能创建客户机，但完全跑在模拟器里——适合快速迭代，却宽容得不像真硬件。2026 年 9 月 29 日，这件事一步跨过了两个台阶：Vates 在其 XCP-ng 开发博客上宣布 Xen 已在 SpacemiT（进迭时空）K3 上成功引导——这是该项目支持的第一块符合 RVA23 规范的板卡，也是截至目前市场上唯一同时具备 APLIC/IMSIC 与 H 扩展的板卡。

消息出自慕尼黑 Xen Summit 2026（由瑞萨承办于 HEADS 办公室，9 月 15–17 日）。在 9 月 16 日 17:00（CEST）的演讲《Xen on RISC-V: From Dom0less to xl》中，Vates 工程师 Oleksii Kurochko 与 Baptiste Le Duc 围绕该移植的两大用例——面向嵌入式与安全关键负载的 dom0less 部署，以及面向传统虚拟化场景的 dom0 + xl 工具栈——给出了务实的进展汇报，配现场演示，并如实清点了尚未打通的部分。

本文梳理通向这一步的两段路程，以及 K3 移植对今年打算在 RISC-V 上做虚拟化的人意味着什么。

诚实声明。 以下内容全部来自 Vates 官方博文、Xen Summit 2026 议程与 K3 公开规格。我们没有在 K3 上亲自运行过 Xen；本文涉及的两个补丁系列均未进入上游——请当作工作分支，而不是已支持的功能。K3 的虚拟化还有一处已知硬伤我们另文报道过：独立评测发现，尽管硬件带虚拟化扩展，KVM 在厂商内核上目前会 oops。Xen 能在同一块板上跑起来，并不等于 KVM 已经修好。

两个台阶、两块板、两个完全不同的问题

这两个里程碑值得分开看，因为各自的难点完全不同。

台阶	板卡	CPU	真正的难点
1. 2026-09-03	HiFive Premier P550	SiFive EIC7700X	内核按批准前草案实现虚拟化扩展
2. 2026-09-29	SpacemiT K3（CoM260 / Pico-ITX）	8× X100 + 8× A100	板子拿不到——不是规范问题

第一段（9 月 3 日博文）的关键词是规范漂移。Xen 在 HiFive Premier P550 上完成引导并启动了客户机域——这是真芯片，不是 QEMU。但这块板的内核并不新：SiFive 于 2021 年 6 月发布 P550 核，比 RISC-V 虚拟化扩展获批早半年。于是 EIC7700X 把一颗现代 SoC 和一颗按虚拟化扩展批准前草案实现的内核凑在一起——EIC7700X 手册自述为 Hypervisor-Level ISA v0.6——且只有 PLIC，没有 APLIC/IMSIC。

Xen 实现的是获批版本，因此要让客户机真正启动，就必须把这块板缺失的 CSR 和扩展小心地屏蔽掉。这与「移植」是不同性质的工作：你不是在新增特性支持，而是在精确地不去碰它。

第二段（9 月 29 日）的关键词则是可得性。Vates 的原话很直白：「目前 SpacemiT K3 是市场上唯一同时支持 APLIC/IMSIC 和 H 扩展的板卡，而我们手上还没有。」软件他们有了，板子缺。

为什么 K3 正是这个移植需要的板子

现代 RISC-V 虚拟化并不只靠 H 扩展，另一半是高级中断架构（AIA），它用两个模块取代传统 PLIC——缺了它们，管理程序做不了本职工作：

模块	作用	为什么管理程序需要它
APLIC（高级平台级中断控制器）	把线式中断转换为 MSI，按 hart 或按客户机路由	让管理程序把设备中断投递到正确的虚拟 hart，无需逐线陷入并模拟
IMSIC（入向 MSI 控制器）	每个 hart、每个特权级的内存中 MSI 信箱	支持把中断直接注入 VS 态，相当于 RISC-V 版本的中断投递（posted interrupt）
H 扩展（RVA23 强制）	VS/VU 模式、两阶段地址翻译（hgatp）、`hfence`/`hstatus`	运行客户机操作系统的硬件前提

K3 符合 RVA23，而 RVA23 把虚拟化扩展列为强制项——这正是全年以来「RVA23 边界」等同于「能否虚拟化」的原因。同样重要的是，K3 是一块已出货、有真实渠道的板子：CoM260 模组出现在 Banana Pi BPI-SM10 与 Milk-V Jupiter 2 上，K3 Pico-ITX 也已零售。

开源硬件的放大器效应。 Vates 博文少见地坦白了这次移植究竟是怎么发生的，也是这个生态里「硬件缺口如何被补上」的好样本。中科院软件所（ISCAS）的张政想参与 Xen RISC-V 开发，而他恰好拥有项目缺的那块板。此前 Vates 曾提交一组补丁修复 HiFive Premier P550 的引导问题；张政捡起同一组补丁，在原作者的硬件上测试并回报。没有人签合同，机制就是这样运转的。

「能引导」背后真正的功课：CI 部分

9 月 3 日那个里程碑不只是台面演示。同一组补丁还加入了正式的 CI 任务——用 Vates 的话说，「如果没人能复现，台面上的一次性引导没有多少价值」。这套任务本身值得当作模板来理解，因为它描述了当下 RISC-V 板卡 bring-up 自动化的真实长相：

一个 runner 容器，驱动板子的 UART 与 MCU 控制线——不看视频、不接显示器，只要能读的串口；
镜像通过 TFTP 下发，被测设备自己拉取；
一个冒烟测试：烧写 Xen 加 Linux 客户机，然后在控制台里等一个预期字符串——客户机的启动信息，项目里写的是 “Hello RISC-V World!”；
端到端流程为：Xen 引导、创建客户机域、启动它、客户机打印该行，此前一直在等待的流水线变绿。

这里有两个需要如实说明的前提：P550 那组补丁尚未发到 Xen 邮件列表——Vates 表示手头还有别的补丁系列要先上游化，不想给评审者加压；K3 的长期计划是把板子放进 Vates 办公室的 CI 机架，那得先买一块。所以两个里程碑今天都还不是上游代码。

移植现状总览

能力	状态（按官方口径）
Xen 在 QEMU（RISC-V）上	可用；项目长期的开发环境
在真硬件上引导客户机	已在 HiFive Premier P550 达成（2026-09-03）；补丁未上游
在 RVA23 板卡上运行 Xen	已在 SpacemiT K3 达成（2026-09-29 于 Xen Summit 宣布）
dom0less 部署	峰会演讲覆盖的两大用例之一（嵌入式 / 安全关键）
dom0 + xl 工具栈	第二大用例；Baptiste Le Duc 的工作聚焦于从 dom0 经 xl 创建客户机域
板卡进入项目 CI	目标，尚未完成——等硬件到位
上游	尚未提交；阻塞点是项目自身的上游化积压

请仔细读演讲标题。「From Dom0less to xl」描述的是演讲范围——该移植的两大用例——并不等于两条路径都已同等完成。议程摘要明确写着会讲「哪些已工作、哪些仍在进行、剩余缺口是什么」。打算用 Xen-on-RISC-V 的人，应去看录像，而不是假设它已与 x86 功能对等。

K3 的虚拟化现状依然混乱——而这正是要点

这个月 K3 的虚拟化支持存在一处真实张力，值得摆出来而不是抹平。在本站 K3 Pico-ITX 报道中，我们记录了那份 20 分钟独立评测的发现：硬件带 RVH 虚拟化扩展，但 KVM 在厂商内核上加载模块时 oops。与此同时，Xen 在同一颗芯片上跑起来了，用的也是同一个 H 扩展加 AIA 模块。

两件事可以同时为真，而差异本身有信息量。KVM 的 RISC-V 支持绑定在面向主线的内核路径与一组平台假设上（中断控制器接线、定时器、AIA 探测），厂商 BSP 未必满足；而这里的 Xen 移植是明确为兼容硬件差异而写的——那段屏蔽逻辑，恰恰是 P550 那轮折腾的产物。换句话说：P550 的批准前内核，对一个移植是负债，却意外成了一次训练，让下一次移植变得可行。

这也再次印证本站全年反复出现的一条规律：RISC-V 的板卡支持仍是软件瓶颈，而非硅瓶颈。今天出货的芯片大体上是有能力的；差异在于有没有人写好并测过平台胶水层，以及这层胶水是否上游。

给 RISC-V 平台移植管理程序者的清单

确认内核实现的是获批版 H 扩展，而不是草案。 直接向厂商索要内核实现的虚拟化扩展版本号。若属 v0.6 一类草案（如 EIC7700X 手册自述），在一切跑通之前先做 CSR 屏蔽工作。
查 APLIC 与 IMSIC，而不只是「有中断」。 只有 PLIC 的板子可以引导管理程序，但无法高效地把中断投递给客户机。截至 2026 年 9 月，同时具备两者的是 SpacemiT K3。
若需要可长期维护的目标，确认 RVA23 合规。 它把 H 扩展变为强制，并给出稳定的软件基线——发行版把线画在这里，是同一个理由。
预算里要算 CI 机架，不只是板子。 UART + MCU 控制线、TFTP 下发镜像、外加控制台字符串断言，才把台面演示变成可复现测试。第一天就要规划。
尽早决定走 dom0less 还是 dom0+xl。 两者是不同的集成面：dom0less 适合工具栈不在环内的嵌入式与安全关键负载；dom0+xl 适合常规虚拟化，但需要工具栈路径端到端可用。
把上游化当成一等交付物。 本文两个系列都还是工作分支。永不落地的移植是维护账单，不是能力。

对本站读者的意义

K3 刚成为做虚拟化最有意思的 RISC-V 板子。 不是因为它已完工，而是因为它是唯一具备完整「中断 + 虚拟化」特性集的在售板卡——这使它成为移植工作的天然靶子，也包括你的。
RVA23 正在做实事。 该规范把 H 扩展列为强制项，正是「RVA23」与「可虚拟化的板子」几乎变成同一份清单的原因。
瓶颈预期在胶水层而非硅。 Xen 能在 CPU 早于其实现规范的板子上跑；KVM 在合规板子上反而还没跑通。软件就绪度仍是那个变量。
这些目前都还没上游。 若你要在生产环境用 Xen on RISC-V，你是在跟邮件列表补丁系列、自己背补丁——请据此规划。

本站相关报道：K3 Pico-ITX 迷你 AI 电脑（含 KVM oops 发现）、K3 的 RVA23 架构、OpenSBI K3 平台支持补丁、Andes AX66 与 Prodigy S8-100 上的 Linux KVM，以及在 K3 VLEN=1024 AI 核上跑 HPL。

Краткое содержание (RU)

Vates объявила 29 сентября 2026 года, что гипервизор Xen теперь загружается на SpacemiT K3 — первой плате, соответствующей спецификации RVA23, которую поддерживает проект, и на сегодня единственной на рынке, несущей одновременно APLIC/IMSIC и расширение H. Объявление прозвучало на Xen Summit 2026 в Мюнхене (15–17 сентября, принимающая сторона — Renesas); в докладе «Xen on RISC-V: From Dom0less to xl» инженеры Vates Олексий Курочко и Батист Ле Дюк разобрали два основных сценария порта — dom0less для встраиваемых и safety-critical нагрузок и dom0 с инструментарием xl — с живой демонстрацией и честным перечнем пробелов. Путь состоял из двух шагов: 3 сентября Xen впервые загрузил гостевой домен на реальном кремнии — плате HiFive Premier P550, чей процессор EIC7700X реализует доратификационный черновик расширения гипервизора (v0.6) и имеет только PLIC, из-за чего порт пришлось строить на «отключении» отсутствующих CSR; 29 сентября добавилась плата K3, которой у проекта просто не было. Ни один из патч-серий пока не отправлен в upstream; цель — поставить K3 в CI Vates. Отдельно важно: независимый обзор ранее показал, что KVM на вендорском ядре K3 падает в oops, хотя аппаратное расширение RVH присутствует — загрузка Xen это не исправляет.

Resumen (ES)

Vates anunció el 29 de septiembre de 2026 que el hipervisor Xen ya arranca en el SpacemiT K3, la primera placa conforme a la especificación RVA23 que soporta el proyecto y, a día de hoy, la única del mercado que incorpora a la vez APLIC/IMSIC y la extensión H. El anuncio se hizo en el Xen Summit 2026 de Múnich (15–17 de septiembre, organizado por Renesas); en la sesión «Xen on RISC-V: From Dom0less to xl», los ingenieros de Vates Oleksii Kurochko y Baptiste Le Duc repasaron los dos casos de uso principales del port — dom0less para cargas embebidas y de seguridad crítica, y dom0 con la herramienta xl — con demo en vivo e inventario honesto de lo que falta. El camino tuvo dos etapas: el 3 de septiembre Xen arrancó un dominio invitado en silicio real, una HiFive Premier P550 cuyo EIC7700X implementa un borrador previo a la ratificación (v0.6) y solo dispone de PLIC, obligando al port a «desactivar» CSR ausentes; el 29 de septiembre se sumó el K3, que el proyecto simplemente no tenía. Ninguna de las dos series de parches está aún en upstream; el objetivo es poner un K3 en el CI de Vates. Aparte: una review independiente mostró que KVM hace oops en el kernel del fabricante pese a existir la extensión RVH; que Xen arranque no lo arregla.

Résumé (FR)

Vates a annoncé le 29 septembre 2026 que l'hyperviseur Xen démarre désormais sur le SpacemiT K3 — la première carte conforme RVA23 prise en charge par le projet, et à ce jour la seule du marché à embarquer à la fois APLIC/IMSIC et l'extension H. L'annonce a été faite au Xen Summit 2026 de Munich (15–17 septembre, accueilli par Renesas) ; dans la session « Xen on RISC-V: From Dom0less to xl », les ingénieurs Vates Oleksii Kurochko et Baptiste Le Duc ont fait le point sur les deux cas d'usage du port — dom0less pour l'embarqué et le safety-critical, et dom0 avec l'outil xl — avec démo live et inventaire honnête des lacunes. Le parcours s'est fait en deux temps : le 3 septembre, Xen a lancé un domaine invité sur du silicium réel, une HiFive Premier P550 dont l'EIC7700X implémente un brouillon antérieur à la ratification (v0.6) et ne dispose que d'un PLIC, obligeant à « désactiver » les CSR absents ; le 29 septembre s'ajoute le K3, que le projet n'avait tout simplement pas. Aucune des deux séries de patchs n'est encore upstream ; l'objectif est de mettre un K3 dans le CI de Vates. Par ailleurs, une review indépendante avait montré que KVM provoque un oops sur le noyau du fournisseur malgré la présence de l'extension RVH — le démarrage de Xen n'y remédie pas.

Kurzfassung (DE)

Vates gab am 29. September 2026 bekannt, dass der Hypervisor Xen nun auf dem SpacemiT K3 bootet — dem ersten RVA23-konformen Board, das das Projekt unterstützt, und derzeit dem einzigen am Markt, das sowohl APLIC/IMSIC als auch die H-Erweiterung mitbringt. Verkündet wurde dies auf dem Xen Summit 2026 in München (15.–17. September, Gastgeber Renesas); in der Session „Xen on RISC-V: From Dom0less to xl“ gaben die Vates-Ingenieure Oleksii Kurochko und Baptiste Le Duc einen Statusbericht zu den beiden Hauptszenarien — dom0less für Embedded- und Safety-Critical-Lasten sowie dom0 mit dem xl-Toolstack — inklusive Live-Demo und ehrlicher Lückenliste. Der Weg hatte zwei Stufen: Am 3. September startete Xen erstmals eine Gastdomäne auf echtem Silizium, einem HiFive Premier P550, dessen EIC7700X einen Vor-Ratifizierungs-Entwurf (v0.6) implementiert und nur einen PLIC besitzt — der Port musste fehlende CSRs gezielt „abschalten“; am 29. September kam der K3 hinzu, der dem Projekt schlicht fehlte. Keine der beiden Patch-Serien ist bislang upstream; Ziel ist ein K3 im CI von Vates. Separat wichtig: Eine unabhängige Review zeigte, dass KVM auf dem Vendor-Kernel in einen oops läuft, obwohl die RVH-Erweiterung vorhanden ist — Xens Boot behebt das nicht.

خلاصه (FA)

شرکت Vates در ۲۹ سپتامبر ۲۰۲۶ اعلام کرد که هایپروایزر Xen اکنون روی برد SpacemiT K3 بوت می‌شود — نخستین برد منطبق با استاندارد RVA23 که این پروژه پشتیبانی می‌کند و تا امروز تنها برد بازار که هم‌زمان APLIC/IMSIC و افزونه H را دارد. این خبر در Xen Summit 2026 در مونیخ (۱۵ تا ۱۷ سپتامبر، میزبان: Renesas) اعلام شد؛ در نشست «Xen on RISC-V: From Dom0less to xl» مهندسان Vates، اولکسی کوروچکو و باتیست لو دوک، وضعیت دو سناریوی اصلی این پورت را ارائه کردند — استقرار dom0less برای بارهای نهفته و ایمنی‌محور، و dom0 همراه ابزار xl — با دموی زنده و فهرست صادقانه شکاف‌ها. مسیر دو مرحله داشت: در ۳ سپتامبر، Xen نخستین‌بار یک دامنه مهمان را روی سیلیکون واقعی بالا آورد — برد HiFive Premier P550 که پردازنده EIC7700X آن پیش‌نویس پیش از تصویب افزونه هایپروایزر (v0.6) را پیاده کرده و فقط PLIC دارد، بنابراین پورت ناچار شد CSRهای نبوده را «غیرفعال» کند؛ در ۲۹ سپتامبر برد K3 اضافه شد که پروژه به‌سادگی در اختیارش نداشت. هیچ‌یک از این دو مجموعه پچ هنوز به upstream نرسیده است؛ هدف، قرار دادن یک K3 در CI شرکت Vates است. نکته جداگانه: بازبینی مستقلی نشان داده بود که KVM روی کرنل سازنده دچار oops می‌شود هرچند افزونه RVH در سخت‌افزار وجود دارد — بوت‌شدن Xen این را رفع نمی‌کند.

Sources / 参考来源

← Back to Tech Blog