Skip to content

Releases: PhialsBasement/MoCoLinux

MoCoLinux 0.5.9

Choose a tag to compare

@PhialsBasement PhialsBasement released this 08 Aug 19:06

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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 08 Aug 11:33

MoCoLinux 0.5.6 raises the configurable guest-memory ceiling to 128 GB and makes large configurations practical on fragmented hosts.

  • Accepts positive --mem values 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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 08 Aug 10:09

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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 06 Aug 16:13

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=0 keeps 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.sh produces 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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 06 Aug 09:45

Windows 10 support

MoCoLinux now runs on Windows XP x64, 7, 8.1 and 10 — all verified on hardware with hardware-accelerated OpenGL.

Manjaro on Windows 10 IoT Enterprise LTSC

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 existing temp_cr3 slot 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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 05 Aug 13:43

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_kmapunsigned long is 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. --run takes 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.vbs ran net session on XP (where it isn't needed) because VBScript's And doesn't short-circuit; cogpu-daemon opened a hardcoded C:\MoCoLinux\ log path.
  • sign-driver.sh copies the build output first. Previously it signed a stale dist-x64/linux.sys that nothing refreshed.

Reverted

  • The hand-rolled MDL PFN fill (MmGetPhysicalAddress per page + MDL_PAGES_LOCKED) bugchecked XP with 0x3B SYSTEM_SERVICE_EXCEPTION. MmBuildMdlForNonPagedPool is 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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 05 Aug 09:42

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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 04 Aug 16:18

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

Choose a tag to compare

@PhialsBasement PhialsBasement released this 03 Aug 16:13

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.

Manjaro with KDE running as native windows on Windows XP x64

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, pacman over 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 in TODO.
  • 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.