Microsoft has successfully upstreamed a new Linux kernel driver called RAMDAX, set to debut in the upcoming 6.19 release, that allows system administrators to carve out portions of volatile RAM and present them as persistent memory DIMMs. The move gives Linux users—particularly those running virtualized and cloud workloads—a flexible, software-defined way to create high-speed, byte-addressable memory namespaces without specialized hardware.

What exactly changed?

The RAMDAX driver, authored by Microsoft engineer Mike Rapoport, has been merged into the libnvdimm-for-next branch, queued for the Linux 6.19 merge window. It treats memory regions allocated at boot—via kernel command-line memmap= options on x86 systems or dummy pmem-region device tree nodes on ARM platforms—as if they were NVDIMM DIMMs. Once bound, these regions appear to the kernel and user space as standard persistent memory devices that can host DAX (direct access) namespaces.

The driver works by reserving a 128 KiB metadata area at the end of each carved‑out region. This label space allows management of up to 509 namespaces per region, using the same ndctl tooling that administrators already use for real NVDIMMs. Binding is manual: you direct the driver to a specific e820_pmem or pmem-region device via the driver_override sysfs knob, giving operators fine‑grained control and reducing the risk of accidental activation.

Integration with existing subsystems is tight. Namespaces created on RAMDAX devices support both fsdax (file‑system DAX) and devdax (device DAX) modes, and they plug into the mature libnvdimm kernel framework without needing new APIs or custom user‑space tools.

What it means for you

The impact varies by audience, but the headline is that software‑defined memory just became a lot more accessible.

For Windows admins running Linux VMs

If you manage Linux guests on Hyper‑V, WSL2, or Azure, RAMDAX will let you carve out a piece of your VM’s allocated RAM and present it as a dedicated, high‑speed storage device. That’s a boon for:
- Caching layers: present a fast, byte‑addressable volume to a guest’s Redis or memcached instance.
- Transient high‑performance scratch space: format it with a DAX‑aware file system for short‑lived, write‑intensive workloads.
- Test/dev environments: accurately emulate persistent memory without tying up expensive NV‑Me‑attached PMEM or NVDIMM hardware.

Just remember: the data lives in ordinary RAM. Unless your hypervisor or platform adds battery‑backed protection, a host power loss will evaporate every byte.

For cloud operators and infrastructure teams

This driver signals a push toward dynamic, policy‑driven memory partitioning. Cloud providers—Microsoft among them—can use RAMDAX to offer tenants on‑demand memory‑tiered storage without firmware changes. Combined with orchestration tools, it becomes possible to instantly repurpose host RAM for high‑throughput, low‑latency namespaces and reclaim it when the workload ends, all while maintaining standard ndctl management interfaces. The benefits include faster provisioning, less hardware‑vendor lock‑in, and simpler lab testing for services that might later run over real persistent memory.

For developers and CI/CD pipelines

RAMDAX makes it trivial to build an ephemeral PMEM-backed testbed on any Linux box. Developers can run integration tests that simulate DAX device behavior without special hardware, and CI runners can spin up disposable namespaces for performance benchmarks. Because the driver uses the same kernel PMEM code paths, behavior observed with RAMDAX namespaces closely mirrors that of physical NVDIMMs, which helps catch bugs early.

How we got here

Microsoft’s relationship with the Linux kernel has evolved from a necessary evil for Hyper‑V paravirtualization to a strategic pillar of its cloud business. The company is a regular top‑10 contributor, and RAMDAX continues a pattern of open‑source work focused on memory and virtualization. Only a year ago, the same engineer, Mike Rapoport, introduced the memmap updates that allowed reserving arbitrary physical RAM for persistence emulation. RAMDAX takes that concept the next step: instead of merely mapping the region into the kernel’s memory map, it wraps the region with the complete NVDIMM device model.

Prior methods for faking persistent memory required either special firmware support, manual creation of DAX-over-RAM using device‑mapper targets (which lacked namespace label management), or static boot‑time configurations that couldn’t be changed without a reboot. RAMDAX introduces runtime‑selectable binding, namespace labels, and full ndctl compatibility, all while living within the well‑tested libnvdimm subsystem. The patch set was intentionally small—a single driver file plus Kconfig and Makefile tweaks—making it easier to review, merge, and backport.

The upstream acceptance puts RAMDAX on track to land in the mainline kernel this spring, exactly in step with the 6.19 release cycle. From there, it will flow into distribution kernels from Canonical, Red Hat, and SUSE, as well as into Microsoft’s own Azure‑tuned kernel.

What to do now

If you’re eager to experiment, the road is straightforward, but tread carefully.

  1. Wait for a kernel with RAMDAX enabled. Linux 6.19 will ship with the driver, but distributions may need time to enable CONFIG_RAMDAX. Check your kernel’s config (look for CONFIG_LIBNVDIMM=y and CONFIG_RAMDAX=y). If you build your own kernels, turn on those options under “NVDIMM Support”.

  2. Carve out memory at boot. On a test machine, add a memmap= argument to the kernel command line. For example, memmap=4G\$10G reserves 4 GiB of RAM starting at the 10 GiB physical address. Confirm the region appears as /dev/pmemX after boot.

  3. Bind the RAMDAX driver. Determine the platform device name (look for e820_pmem or your pmem-region device in sysfs). Then force‑bind:
    bash cd /sys/bus/platform/devices/e820_pmem echo ramdax > driver_override echo e820_pmem > /sys/bus/platform/drivers/ramdax/bind
    Verify with dmesg and ndctl that a new DIMM appears.

  4. Create a namespace. Use ndctl just as you would for a real NVDIMM:
    bash ndctl create-namespace --mode=fsdax --size=2G mkfs.ext4 -b 4096 -F /dev/pmem0 mount -o dax /dev/pmem0 /mnt/ramdax

  5. Test, but don’t trust persistence. Run your workload, then deliberately power‑off the host. After restarting, notice that the namespace metadata may survive (since it’s in the reserved 128 KiB), but any user data is gone. That’s the critical distinction: RAMDAX provides the interface of persistent memory, not the physical durability. Automate your setup scripts; never rely on data surviving a power cycle.

  6. Harden isolation. In any multi‑tenant scenario, enforce strict binding controls. Only allow driver_override writes from privileged orchestration agents. Use VM placement policies to prevent a guest’s DAX namespace from overlapping with host‑critical memory.

The road ahead

RAMDAX lands at a time when the lines between memory and storage continue to blur. CXL‑attached memory, NV‑Me‑over‑Fabrics, and software‑defined memory pools are all vying for mindshare. Microsoft’s driver gives the Linux ecosystem a low‑cost, high‑speed tool to explore those boundaries today. The real test will be how quickly hypervisor platforms (including Azure and Hyper‑V) adopt it for production workloads, and whether future Windows Server releases draw inspiration to create a similar in‑RAM tier for Hyper‑V guests.

For now, add the driver to your lab road map. Treat it as a sharp new tool that demands a well‑thought‑out safety playbook. If you do, RAMDAX may unlock a class of performance‑sensitive applications that previously needed exotic hardware.