Open Challenges for a Production-ready Cloud Environment on top of RISC-V hardware

Aaron Call; Guillem Senabre; Ramon Nou

REVIEW 4 major objections 4 minor 5 references

Open Challenges for a Production-ready Cloud Environment on top of RISC-V hardware

T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper reports that a working OpenStack cluster can be built on RISC-V development boards, but that missing hardware features and performance gaps of up to 10x on bare metal and 100x under emulation make production-ready cloud…

desk verdict Real OpenStack-on-RISC-V deployment experience, but the performance claims overreach by comparing a $100 dev board to a Xeon cluster and using QEMU soft-emulation numbers. read the letter →

arxiv 2505.02650 v1 pith:X5VGCGY5 submitted 2025-05-05 cs.DC cs.ARcs.ET

Aaron Call , Ramon Nou , Guillem Senabre This is my paper · ORCID

classification cs.DCcs.ARcs.ET

keywords RISC-VOpenStackcloudcomputingvirtualizationperformancemeasurementhardwarematurityQEMUdatacenter

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that RISC-V hardware, despite its promise for open cloud infrastructure, is not yet ready for production-grade cloud environments. It shows a functional OpenStack cluster running on real RISC-V boards, but only after working around missing firmware standards, incomplete software packages, and absent processor extensions. Measured against an Intel Xeon server, the RISC-V board trails by up to 10x in some workloads, and OpenStack or QEMU virtual machines run up to 100x slower than bare metal on the paper's custom benchmarks. The paper concludes that relying on such workarounds and nonstandard deployment methods is incompatible with a production-ready cloud.

What carries the argument

The load-bearing object is the demonstrator cluster: four LicheePi 4A compute nodes (TH1520 CPU, 16 GB RAM, dual Gigabit Ethernet), a controller node acting as bastion, and a storage node on a 2 TB USB SSD, all running OpenStack with QEMU/KVM for virtual machines. Two instruments carry the argument: a microbenchmark table comparing the board to an Intel Xeon server across Coremark, memory latency, disk I/O, network throughput, and power, and a custom C benchmark suite measuring real/user/sys time, prime computation, and file read/write on native hardware, inside an OpenStack instance, and under QEMU. The enabling mechanism is the boot workaround—injecting kernel and DTB into libvirt, or using EDK2 with ACPI disabled—which is what makes virtual machines possible at all on this platform.

What would settle it

Take a commercially available RISC-V server board that implements the hypervisor extension and the ratified RVV1.0 vector extension, run the same OpenStack deployment and the paper's microbenchmarks on it without ACPI disabling, and compare VM overhead to bare metal. If the OpenStack/QEMU overhead drops from roughly 70-100x to a small factor and the Coremark, disk, and network figures approach the Intel Xeon server, then the paper's 'unfeasible' claim would be shown to be a property of the development board rather than of RISC-V itself.

Watch

Extended reading notes

Core claim

On its own terms, the central discovery is a working OpenStack deployment on a small cluster of Sipeed LicheePi 4A boards, together with a catalogue of the gaps that had to be bridged to make it boot. Because RISC-V has no standard BIOS, OpenStack's assumption of a self-bootable guest image fails: libvirt must inject the kernel and device-tree blob manually, or the image must use EDK2/UEFI with the ACPI support explicitly disabled. The hardware comparison against an Intel Xeon server shows the board trailing by roughly 3x on Coremark, 7x on sequential disk writes, about 10x on network throughput, and over 45x on random writes. Virtualized and emulated runs are about 70 to 100 times slower than native execution. The paper concludes that this combination of missing extensions, immature boot flow, and performance gap makes production-ready OpenStack on RISC-V currently unfeasible.

Load-bearing premise

The conclusion that RISC-V cannot yet support a production cloud rests on treating the 100-dollar LicheePi 4A development board as representative of RISC-V server-class hardware, so a substantially faster server-grade RISC-V chip could undermine the verdict.

Editorial extensions

If this is right

Until RISC-V chips implement hypervisor extensions and a standard boot firmware path, OpenStack deployments on RISC-V will require manual kernel/device-tree injection and disabling ACPI.
Cloud operators cannot plan on RISC-V for performance-sensitive production workloads today; the reported gaps of up to 10x on bare metal and 100x under emulation are too large.
The software packaging gap is already closing, with Debian's RISC-V repository coverage reaching roughly 95%, so the remaining blockers are hardware features and boot flow, not Python package availability.
The only HPC board with vector extensions has been sold out for months despite a 600-euro price, indicating that demand for capable RISC-V hardware currently exceeds supply.
Virtualization on RISC-V is the weakest layer, so early RISC-V cloud efforts should target bare-metal or container workloads rather than VM-heavy OpenStack.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The 100x emulation overhead probably reflects the immaturity of the RISC-V virtualization path (QEMU and unbuilt hypervisor extensions) more than the CPU's raw speed; a hardware hypervisor extension could erase most of this gap independently of general performance.
The 'unfeasible' verdict is time-sensitive: the paper itself notes RVV1.0 was ratified only in 2024 and hypervisor extensions are defined but absent from silicon, so the same OpenStack deployment could plausibly become viable once server-class chips with those extensions ship.
Since Debian coverage is already at about 95%, the bottleneck is shifting from software packaging to hardware capabilities; testing the same image on the vector-capable Milk-V Jupiter board would separate the benefit of vector extensions from general CPU maturity.
A concrete testable extension would be to benchmark the same OpenStack cluster after switching the boot path from kernel/DTB injection to a pure EDK2/UEFI image, isolating how much of the VM overhead comes from the nonstandard boot method rather than the hardware.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

This is a short poster with a real, useful core: the authors actually stood up an OpenStack cluster on LicheePi 4A RISC-V boards and documented the pain. The porting notes—kernel 5.10 to 6.6 vendor lag, missing bcrypt/passlib for Keystone, the OpenSBI/EDK2 boot flow, and the ACPI-vs-DeviceTree conflict—are the kind of ground truth that saves other people weeks. That part deserves a serious read.

What is less solid is the performance case for the headline conclusion. The stress-test note has it right: Table 2 compares a $100, 4-thread board with 1 GbE against an 8-node Xeon cluster with 10 GbE. The 10x network and disk gaps are hardware class, not ISA. Table 3 reports up to 142x write slowdowns, but those runs are under QEMU in software-emulation mode because the TH1520 lacks the RISC-V hypervisor extension. Production RISC-V clouds would target H-extension chips with KVM, so that number measures the wrong stack. And Table 2 has a red flag: memory latency at 116 ns for RISC-V versus 1497 ns for x86. That is backward from expectation and suggests the benchmark methodology was not controlled. The x86 model is also listed inconsistently (4114 in text, 4112 in the table). The benchmark programs are not shipped, so the numbers can't be checked.

This doesn't mean the conclusion is wrong. RISC-V server-class cloud infrastructure is young, and 'not yet production-ready' is a plausible statement that the authors' real experience supports in a narrow sense. But the evidence as written supports 'a cheap development board with a software-emulation stack is not production-ready,' not 'RISC-V server hardware with mature virtualization is infeasible.' The authors implicitly know this—they say boards are development-purpose and hypervisor extensions aren't in silicon—yet the conclusion overreaches.

The citation pattern is fine; this is a project report, and the relevant EU initiatives are cited. The paper is honest about workarounds and doesn't hide the rough edges.

For peer review: I'd send it to a serious referee. The deployment experience is worth preserving, but the quantitative claims need either a server-class comparison or a sharpened scope. As it stands, I wouldn't cite the performance numbers in my own work, but I would cite the porting experience after the authors clean up the data.

The paper is for people building or planning RISC-V cloud stacks, not for a broad theory audience. It deserves a revise-and-resubmit, not a desk reject.

Referee Report

4 major / 4 minor

Summary. The paper reports on the construction of a prototype OpenStack cluster built from Sipeed LicheePi 4A RISC-V development boards as part of the Vitamin-V project. It describes the hardware selection process, software porting challenges (including missing Debian packages, bcrypt/passlib issues, and a slow vendor kernel update cycle), and a method for launching VMs by injecting a kernel and device tree via libvirt or by using EDK2 with device-tree-based UEFI. It presents two performance comparisons: Table 2 against an Intel Xeon cluster, and Table 3 comparing native execution, OpenStack-managed VMs, and QEMU on the RISC-V board. The paper concludes that current performance gaps and the reliance on workarounds make RISC-V currently unfeasible for production-ready cloud environments such as OpenStack.

Significance. If the central conclusion were established, it would be a valuable cautionary data point for the RISC-V cloud ecosystem and for European initiatives such as EPI and Vitamin-V. The paper's genuine strengths are its deployment experience and the identification of concrete integration obstacles: non-self-bootable guest images, the ACPI-versus-device-tree conflict, the need to patch Nova for RISC-V, and the absence of the hypervisor extension on the tested chip. These qualitative findings will be useful to practitioners porting cloud software to RISC-V. However, the quantitative evidence underpinning the headline '10× slower' and '100× slower' claims is not reliable as reported, because of platform-class and emulation-mode mismatches, an internally contradictory memory-latency measurement, and the absence of any benchmark artifacts. The paper does not ship reproducible code or detailed methodology, so the performance conclusions are not independently checkable.

major comments (4)

[Ecosystem maturity (Hardware), Table 2] The memory-latency row is internally inconsistent with the paper's own claim that RISC-V is far slower than x86: RISC-V is reported as 116 ns versus 1497 ns on x86, meaning the board appears 13× faster on this metric. Since typical memory latency is on the order of 100 ns for both architectures, this strongly suggests a unit, configuration, or measurement-protocol error. Because Table 2 is presented as evidence for a performance gap that makes production clouds unfeasible, this discrepancy undermines the quantitative basis of the central conclusion.
[Ecosystem maturity (Hardware), Table 2] The comparison conflates platform class with ISA readiness. The LicheePi 4A is a 100 USD, 4-thread, low-power development board with 16 GB RAM and 1 GbE networking, while the x86 'counterpart' is an 8-node Xeon cluster with larger memory, 10 GbE, and 10 TB storage. The 10× network gap and the disk-I/O gaps are expected from the hardware class alone and cannot be attributed to the RISC-V ISA. The conclusion that RISC-V is 'currently unfeasible' for production clouds would require measurements on server-class RISC-V hardware, or at minimum an explicit acknowledgment that the results characterize a low-power development board.
[Ecosystem maturity (Hardware), Table 3] The emulation overhead in Table 3 is obtained with QEMU in software-emulation mode (TCG), because the TH1520 does not implement the RISC-V hypervisor extension. Production cloud environments would use hardware-assisted virtualization (KVM) on an H-extension part. Overheads of 20–142× are characteristic of full-system software emulation and do not predict the performance of hardware-virtualized RISC-V servers. As written, the evidence supports the statement that a software-emulation stack on a development board is not production-ready; it does not support the broader conclusion that server-class RISC-V with mature virtualization is infeasible.
[General methodology, Table 3] The benchmark methodology is not reproducible. The paper states that 'custom C benchmark programs' were used, but it provides no code, no build or test instructions, no number of repetitions, and no variance or error analysis, and it does not describe what operations the 'write' and 'read' tests perform. Because the headline slowdown factors are central to the paper's conclusion, the authors should ship the benchmark as an artifact and report the measurement spread. This is a load-bearing reproducibility gap, not a presentation detail.

minor comments (4)

[Ecosystem maturity (Hardware)] The text states the x86 cluster uses 'Intel Xeon Silver 4114 operating at 2.2GHz', while the caption of Table 2 says 'Intel Xeon Silver 4112 @ 2GHz'. These are different models; please reconcile the configuration and clarify whether the cluster-wide or per-node figures are reported.
[Ecosystem maturity (Hardware)] The sentence 'RVV1.0 extension was ratified just in 2024' conflicts with the commonly cited 2021 ratification of RISC-V vector extension 1.0; please provide a source or correct the date. Similarly, 'hypervisor extensions are defined but not built on any chips' is too strong; please qualify it to 'not available on the TH1520' or cite a survey of available H-extension implementations.
[Launching Virtual Machines on RISC-V with OpenStack] The passage 'OpenStack's Glance service must be configured with metadata to:' is followed by an incomplete list; the required metadata items are missing and the sentence ends mid-thought. Please complete this description.
[Ecosystem maturity (Hardware), Table 2] The power-consumption rows report 11 W for RISC-V and 270–350 W for x86, but it is unclear whether the x86 value is per node or for the entire eight-node cluster. Please clarify, as this affects the interpretation of the efficiency comparison.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's assessment is based on measured benchmarks and deployment experience, not on a derivation that presupposes its conclusion.

full rationale

The paper does not perform a derivation, model fit, or parameter calibration that could reduce to its own inputs. Its central claim—that current RISC-V platforms are not yet suitable for production-ready OpenStack clouds—is supported by direct measurements reported in Table 2 and Table 3, such as 'in some cases, RISC-V being 10 times slower' and 'emulation is up to 100× slower than bare-metal execution.' These are empirical observations, not quantities derived from the conclusion by construction. The only self-citation is reference [1], the Vitamin-V project description, which is used for context and funding framing rather than as load-bearing evidence for the performance claim. The paper also explicitly reports a deployment outcome—successfully launching VMs via customized libvirt and EDK2 configuration—so the negative conclusion is not merely an assertion of impossibility but a summary of observed challenges. Concerns that the LicheePi 4A board and QEMU software emulation are not representative of server-class RISC-V hardware with the hypervisor extension are validity or generalizability criticisms, not circularity: the authors use those platforms as their test environment and report what they measured. No equation is shown that defines a predicted quantity in terms of the fitted data, no uniqueness theorem is imported from the authors' prior work, and no known empirical pattern is renamed as a new result. Therefore the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 2 assumptions · 0 invented entities

The central claim rests on the representativeness of the chosen development board and on the benchmark suite, both of which are assumptions the paper takes without independent validation.

assumptions (2)

domain assumption The LicheePi 4A development board is representative of current RISC-V hardware for cloud readiness.
The paper generalizes from this single low-power board to the entire RISC-V ecosystem, despite noting that server-class EPI processors are not yet available. This is load-bearing for the conclusion that RISC-V is not production-ready for cloud.
domain assumption The benchmark suite used (Coremark, custom C programs, disk and network throughput) captures the workloads that matter for cloud production environments.
The performance conclusions are based on these microbenchmarks, which may not reflect representative cloud workloads such as virtualization, container orchestration, or database serving.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Open Challenges for a Production-ready Cloud Environment on top of RISC-V hardware." pith.science (2026). https://pith.science/paper/X5VGCGY5

@misc{pith2026250502650,
  author       = {Pith},
  title        = {Pith review of: Open Challenges for a Production-ready Cloud Environment on top of RISC-V hardware},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X5VGCGY5}},
  note         = {Machine review of arXiv:2505.02650}
}

read the original abstract

As part of the Vitamin-V European project, we have built a prototype of a RISC-V cluster managed by OpenStack, with the goal of realizing a functional RISC-V cloud ecosystem. In this poster we explain the hardware and software challenges encountered while porting some elements of OpenStack. We also discuss the current performance gaps that challenge a performance-ready cloud environment over such new ISA, an essential element to fulfill in order to achieve european technological sovereignty.

Figures

Figures reproduced from arXiv: 2505.02650 by the authors.

**Figure 1.** Openstack cluster using LicheePi4a boards. We compared this platform against a cluster composed of 8 nodes based on Intel Xeon Silver 4114 operating at 2.2GHz, with 126GB DDR5 of RAM, interconnected via a 10GBps ethernet network plus a node dedicated to storage with 10TB of capacity. The results of this performance comparison are shown in table 2. While it is obvious that a performance gap should exist due to the d… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

5 extracted references · 5 canonical work pages

[1]

Ramon Canal, Cristiano Chenet, Angelos Are- lakis, Jose-Maria Arnau, Josep Ll. Berral, Aaron Call, Stefano Di Carlo, Juan Jose Costa, Dimitris Gizopoulos, Vasileios Karakostas, Francesco Lu- brano, Konstantinos Nikas, Yiannis Nikolakopou- los, Beatriz Otero, George Papadimitriou, Ioannis Papaefstathiou, Dionisios Pnevmatikatos, Daniel Raho, Alvise Rigo, E...

work page 2023
[2]

Big data: The power of petabytes

Michael Eisenstein. Big data: The power of petabytes. Nature, 527(7576):S2–S4, Nov 2015

work page 2015
[3]

European processor initiative: The industrial cornerstone of eurohpc for exascale era

Mario Kovač. European processor initiative: The industrial cornerstone of eurohpc for exascale era. In Proceedings of the 16th ACM International Conference on Computing Frontiers, CF ’19, page 319, New York, NY, USA, 2019. Association for Computing Machinery

work page 2019
[4]

milk-v jupiter board, 2024

Milk-V. milk-v jupiter board, 2024. Accessed: 6 Feb. 2025

work page 2024
[5]

Sipeed liche pi4a.https://sipeed.com/ licheepi4a

SiPeed. Sipeed liche pi4a.https://sipeed.com/ licheepi4a. Accessed: 2024-01-25. RISC-V Summit Europe, Paris, 12-15th May 2025 3

work page 2024

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.

[1] [1]

Ramon Canal, Cristiano Chenet, Angelos Are- lakis, Jose-Maria Arnau, Josep Ll. Berral, Aaron Call, Stefano Di Carlo, Juan Jose Costa, Dimitris Gizopoulos, Vasileios Karakostas, Francesco Lu- brano, Konstantinos Nikas, Yiannis Nikolakopou- los, Beatriz Otero, George Papadimitriou, Ioannis Papaefstathiou, Dionisios Pnevmatikatos, Daniel Raho, Alvise Rigo, E...

work page 2023

[2] [2]

Big data: The power of petabytes

Michael Eisenstein. Big data: The power of petabytes. Nature, 527(7576):S2–S4, Nov 2015

work page 2015

[3] [3]

European processor initiative: The industrial cornerstone of eurohpc for exascale era

Mario Kovač. European processor initiative: The industrial cornerstone of eurohpc for exascale era. In Proceedings of the 16th ACM International Conference on Computing Frontiers, CF ’19, page 319, New York, NY, USA, 2019. Association for Computing Machinery

work page 2019

[4] [4]

milk-v jupiter board, 2024

Milk-V. milk-v jupiter board, 2024. Accessed: 6 Feb. 2025

work page 2024

[5] [5]

Sipeed liche pi4a.https://sipeed.com/ licheepi4a

SiPeed. Sipeed liche pi4a.https://sipeed.com/ licheepi4a. Accessed: 2024-01-25. RISC-V Summit Europe, Paris, 12-15th May 2025 3

work page 2024