GoKawiilFrom DrvFs in WSL 1 to Plan 9 to virtiofs, cross-OS file access in WSL 2 has improved with each generation. A new change gives each virtio device its own dedicated DMA pool, removing the last major contention point on the virtiofs path.
If your workflow crosses the Windows/Linux boundary, file I/O performance in WSL 2 has been getting steadily better. A change landed in WSL 2 in May 2026 that removes one of the last remaining bottlenecks on the virtiofs path. To understand why it matters, it helps to follow how cross-OS file access has evolved.
How we got here
WSL 1 (2016) handled Windows drive access through DrvFs, a custom filesystem driver running inside the Windows NT kernel. Because WSL 1 ran Linux processes directly on the Windows kernel through a compatibility layer, file operations on /mnt/c could reach NTFS almost directly. Performance was good for file-heavy workloads.
WSL 2 (May 2019) replaced that model with a full Linux kernel in a lightweight Hyper-V VM. That was the right trade: real Linux kernel calls, proper syscall compatibility, and much better performance for Linux-native workloads. For cross-OS access, the VM boundary meant a different approach was needed. Microsoft built a Plan 9 (9P) file server into the Windows-side WSL service. Your Linux session connects to it over a Hyper-V socket at boot, and file operations on /mnt/c travel through that 9P protocol channel.
9P over a Hyper-V socket works, but it has protocol overhead: each operation is bounded by a message size parameter ( msize=65536 , 64 KB). File-heavy workloads that hit many small files carry that overhead on every round trip. Microsoft has been iterating on this since WSL 2 launched.
Around 2021, virtiofs arrived as an experimental opt-in. Virtiofs uses the VirtIO transport for shared-memory file access, reducing serialization overhead compared to 9P. You enable it in the [wsl2] section of your .wslconfig with virtiofs=true . It has been working its way through incrementally since then: device reuse improvements in PR #40298, shared mmap support without DAX in PR #40426, and now the DMA layer fix.
The DMA layer
Virtual machines on Hyper-V perform DMA for I/O through bounce buffers: a reserved memory region below the 4 GB DMA boundary that hardware can address directly. The Linux kernel calls this the SWIOTLB pool. Until recently, all virtio devices in a WSL 2 session shared one global pool. A virtiofs mount for /mnt/c , one for /mnt/d , and the virtio network adapter all queued into the same buffer, contending with each other during heavy I/O.
PR #40654, authored by Ben Hillis and merged May 27, 2026, gives each virtio device its own dedicated DMA pool. The kernel allocates a contiguous physical range below 4 GB at boot, publishes its address through sysfs ( /sys/bus/vmbus/drivers/hv_pci/swiotlb_base and swiotlb_size ), and the WSL service reads those values and injects a per-device swiotlb= option into each virtio device at creation time. No more shared queue between drives and the network adapter.
... continue reading