CEMU: Enabling Full-System Emulation of Computational Storage Beyond Hardware Limits

Computational storage drives (CSDs) put a small processor inside the SSD so data can be crunched where it lives instead of hauled to the CPU — a promising idea, but researchers cannot properly explore CSD designs, because real hardware and hardware emulators are stuck with whatever compute the physical device happens to have, while pure simulators do not faithfully model the whole operating system and I/O stack; this paper (Huazhong University of Science and Technology — Qiuyang Zhang, Jiguang Wan, and colleagues) presents CEMU, a software CSD emulator that runs the computation on the host CPU for full-system fidelity but models the timing separately, so it can pretend the CSD has far more computing power than any real chip, plus a new filesystem (FDMFS) that keeps it compatible with the existing I/O stack — matching real CSD hardware within 95 percent.

The argument in one glance

Problem

You cannot study a storage-computer you are not allowed to build

A computational storage drive (CSD) is a solid-state drive (SSD) with a processor inside it, so that computation can happen right where the data lives — near-data processing — instead of shipping the data across the system to the CPU. This is promising: for data-heavy work, moving the computation to the storage can save enormous amounts of data movement. But to design good CSD systems, researchers need a platform to experiment on, and the existing options are all inadequate. Real CSD hardware and hardware-based emulators (for example, built on FPGAs) are constrained by the physical compute resources actually on the device, so you can only study a CSD as powerful as the chip you happen to have — you cannot ask what a much more capable CSD would do. Pure software simulators, on the other hand, can model any device you like, but they lack full-system fidelity: they do not faithfully reproduce the real operating system, the input and output (I/O) stack, and the application all running together end to end. So the field was stuck: the faithful platforms could not go beyond their hardware, and the flexible platforms were not faithful.
What people did

Use real CSD hardware, FPGA emulators, or software simulators

Researchers reach for one of three kinds of platform. They run experiments on actual CSD hardware, which is fully realistic but rare and fixed. They build hardware emulators, often on FPGAs, which are more configurable than a shipped product but still bounded by the physical compute they contain. Or they use software simulators, which can model arbitrary devices but abstract away much of the real system.
Why it fell short

Each platform sacrifices either flexibility or full-system fidelity

None of the three lets you explore the full design space of CSD systems faithfully. Real hardware and FPGA emulators are limited by their physical compute: the on-device processor has a fixed, modest amount of computing power, so you cannot investigate a CSD with, say, ten times more compute, which is exactly the kind of forward-looking question designers want to ask. Software simulators remove that limit but pay for it in fidelity — they do not run the actual operating system, file system, and I/O stack that determine how a CSD really behaves inside a working system, so their conclusions may not hold in practice. The research platforms are also fragmented, each capturing a different slice of the problem. What was missing is a single platform that is at once configurable beyond hardware limits — able to emulate CSDs far more powerful than any available chip — and full-system faithful, running the real software stack so that measured behavior reflects reality.
This paper's idea

Run the compute for real, but model its timing separately

CEMU is a software-based CSD emulation platform for full-system research, with two parts: a CSD device emulator and a CSD-oriented software stack. The device emulator's central trick is to separate what the computation does from how long it is supposed to take. The emulated CSD uses the host CPU to physically perform the computation, so real data flows through real code and produces real results — preserving full-system behavior — but the computational delay is modeled separately, so CEMU can report the timing of a CSD with far more (CPU-unbounded) computing power than the host actually has. A novel virtual machine freezing mechanism makes this configurable: it lets CEMU control the emulated device's sense of time independently of the host's real execution, so the modeled delay, not the host's speed, determines the emulated performance. The software stack follows two principles: it adheres to recent industry CSD standards, so experiments are realistic, and it is compatible with the existing I/O stack, achieved through a newly developed file system called FDMFS, so ordinary applications and the real operating system can use the emulated CSD unchanged. The authors verify CEMU against actual CSD hardware across a range of applications, reporting average end-to-end performance accuracy of 95 percent or higher, and use two case studies — large language model training and the LevelDB key-value store — to show CEMU can explore CSD research questions and reveal insights previous platforms could not.

Why this problem is worth solving

Computational storage could remove one of computing’s biggest costs — moving data — but only if designers can actually explore how to build it well.

In a conventional system, data lives on the SSD and computation happens on the CPU, so any processing means reading the data off the drive, across the interconnect, into the processor, and often writing results back — and for data-intensive workloads, that movement dominates both time and energy. A computational storage drive puts a processor inside the SSD so that some computation can run right at the data, sending back only results. This near-data processing can dramatically cut data movement for the right workloads, which is why it is a major direction in storage research. But CSDs are a young, wide-open design space: how much compute should sit in the drive, how should it be programmed, how should the operating system and applications talk to it, which computations are worth offloading? Answering these questions requires experimenting, and experimentation requires a research platform that is both realistic and flexible. Because the whole value of a CSD depends on subtle interactions between the device, the I/O stack, and the application, a platform that cannot faithfully capture the full system, or cannot model devices beyond what exists today, will give misleading answers. Getting the research infrastructure right is therefore a prerequisite for the field to make progress, which is what makes this an important problem.

The difficulty is a genuine tension between fidelity and flexibility that no prior platform escaped.

The three kinds of platform sit at different, unsatisfying points. Real CSD hardware is perfectly faithful — it is the real thing — but it is scarce, fixed in its capabilities, and you cannot reconfigure it to ask what a different or more powerful CSD would do; you are limited to the exact compute the vendor put in the drive. FPGA-based emulators are more configurable and let researchers prototype custom logic, but they are still bounded by the physical compute resources of the FPGA, so they too cannot emulate a CSD substantially more capable than the hardware in hand, and building on them is laborious. Software simulators flip the trade-off: they can model any device, including hypothetical powerful ones, but to do so they abstract the system, and they typically do not run the real operating system, the real file system, and the real I/O stack with the application on top. That matters because a CSD’s real-world performance is determined by exactly those layers — how requests flow through the kernel, how the file system places and accesses data, how the application issues I/O. A simulator that omits them can be precise about an idealized device and still wrong about a real system. So designers were forced to choose between platforms that are faithful but inflexible and platforms that are flexible but unfaithful, and neither can explore CSD systems beyond hardware limits with full-system realism.

What people did before, and where it broke

Experiment on real CSD hardware. Run studies on an actual computational storage drive. Where it broke. It is faithful but scarce and fixed: you are limited to the exact compute the device contains and cannot reconfigure it to explore other or more powerful CSD designs.
Build FPGA-based hardware emulators. Prototype CSD logic on an FPGA for more configurability. Where it broke. It is still bounded by the FPGA’s physical compute resources, so it cannot emulate a CSD much more capable than the hardware, and it is laborious to build.
Use software simulators. Model arbitrary CSD devices in software to escape hardware limits. Where it broke. Simulators lack full-system fidelity — they do not run the real operating system, file system, and I/O stack with the application, so conclusions may not hold on a real system.
Accept fragmented, single-purpose platforms. Use whichever platform captures the slice of the problem at hand. Where it broke. The platforms are fragmented and inadequate for exploring the full design space, forcing a choice between fidelity and flexibility on every study.
The gap. No platform was simultaneously full-system faithful (running the real software stack) and configurable beyond hardware limits (able to emulate CSDs far more powerful than any available chip).

How CEMU works

Emulating a more powerful CSD than you own, faithfully

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Bring the computation to the data — and study how to do it well. CEMU exists to advance computational storage, whose whole premise is running computation inside the drive so data need not travel to the CPU. Placing domain-specific computation inside the storage device to avoid moving data across the system is the same principle the work on in-storage domain-specific acceleration for serverless computing covered elsewhere on this site is built on, exploiting near-data execution to cut the cost of data movement. CEMU does not itself add a new in-storage accelerator; it builds the research platform that lets designers explore such CSD systems faithfully, which the near-data field needs to progress.

Make an emulator that transcends the hardware you actually have. The heart of CEMU is a research platform that lets you experiment on devices more capable than any you can build, by running real software while modeling the timing of a hypothetical device. Providing a configurable platform to prototype and study hardware designs that do not yet exist, rather than being limited to available silicon, is the same goal the work on a scalable multi-FPGA architecture prototype platform in the cloud covered elsewhere on this site pursues, giving researchers a reconfigurable stand-in for hardware. CEMU’s distinctive move is to keep full-system fidelity by executing the computation for real on the host, while decoupling the reported timing so the emulated CSD can be arbitrarily powerful.

Slot the new device into the real operating system, not a toy. CEMU insists on full-system realism, so it exposes the emulated CSD through the actual I/O stack, developing a file system (FDMFS) so unmodified applications and the real kernel use it as they would a real drive. Introducing system support and a file system so a novel storage device works within the existing operating-system I/O stack is the same undertaking the work on system support for CXL-based memory-semantic solid-state drives covered elsewhere on this site takes on, making a new class of storage usable by ordinary software. This is what lets CEMU measure how a CSD behaves in a genuine full system rather than in isolation.

Following a study through CEMU

Exploring whether a much more powerful CSD would speed up LLM training

An illustrative walk-through, based on the paper's abstract, of how CEMU studies a beyond-hardware CSD design. Exact internal mechanisms should be read from the full paper.

Step 1 of 5

Pose a beyond-hardware question

A researcher asks whether offloading part of large language model training to a CSD with, say, far more compute than any real drive would help. No real device with that much in-storage compute exists to test on.

The question requires emulating hardware beyond what is available.

Why it works

Executing for real preserves full-system behavior. A simulator that fakes the computation loses fidelity → but running the CSD’s computation on the host CPU produces real data and results → so the operating system, I/O stack, and application behave exactly as they would with a real device.
Decoupling timing lifts the hardware ceiling. Real hardware and FPGA emulators are capped by their physical compute → but modeling the computational delay separately from the physical execution → so CEMU can report the performance of a CSD far more powerful than the host.
VM freezing makes the timing controllable. If the host’s wall-clock speed drove the result, you could not emulate a faster device → but freezing the virtual machine lets CEMU advance emulated time by the modeled delay → so the configured device, not the host, determines measured performance.
A standards-compliant, compatible stack keeps it realistic. A bespoke interface would not reflect real usage → but adhering to industry CSD standards and slotting into the existing I/O stack via FDMFS → so unmodified applications and the real kernel exercise the emulated CSD authentically.
Fidelity plus flexibility reveals hidden insights. Fixed hardware cannot explore new designs and unfaithful simulators mislead → but CEMU is both faithful (95 percent or higher versus real hardware) and configurable beyond hardware → so it surfaces effects, as in the LLM-training and LevelDB studies, that prior platforms missed.

What it costs (trade-offs and scope)

This explainer is from the abstract only. The full paper was not available when this page was written, so the descriptions of the virtual-machine freezing mechanism, the delay model, and FDMFS are at the level the abstract states; their internal designs and the exact experimental methodology are not reproduced here and should be read from the paper. (The artifact is open-source at the authors’ repository.)
Modeled timing is only as good as the model. CEMU preserves behavior by running the computation for real, but the emulated performance of a beyond-hardware CSD comes from a separate delay model; the reported 95 percent-or-higher accuracy is measured where real hardware exists to compare against, and for hypothetical devices the results are only as trustworthy as the timing model.
Running compute on the host consumes host resources. Physically performing the CSD’s computation on the host CPU is what gives fidelity, but it means the host must actually do the work; emulating a very powerful CSD still runs its computation at host speed underneath, with only the reported timing adjusted, so throughput of the emulation is bounded by the host.
It targets CSD systems and the storage I/O stack. CEMU is built around computational storage drives, the industry CSD standards, and the file-system and I/O-stack layers; it is a platform for that domain rather than a general-purpose accelerator emulator, and applying it elsewhere would require different device and stack models.
Findings come from specific case studies. The demonstrated insights are from large language model training and LevelDB; other workloads may exercise different parts of the design space, and the platform’s value on them would need its own study.

The evaluation

Platforms for computational-storage research

Property	Real CSD hardware	FPGA emulator	Software simulator	CEMU
Full-system fidelity
Emulate beyond available compute
Runs real OS, file system, application
Configurability
Accuracy versus real hardware

A comparison, drawn from the paper's abstract, of platforms for computational-storage research. CEMU runs the CSD computation on the host for full-system fidelity but models timing separately (via a virtual-machine freezing mechanism) to emulate CSDs beyond hardware limits, and exposes the device through a standards-compliant stack and the FDMFS file system, achieving average end-to-end accuracy of 95 percent or higher against real CSD hardware.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based only on the paper’s abstract; the full text was not available when it was written, so this page is marked as a draft. The claims stated here are the abstract’s: computational storage drives (CSDs) improve performance through near-data processing in SSDs, but current research platforms are fragmented and inadequate — hardware and emulator platforms are constrained by physical compute resources, while simulators lack full-system fidelity. CEMU is a software-based CSD emulation platform for full-system research, consisting of a CSD device emulator and a CSD-oriented software stack. Through a novel virtual machine freezing mechanism, CSD emulation achieves high configurability; the CSD uses the host CPU to physically perform computation to preserve full-system behaviors, while the computational delay is modeled separately to emulate CSDs with CPU-unbounded high computing power. The software stack adheres to recent industry CSD standards and is compatible with the existing I/O stack, achieved via a newly developed file system FDMFS. The authors verify CEMU’s emulation fidelity across a range of applications by benchmarking against actual CSD hardware, reporting average end-to-end performance accuracy of 95 percent or higher, and use two case studies (large language model training and LevelDB) to show CEMU can explore CSD system research and uncover insights not found on previous platforms. The internal designs of the freezing mechanism, the delay model, and FDMFS, and the exact methodology, are not described in the abstract and have not been invented here; they should be confirmed in the full paper (the artifact is open-source). The illustrative walk-through above is a plausible reconstruction, not a trace from the paper.

Background

Why research infrastructure quietly shapes what gets built

It helps to see CEMU as part of an often-overlooked truth: the tools researchers use to experiment quietly determine which ideas can even be explored. In computer architecture and systems, new hardware ideas rarely start on real silicon, because fabricating a chip is slow and expensive; instead they are explored on simulators, emulators, and prototype platforms, and the strengths and blind spots of those tools bound the questions the field can ask. Computational storage is a young area precisely at the intersection of hardware and the software stack, where the interactions between a device, the operating system, and applications are the whole point — so a platform that captures the device but not the system, or the system but not a hypothetical device, cannot answer the questions that matter. The recurring solution is to build better research infrastructure that widens the design space while staying faithful, whether by decoupling timing from execution, by making hypothetical hardware usable through real software, or by prototyping devices that do not yet exist. The broader effort to move computation into storage and study how such near-data systems should be organized end to end is the same terrain the work on exploiting near-data processing for scalable inference covered elsewhere on this site explores, pushing computation toward the data. CEMU contributes the platform that lets the computational-storage community explore beyond the hardware they happen to own, arguing that faithful, flexible emulation is what unlocks the next round of CSD ideas.

If you remember only three things

1. Computational storage drives (CSDs) put a processor inside the SSD so computation runs near the data (avoiding moving it to the CPU), but researchers could not properly explore CSD designs. Real hardware and FPGA emulators are limited to the physical compute on the device (so you cannot study a more powerful CSD than you have), while software simulators lack full-system fidelity (they do not run the real operating system, file system, and I/O stack), so there was no platform that was both flexible and faithful.
2. CEMU is a software-based CSD emulation platform with a device emulator and a CSD-oriented software stack. Its key trick is to run the CSD's computation physically on the host CPU (preserving full-system behavior with real data and results) while modeling the computational delay separately, so it can emulate CSDs with far more computing power than the host — made configurable by a novel virtual-machine freezing mechanism that controls the emulated device's sense of time. Its software stack adheres to industry CSD standards and stays compatible with the existing I/O stack through a new file system, FDMFS, so unmodified applications and the real kernel use the emulated CSD.
3. Benchmarked against actual CSD hardware across a range of applications, CEMU achieves average end-to-end performance accuracy of 95 percent or higher, and case studies on large language model training and LevelDB reveal insights previous platforms could not surface. The trade-offs: emulated timing of beyond-hardware devices is only as good as the delay model, running the compute on the host consumes host resources, and it targets the CSD and storage-I/O domain. (This page is written from the abstract only; the freezing mechanism, delay model, and FDMFS internals should be confirmed in the paper.)

Check yourself

Check your understanding

1. Why were existing platforms inadequate for computational-storage research?
2. What is CEMU's central trick for emulating a CSD more powerful than the host?
3. Why does CEMU include a new file system (FDMFS) and follow industry CSD standards?
4. Predict: a researcher uses CEMU to emulate a CSD with ten times the compute of any real device and measures a large speedup on a workload. How much should they trust the result, and why?

Sources

The paper is “CEMU: Enabling Full-System Emulation of Computational Storage Beyond Hardware Limits” by Qiuyang Zhang, Jiapin Wang, You Zhou, Peng Xu, Kai Lu, Jiguang Wan, Fei Wu, and Tao Lu (Huazhong University of Science and Technology and collaborators), published at ASPLOS 2026, DOI 10.1145/3779212.3790137. It is licensed CC BY. The artifact is open-source at the authors’ repository (cs-qyzhang/CEMU).

This explainer is written from the paper’s abstract only; the full text was not available at the time of writing, so this page is marked as a draft. According to the abstract, computational storage drives (CSDs) improve performance through near-data processing in SSDs, but current research platforms are fragmented and inadequate: hardware and emulator platforms are constrained by physical compute resources, while simulators lack full-system fidelity. CEMU is a software-based CSD emulation platform enabling full-system research, consisting of a CSD device emulator and a CSD-oriented software stack. Through a novel virtual machine freezing mechanism, CSD emulation achieves high configurability; the CSD can utilize the host CPU to physically perform computation to preserve full-system behaviors, while the computational delay is modeled separately to emulate CSDs with CPU-unbounded high computing power. The software stack adheres to recent industry CSD standards and is compatible with the existing I/O stack, achieved via a newly developed file system FDMFS. The authors verify CEMU’s emulation fidelity across a range of applications by benchmarking against actual CSD hardware, demonstrating average end-to-end performance accuracy of 95 percent or higher, and use two case studies on large language model training and LevelDB to demonstrate that CEMU is effective in exploring CSD system research and can uncover insights not discovered on previous research platforms. No numbers or mechanisms beyond the abstract have been introduced here; the internal designs of the freezing mechanism, delay model, and FDMFS, and the full methodology, should be confirmed in the full paper.