Releases: PhialsBasement/MoCoLinux
Release list
MoCoLinux 0.5.9
MoCoLinux 0.5.9 brings working two-vCPU cooperative SMP to the Linux 7.1.5 guest on Windows 10.
- Runs two Linux processors concurrently on distinct host logical processors, with per-vCPU passage pages, switch state, timers, virtual interrupt state and posted-IPI delivery.
- Exposes the selected host processors' real physical-core/SMT relationship to the guest.
- Uses targeted Windows DPC doorbells and guarded posted-IPI polling, fixing the Firefox hardlock encountered during SMP bring-up.
- Hardens vCPU claiming, teardown, kick delivery and daemon error handling against failed starts and concurrent shutdown.
- Makes two vCPUs the installed default through
--cpus 2.
Validated on Windows 10 IoT Enterprise LTSC 21H2 build 19044 with a Core i5-3470 and Linux 7.1.5:
| Workload | 1 vCPU | 2 vCPUs | Scaling |
|---|---|---|---|
sysbench cpu --cpu-max-prime=20000, 10 s |
345.23 events/s | 682.96 events/s | 1.978x |
| OpenSSL SHA-256, 8192-byte blocks | 320,064.72 kB/s | 634,843.21 kB/s | 1.983x |
sysbench memory sequential write |
17,631.70 MiB/s | 35,828.47 MiB/s | 2.032x |
sysbench memory sequential read |
21,729.63 MiB/s | 42,494.90 MiB/s | 1.956x |
Firefox loaded pages normally after the IPI fix, stress/lock/context-switch tests completed, and the guest remained reachable over SSH. SMP beyond two vCPUs and replacing the TCP/VirtualGL presentation bottleneck remain future work.
SHA-256: 7c6da312ee11f85db10a0866723e776fe9b1c25df910e0d14a93760049c47a17 (MoCoLinux-0.5.9.zip)
MoCoLinux 0.5.6
MoCoLinux 0.5.6 raises the configurable guest-memory ceiling to 128 GB and makes large configurations practical on fragmented hosts.
- Accepts positive
--memvalues up to 131072 MB. - Backs guest RAM with independent host-memory blocks; no single physically contiguous allocation is required.
- Maps GPU/X guest memory on demand in 12 MB working-set windows instead of mapping the entire configured RAM size.
- Converts Windows user-mapping failures into clean allocation errors instead of bugchecks.
- Verified with a real 2048 MB boot: the guest reported 1.93 GiB usable and the virgl GPU initialized successfully.
SHA-256: 7f753312ffcf44684ac9f667135a575a36536c37bd5d8f77d60562c0d670ffd7 (MoCoLinux-0.5.6.zip)
MoCoLinux 0.5.5
Everything since 0.5.3.
Fragmented host RAM
- FragRAM — guest pseudo-physical memory now uses a dense p2m/m2p map backed by fragmented host pages instead of requiring one contiguous physical allocation.
- Safe KMAP publication — user mappings are exposed only after the complete RAM map exists, with teardown protected against active mappings.
- Guest transport updates — COBD and virtio-gpu use the new pseudo-physical mapping correctly. The complete Linux 7.1.5 patchset is included in the tagged source.
Graphics
- Split GPU descriptors — cogpu now resolves virtqueue descriptors across KMAP-window boundaries, preventing valid GPU requests from stalling when their buffers span fragmented RAM mappings.
- The established GPU completion and CoXWire paths from 0.5.3 are retained.
Installer
- Live build terminal — Setup streams new pacman and root-filesystem builder output into the Installing page, so long downloads and mirror failures are visible as they happen.
- Successful guest exchanges now retain their complete replies in the setup transcript for post-failure diagnosis.
The release package passed driver-signature, XP runtime, DLL dependency, payload, and ZIP integrity checks.
Install: unzip, then run mocolinux-setup.exe as administrator.
MoCoLinux 0.5.3
Everything since 0.4.0, verified on the ThinkCentre M92p.
Graphics
- GPU completion doorbell — the GPU daemon rings the driver when it publishes a completion, so a guest waiting on a fence no longer pays the monitor's backoff tick. Offscreen fence latency dropped ~9 ms → ~1 ms.
- CoXWire — the guest's X connection carried through guest RAM instead of slirp. glxgears 1024x768: 5 → 44 fps.
- 32-bit VirtualGL in the image (lib32-virtualgl / lib32-libjpeg-turbo), so 32-bit GL clients reach the card instead of failing to preload.
Stability
- coxwire X-stream corruption fixed — mlocked ring pages were being migrated by memory compaction out from under the host's pointers, desyncing the X protocol stream (BadLength/BadGC) under heavy load.
vm.compact_unevictable_allowed=0keeps compaction off them. - Torn ring-counter fix — network ring head/tail are now read/written as single aligned 32-bit accesses, ending the "tx ring is corrupt" slirp shutdowns under sustained traffic.
- 3 GB swapfile created on installs larger than 8 GB — no swap meant permanent direct reclaim under memory pressure (the sluggish-desktop cause).
Build / install
tools/build.shproduces a complete, signed, checked release (no Universal CRT, no missing DLLs); mirror list is chosen from published sync data without probing 125 servers.
Known limitation
- Steam's client UI (Chromium in Valve's pressure-vessel container) does not get GPU acceleration — its sandbox defeats VirtualGL's interposer. Ordinary apps (Firefox, KDE, glxgears) are hardware-accelerated as usual.
Install: unzip, run mocolinux-setup.exe as administrator.
MoCoLinux 0.4.0
Windows 10 support
MoCoLinux now runs on Windows XP x64, 7, 8.1 and 10 — all verified on hardware with hardware-accelerated OpenGL.
What's new since 0.3.0
- Windows 10 support. Two world-switch fixes for KVA Shadow (KPTI):
- CR4 before CR3 at the crossing. PCIDE controls whether CR3 bits 11:0 are a PCID. The guest clears PCIDE; writing the host's PCID-encoded CR3 with PCIDE still off raises #GP in the passage page → triple fault → instant machine freeze. Fixed by loading CR4 (with PGE cleared) before CR3.
- TSC_AUX saved and restored per crossing. Windows 10 stores the logical processor number in MSR 0xC0000103 for RDTSCP. The guest's
cpu_init()overwrites it, and PatchGuard verifies it hasn't changed — bugcheck 0x109 (CRITICAL_STRUCTURE_CORRUPTION, arg4=0x7, arg3=0xC0000103) minutes after boot. Saved into the existingtemp_cr3slot to avoid growing the shared state struct.
Requirements for Windows 10
- Test signing must be on (
bcdedit /set testsigning on— the installer does this) - No hypervisor (Hyper-V / VBS / HVCI must be off)
- The installer handles all checks and refuses to continue if conditions aren't met
Install
Download the zip, extract, and run mocolinux-setup.exe as Administrator. It installs the driver, daemons, kernel, GPU daemon with virglrenderer, X server, seed image and launchers, then boots Linux and builds a Manjaro desktop over the network (~15 min).
Contents
19 files including root-arch.img (the seed image), COPYING (GPL v2), the VcXsrv installer, and all launchers. Everything needed to go from a double-click to a running Manjaro desktop.
MoCoLinux 0.3.0
Windows 8.1 support
MoCoLinux now runs on Windows XP x64, Windows 7 x64 and Windows 8.1 x64, verified on hardware with hardware-accelerated OpenGL on the host's GPU.
What's new
- Windows 8.1 support. The installer handles Secure Boot detection, test signing with a post-reboot driver install, hypervisor detection (CPUID leaf 1 ECX bit 31), and UAC elevation for both the installer and the logon entry.
- GPU on NT 6.3. Fixed a 32-bit truncation of user-space mapping addresses in
co_manager_kmap—unsigned longis 32 bits under LLP64, so every KMAP slice above 4 GB lost its top half. XP and 7 place these mappings low; 8.1 does not. - Desktop shortcuts work.
--runtakes one argument; the shortcuts were passing two unquoted tokens, so the daemon rejected the second as an unknown parameter. Every app shortcut silently did nothing. - Terminal shortcut works on Vista+. Telnet Client is an optional feature, off by default since Vista. The shortcut now goes through
moco-term.bat, which finds or enables it. - Launcher works on non-C: installs.
moco-boot.vbsrannet sessionon XP (where it isn't needed) because VBScript'sAnddoesn't short-circuit;cogpu-daemonopened a hardcodedC:\MoCoLinux\log path. sign-driver.shcopies the build output first. Previously it signed a staledist-x64/linux.systhat nothing refreshed.
Reverted
- The hand-rolled MDL PFN fill (
MmGetPhysicalAddressper page +MDL_PAGES_LOCKED) bugchecked XP with 0x3B SYSTEM_SERVICE_EXCEPTION.MmBuildMdlForNonPagedPoolis explicitly documented as valid for user-space mappings and was innocent throughout.
Install
Run mocolinux-setup.exe as Administrator. It installs the driver, daemons, kernel, GPU daemon, X server and launchers, then boots Linux and builds a Manjaro desktop over the network (~15 min).
MoCoLinux 0.2.1 — launchers that know where they are
A bug-fix release. If 0.2.0 gave you a Linux desktop that drew everything in software despite the graphics support, this is why.
What was wrong
Four shipped scripts took the install directory from their arguments, and otherwise fell back to hardcoded paths — F:\xfer\mocolinux-m2 and E:\MoCoLinux, the layout of the machine they were written on. Correct there, wrong everywhere else.
Started without arguments, moco-boot.vbs launched the guest and the network bridge from whatever happened to be at that path, then failed on cogpu-daemon.exe with the system cannot find the file specified. What you got was a guest that boots, has a network, has windows, renders in software, and gives no indication why. On the test box that stale path held a pre-GPU build, so it even started older binaries first.
A second defect in the same file: it quit as soon as it saw a running guest, ensuring only the X server on the way out. Any other daemon could be missing while the guest ran — the GPU daemon can die, or never have started — and re-running the launcher could never repair it.
The fix
moco-boot.vbs and moco-icons.vbs take their directory from WScript.ScriptFullName, and the image directory from %SystemDrive% (which mocolinux.ini already assumes). xstart1142.bat and stop.bat use %~dp0. All four are installed beside the binaries they launch, so none of them needs telling. xstart1142.bat also had those staging directories as fallbacks after its own lookup — removed, because starting an unrelated X server is worse than reporting there isn't one.
moco-boot.vbs now checks each daemon individually instead of quitting early.
Verified
On Windows XP x64: with the guest running and cogpu-daemon.exe killed, the fixed launcher run with no arguments starts it. The guest then reports virgl (GeForce GT 730/PCIe/SSE2), OpenGL 4.2, direct rendering — the GPU path working under a 5.2 kernel, on the same binaries Windows 7 uses.
Not changed
No driver, kernel, daemon or image changes. Same linux.sys, same vmlinux, same cogpu-daemon.exe. If 0.2.0 is working for you, this changes nothing but the launchers.
Everything in the 0.2.0 notes still applies — read READ-ME-FIRST.txt, and in particular restart Windows between sessions.
SHA-256 of the zip:
352d8af0666ce87ebf15d20131c2b79e78b29ef75d629c9c1c2774de1878204d
GPL v2.
MoCoLinux 0.2.0 — the graphics card, and Windows 7
Linux runs inside Windows with no hypervisor, sharing the processor with it. 0.1.0 made that work; 0.2.0 gives it the graphics card.
OpenGL runs on real hardware
The guest's virtio-gpu driver now reaches an unmodified virglrenderer bound to a real WGL context on the Windows side. Applications send OpenGL, the card executes it.
moco-gl firefox
moco-gl glxgears
glxgears: 132 fps on a GeForce GT 730. Firefox renders rather than falling back. Every desktop shortcut already goes through moco-gl; the seed installs VirtualGL and mesa-utils to make it work.
Nine bugs in the device layer stood between 0.1.0 and this. The last one was the interesting one: virglrenderer asks for its first context with shared == false, and honouring that put it in its own WGL share group — so every object it created was invisible to every guest context that came after. glBindBuffer bound nothing, glMapBufferRange failed, and the window painted black while the GPU dutifully rendered into a namespace nobody could see.
What limits it now is delivery, not the card. Readback runs at 160 fps; frames reach the screen over the guest's network connection at 48. That is the next thing to fix.
Windows 7
Windows 7 x64 joins XP x64 and Server 2003 x64. The installer arranges test-signing during the restart it already performs, and tells you it did — the driver will not load otherwise, and you get a Test Mode watermark afterwards.
ssh
The guest runs sshd. Give the network daemon a redirection — colinux-slirp-net-daemon -R -r tcp:2222:22 — and connect to port 2222 on the Windows machine.
Installing
Extract the zip, run mocolinux-setup.exe, restart when it asks. It finishes by itself: boots Linux and has it build a complete Manjaro system on a fresh disk image, over your network. Fifteen minutes and about 2.5 GB.
Read READ-ME-FIRST.txt before deciding something is broken — in particular, restart Windows between sessions. Guest RAM has to come from Windows in unbroken 32 MB runs, and one run's worth of churn leaves physical memory too fragmented to supply them.
This is a kernel driver that swaps CPU context with Windows, at version 0.2.0. A bugcheck is possible. Do not put anything you care about on it.
SHA-256 of the zip:
d21769c16d2e0a2e9e88e223d7d2347157d06a519b637231f43e88d43e1b472a
GPL v2.
MoCoLinux 0.1.0 — Linux inside Windows XP x64, installing itself
Linux 7.1.5 running inside Windows XP x64 — no hypervisor, no emulation, no
virtualisation extensions. Both kernels resident on the same processor, taking
turns.
This release installs itself. Extract, run mocolinux-setup.exe, restart when
asked, and it finishes on its own: it boots Linux and has it build a complete
Manjaro system on a fresh disk image over your network. Afterwards Manjaro starts
at logon, and the desktop icons run Linux applications as ordinary Windows
windows.
Kate, xterm, Dolphin browsing the guest's cooperative block device, and Konsole —
each an XP window with a Luna frame and a taskbar button, beside Steam and the
Start button.
What works
- Manjaro with systemd to a multi-user target, ext4 root over a cooperative block device
- Processes in ring 3, 32-bit binaries, Landlock, user namespaces
- KDE applications as rootless native Windows windows over an X server on the host
- Networking: an ethernet device in the guest, NAT on the host,
pacmanover HTTPS - Preemption of a running task, and the host's clock as virtual time
- Asynchronous block I/O — the guest keeps scheduling while its disk works.
A full package install now answers the console in 16–125 ms; it used to freeze
the guest solid for minutes at a time and trip systemd's own watchdogs - Clean shutdown, and a run can be ended from another process
Verified end to end on a Lenovo ThinkCentre M92p (i5-3470): 217 console polls with
zero timeouts, 1.3 GB downloaded, no bugcheck, guest responsive throughout.
Requirements
Windows XP Professional x64 or Server 2003 x64 (the 5.2 kernel), an x86-64
processor, ~25 GB free on NTFS, a network connection, and administrator rights.
Every binary imports only DLLs a stock XP x64 has — no .NET, no Universal CRT, no
Visual C++ runtime.
Read this before deciding something is broken
- The first boot after a Windows restart is reliable and the second is not.
Guest RAM must come from Windows in unbroken 32 MB runs, and one run's churn
fragments physical memory enough that the next boot's allocations grind the
machine. Restart Windows between sessions. Top item inTODO. - Graphical applications render in software on the guest's single processor, so a
desktop feels slow. Indirect GLX caps hardware OpenGL at 1.4 regardless of the
card; the real fix needs a command stream and is not built. - No SMP — one processor in the guest.
- A bugcheck is possible. This is a kernel driver that swaps CPU context with
Windows, at version 0.1.0. Do not put anything you care about on it.
Not yet
SMP, the coLinux message layer (so colinux-console-nt cannot attach), a DHCP
client in the guest, inbound port redirects, and accelerated OpenGL. TODO is
specific about all of it.
sha256 d557cd9df7ed29bf7e621e43d3c059de27040bc1a4ed4a96832b89247b586a9d
GPL v2, as coLinux was. Built on Dan Aloni's cooperative Linux.

