{"id":"29bc6980-dbeb-44e3-a946-d85262cb9508","arxiv_id":"2505.02650","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A prototype OpenStack cluster on low-power RISC-V boards runs, but large performance and software maturity gaps block production-ready RISC-V cloud environments.","lead":"Engineers at the Barcelona Supercomputing Center built a small RISC-V cluster running OpenStack and benchmarked it against an x86 server. They report that the RISC-V ecosystem is still too immature and slow for production cloud use, despite having a working prototype.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The infeasibility conclusion is based on mismatched platforms: a low-power dev board and QEMU software emulation, not server-class RISC-V with hardware-assisted virtualization.","rationale":"The paper reports a real and nontrivial OpenStack port, and the qualitative evidence about package gaps and workarounds is credible support for a 'not yet production-ready' statement. The problem is that the headline performance numbers are used to quantify that claim, and those numbers are not controlled. A 100 USD board versus an 8-node Xeon cluster tells us about price/performance, not about the RISC-V ISA; QEMU TCG versus KVM tells us about emulation overhead, not about production virtualization. The reader's weakest assumption about board representativeness is correct but incomplete: the same mismatch appears in the software stack (TCG instead of KVM) and is visible inside Table 2 itself as an impossible-looking memory-latency result. A controlled rerun on H-extension hardware with matched x86 conditions is the one experiment that would decide whether RISC-V's measured gaps are intrinsic to the ecosystem or artifacts of the prototype platform. Because the conclusion is conditional on evidence that has not yet been produced, the reader's CONDITIONAL verdict remains appropriate; no verdict change is needed.","tokens_in":3792,"tokens_out":8746,"duration_ms":100633,"concrete_test":"Rerun the same benchmark suites on a matched pair: (a) one LicheePi 4A versus one Xeon Silver node with equal active core counts and equal network generation, using lmbench lat_mem_rd and the paper's custom C programs; and (b) on a RISC-V SoC with the H extension (e.g., SG2380- or EIC7700-class), boot the same OpenStack VMs under KVM and compare native versus VM overhead. If KVM overhead is below roughly 20% or the memory-latency anomaly reverses, the performance-based infeasibility claim is not supported by the data.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The quantitative case for 'currently unfeasible' rests on Table 2 and Table 3, and both comparisons conflate platform class with ISA readiness. Table 2 compares a $100 LicheePi 4A (4 threads, 16 GB, 1 GbE) against an 8-node Xeon cluster with 10 GbE and much larger memory; the 10x network and disk gaps are expected from hardware class, not from the RISC-V instruction set. Table 3 reports up to 142x slowdowns for write I/O, but those runs use QEMU in software-emulation mode because the TH1520 lacks the RISC-V hypervisor extension; production clouds would use KVM on an H-extension part, so this overhead does not measure production virtualization. Table 2 also contains an internal red flag: RISC-V memory latency is reported as 116 ns versus 1497 ns on x86, i.e., the supposedly slower platform is 13x faster on a latency metric, indicating uncontrolled benchmark methodology. As written, the evidence supports 'a cheap development board with a software-emulation stack is not production-ready,' not 'RISC-V server hardware with mature virtualization is infeasible.'","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":3991,"tokens_out":5603,"duration_ms":63251,"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":[{"comment":"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.","section":"Ecosystem maturity (Hardware), Table 2"},{"comment":"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.","section":"Ecosystem maturity (Hardware), Table 2"},{"comment":"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.","section":"Ecosystem maturity (Hardware), Table 3"},{"comment":"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.","section":"General methodology, Table 3"}],"minor_comments":[{"comment":"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.","section":"Ecosystem maturity (Hardware)"},{"comment":"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.","section":"Ecosystem maturity (Hardware)"},{"comment":"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.","section":"Launching Virtual Machines on RISC-V with OpenStack"},{"comment":"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.","section":"Ecosystem maturity (Hardware), Table 2"}],"recommendation":"major_revision","confidential_remarks":"The paper reads like a conference poster abstract rather than a full research article, but the deployment experience is genuine and useful. The main revision priority should be to narrow the scope: report the experience on the development board as such, fix or remove the unreliable memory-latency row, add an explicit limitations paragraph distinguishing 'development board with software emulation' from 'RISC-V server hardware', and make the benchmark artifacts available. If those changes are made, the paper can make a solid, non-overreaching contribution to the RISC-V cloud literature."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis 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.\n\nWhat 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.\n\nThis 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.\n\nThe 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.\n\nFor 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.\n\nThe 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.","headline":"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.","tokens_in":4467,"tokens_out":3032,"would_cite":false,"duration_ms":32140,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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…","keywords":["RISC-V","OpenStack","cloud computing","virtualization","performance measurement","hardware maturity","QEMU","data center"],"falsifier":"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.","tokens_in":3610,"feed_emoji":"☁️","tokens_out":7509,"duration_ms":81222,"temperature":0.7,"pith_summary":"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.","feed_headline":"RISC-V clouds run 10x slower and still need workarounds","feed_subtitle":"A working OpenStack cluster on RISC-V boards exists, but missing firmware and 100x emulation overhead block production use.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the project context and goals for building a trustworthy RISC-V cloud environment, framing the prototype's purpose.","marker":"[1]"},{"why":"Motivates RISC-V as the basis for European processor production, establishing why cloud readiness on this ISA matters.","marker":"[3]"},{"why":"Documents the only commercially available HPC board with RVV1.0 vector extensions and its limited availability, supporting the hardware-maturity claim.","marker":"[4]"},{"why":"Supplies the LicheePi 4A board's specifications and vendor details, the platform on which the whole OpenStack prototype is built.","marker":"[5]"}],"fun_headline_variants":["RISC-V cloud prototype works, but production remains out of reach","OpenStack on RISC-V: functional, but production unfeasible","RISC-V cloud gaps: missing firmware, slow I/O, no production","RISC-V cloud prototype: works, but 100x slower under virtualization","RISC-V OpenStack cluster proves concept, not production"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["RISC-V cloud prototype works, but production remains out of reach","OpenStack on RISC-V: functional, but production unfeasible","RISC-V cloud gaps: missing firmware, slow I/O, no production","RISC-V cloud prototype: works, but 100x slower under virtualization","RISC-V OpenStack cluster proves concept, not production"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00062,"raw_usage":{"total_tokens":2807,"prompt_tokens":811,"completion_tokens":1996,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":427,"completion_tokens_details":{"reasoning_tokens":1915}},"tokens_in":427,"tokens_out":1996,"duration_ms":15484,"temperature":1.0,"reasoning_tokens":1915,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T00:44:25.894950+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the project context and goals for building a trustworthy RISC-V cloud environment, framing the prototype's purpose."},{"cited_title":"European processor initiative: The industrial cornerstone of eurohpc for exascale era","cited_arxiv_id":null,"evidence_quote":"Motivates RISC-V as the basis for European processor production, establishing why cloud readiness on this ISA matters."},{"cited_title":"milk-v jupiter board, 2024","cited_arxiv_id":null,"evidence_quote":"Documents the only commercially available HPC board with RVV1.0 vector extensions and its limited availability, supporting the hardware-maturity claim."},{"cited_title":"Sipeed liche pi4a.https://sipeed.com/ licheepi4a","cited_arxiv_id":null,"evidence_quote":"Supplies the LicheePi 4A board's specifications and vendor details, the platform on which the whole OpenStack prototype is built."}],"review_version":1}