RayNu-V Making buddies

A guided read · real iron

A chat with Mr. COM2

The first nine chapters are one unedited serial capture from a Dell PowerEdge R640 booting RayNu-V on 2026-08-15. Chapters 10–12 are later iron, same three voices: the USB walk, the RAID disks, and the guest firmware that lets an operating system speak.

How to listen yourself: every PowerEdge ships with an iDRAC — the Integrated Dell Remote Access Controller, a tiny computer inside the computer. ssh into it and run console com2, and Serial over LAN (SOL) pipes the machine’s second serial port — COM2 — to your terminal. RayNu-V writes everything there. Below, each beat of the boot appears three ways: what COM2 says (the real bytes), what computer science says should happen here, and what RayNu-V says it just did. Monikers are expanded once, at first appearance.

1 · The handshake

COM2 says

Booting from Virtual Floppy Drive
RayNu-V r640-hypervisor — formally verified bare-metal hypervisor
pillars: [V] verified · [Z] single-binary · [D] iDRAC · [A] audit
serial: COM1+COM2 mirror (iDRAC SOL = console com2)
RAYNU-V-M0-BOOT-OK

Computer science says

A UEFI (Unified Extensible Firmware Interface) application starts life inside firmware — no drivers, no OS, nothing. The cheapest way to prove you are alive is a UART (Universal Asynchronous Receiver/Transmitter): put bytes on a wire at an agreed baud rate. No negotiation, no stack. If your banner prints, milestone M0 is real.

RayNu-V says

The banner prints on real iron, and the audit chain opens with the very first line (RAYNU-V-AUDIT: BootStarted follows immediately after). From byte one, this machine is keeping receipts.

2 · Taking the machine

COM2 says

boot: probing PE/ESP assets (pre-EBS)
boot: PE assets embedded (.askern/.asinit) — prefer PE
RAYNU-V-M3-ASSETS-OK
boot: calling ExitBootServices — ConOut/video ends after this line
boot: ExitBootServices returned; scanning conventional memory
boot: conventional regions=9 pages_above_1MiB=16574029
boot: frame pool clipped to guest RAM [1MiB,256MiB); BAR/shell window free
boot: frame pool phys=0x1000000 pages=61440
RAYNU-V-M1-EBS-OK

Computer science says

Until ExitBootServices (EBS), the firmware owns the machine: its console, its memory map, its rules. After that call returns, the hypervisor owns everything — and firmware conveniences (like the video console, ConOut) are gone. The kernel image and initrd (initial ramdisk) ride inside the single binary as PE (Portable Executable) sections — .askern/.asinit — found on the ESP (EFI System Partition) before EBS, because after EBS there is no filesystem to ask.

RayNu-V says

Assets found, firmware politely dismissed, 16,574,029 pages counted, and a frame pool clipped for guests — with the device BAR (Base Address Register) window deliberately left free. Owning the memory map is what makes a hypervisor a hypervisor.

3 · Root mode

COM2 says

boot: VMXON region phys=0x1003000
RAYNU-V-M1-VMXON-OK
RAYNU-V-AUDIT: VmxEnabled vcpu_id=0

Computer science says

Intel’s virtualization extensions (VMX, marketed as VT-x) split the CPU into root mode (hypervisor) and non-root mode (guests). VMXON enters root operation. From here, every guest runs inside a VMCS — a Virtual Machine Control Structure that declares, per virtual CPU, exactly what it may do without asking.

RayNu-V says

VMXON on the R640’s Xeon, audited. The CPU is now ours to lend.

4 · The isolation engine

COM2 says

boot: EPT page_size=2M
boot: precise EPT [0,512MiB); APIC MMIO unmapped
boot: guest CR3 (precise identity)=0x1007000 host CR3=0x47e01000
RAYNU-V-AUDIT: EptMapped guest_id=1
RAYNU-V-AUDIT: EptMapped guest_id=1
RAYNU-V-AUDIT: EptMapped guest_id=1
boot: ADR-004 ownership selftest ok

Computer science says

Extended Page Tables (EPT) are hardware second-level address translation: guest-physical addresses get rewritten to host-physical frames by the CPU itself. If a frame is not mapped, the guest cannot touch it — full stop. CR3 is the register holding the page-table root; host and guest keep distinct roots. Note the APIC (Advanced Programmable Interrupt Controller) MMIO (memory-mapped I/O) window deliberately unmapped: even the interrupt controller is fenced out of guest space — a guest that could program it would fire inter-processor interrupts at the host or its neighbors.

RayNu-V says

A precise [0, 512 MiB) guest window, a separate host CR3, every mapping audited — and the ADR-004 ownership selftest passing on iron. This is the property the Verus proofs machine-check: “exclusively owned by one guest, belonging to neither the hypervisor nor any other guest.”

5 · Loading a real kernel

COM2 says

boot: load kernel=0x1200000 entry=0x1200200 initrd=0x1bc0000
      boot_params=0x1bc2000 cmdline=0x1bc1000 magic=0x53726448
RAYNU-V-M3-LOAD-OK
RAYNU-V-M3-BZIMAGE-OK
boot: real Linux bzImage detected
boot: e820_entries=3

Computer science says

Linux on x86 boots via a decades-old contract: a zero page of boot parameters, a command line, an initrd, and the e820 memory map the firmware would normally supply. The magic number 0x53726448 is literally “HdrS” — the bzImage (big compressed kernel image) signature. Check the magic, fill the contract, jump.

RayNu-V says

That is a genuine, unmodified Linux 6.12.40 bzImage out of the embedded asset — not a toy payload. We hand it a faithful boot protocol and get out of the way.

6 · The trap door

COM2 says

boot: VMLAUNCH → guest store+loop+HLT + IRQ inject (EPT)
boot: VMEXIT phase=00000000 reason=0x0000000c rip=0x000000000100a0a7
RAYNU-V-M1-VMEXIT-OK
RAYNU-V-M2-EPT-OK  RAYNU-V-M2-GUEST-OK  RAYNU-V-M2-OWN-OK  RAYNU-V-M2-ALLOC-OK
boot: software inject vector 0x00000021 + VMRESUME
boot: VMEXIT phase=00000001 reason=0x00000001
boot: external IRQ vector=0x00000021
boot: APIC EOI ok
boot: timer re-inject vector 0x00000021 + VMRESUME
boot: VMEXIT phase=00000003 reason=0x0000000c
RAYNU-V-M2-TIMER-OK

Computer science says

VMLAUNCH drops the CPU into non-root mode; the guest runs until hardware says otherwise — a VMEXIT. Reason 0x0c is HLT (the guest halted); reason 0x01 is an external interrupt. The hypervisor injects a timer IRQ (interrupt request) as vector 0x21, the LAPIC (Local APIC) delivers it, the guest acknowledges, the host sees the EOI (end-of-interrupt), and VMRESUME re-enters. That loop is the heartbeat of every hypervisor on earth.

RayNu-V says

Full cycle on iron: guest runs, halts, takes a timer interrupt, comes back, and asks for another. Four M2 markers in one breath — EPT, guest execution, ownership, allocator — because this one loop exercises all of them.

7 · Unmodified Linux speaks

COM2 says

boot: entering 64-bit Linux rip=0x0000000001200200
boot: Linux CR4.VMXE host-owned
Linux version 6.12.40 (ubuntu@cursor) (gcc …) #2 Sun Jul 19 2026
Command line: earlyprintk=serial,ttyS0,115200,keep rdinit=/init …
NX (Execute Disable) protection: active
CPU topo: Num. cores per package:     1
… pages, zones, hash tables, XSAVE feature list …
FreeiRAYNU-V-M3-GTIMER3-OK
ng initrd memory: 4K
Run /init as init process
RAYNU-V-M3-SHELL-OK
RAYNU-V-M3-NOIRQ-OK

Computer science says

earlyprintk writes straight to the UART before the kernel’s console stack exists — that is why you can watch a kernel think. CR4 is a control register; its VMXE bit turns VMX on, and here it is host-owned, so the guest cannot switch the hypervisor off (a lesson that later saved our guest-firmware work — see the Stories page). NX is the no-execute bit. And the charming FreeiRAYNU-V… mid-word collision is what happens when Linux and the hypervisor print in the same microsecond: one wire, two authors, zero editing.

RayNu-V says

A real distro kernel walks its whole bring-up — memory map, CPU topology, XSAVE feature negotiation, initramfs unpack — and lands at Run /init and a shell, under our EPT, with the guest timer (GTIMER) markers green. Nothing about the guest was modified to make this work.

8 · Four guests, one scheduler

COM2 says

boot: M4.2 — launching shell guest slot=00000001 id=0x…02
… slot 2, slot 3 launch the same way …
RAYNU-V-M4-2VM-OK
boot: credit scheduler armed slots=0..00000003
boot: sched switch → slot=00000000
RAYNU-V-M4-SLICE-G0
boot: sched switch → slot=00000001
RAYNU-V-M4-SLICE-G1
… G2, G3 sliced in turn …
RAYNU-V-M4-SCHED-OK
RAYNU-V-M4-NVM-OK

Computer science says

Virtualization is CPU multiplexing: a credit-based scheduler hands out time slices, and each guest lives behind its own VMCS and EPT so isolation holds per guest, not per machine. Four guests on one core means four clean entries and exits per round-robin — every switch a full VMCS swap.

RayNu-V says

One Linux plus three shell guests, time-sliced under the credit scheduler, each printing its SHELL marker through its own private EPT. Multi-VM is not a slide; it is slots 0–3 taking turns on the wire.

9 · Devices, two vCPUs, and the marker

COM2 says

boot: VMLAUNCH → virtio-blk status probe
RAYNU-V-M4-BLK-OK
boot: M4.3 complete — virtio-blk MMIO handshake + write/readback
boot: VMLAUNCH → virtio-net dual-port probe
RAYNU-V-M4-NET-OK
boot: M4.5 BSP ready — waking AP
boot: AP wake via host VMLAUNCH (documented INIT-SIPI equiv)
RAYNU-V-M4-SMP-OK
boot: VMXOFF ok
boot: E2 marker build=r640-boot-ok-marker
RAYNU-V-R640-BOOT-OK
RAYNU-V-R640-BOOT-OK
RAYNU-V-R640-BOOT-OK

Computer science says

virtio is the paravirtual device standard — guests talk to virtual disks and network cards through shared-memory rings instead of emulated hardware. SMP (symmetric multiprocessing) means a BSP (bootstrap processor) waking an AP (application processor); real hardware does it with INIT-SIPI inter-processor interrupts, and a hypervisor may document a host-side equivalent. VMXOFF then leaves VMX mode as cleanly as VMXON entered it.

RayNu-V says

Disk handshake with write/readback, a dual-port virtual switch exchange, two vCPUs under one shared EPT — then a polite VMXOFF and the marker, three times, for the camera. That is the whole loop: firmware to four guests to a clean exit, on a real Dell PowerEdge R640, with every step on the record.

This marker build exits VMX at the end of the path. Later builds keep VMX on — the management plane serves HTTP beside running guests (ADR-013 Phase F, 2026-08-20; the story).

10 · Walking a USB port

COM2 says

boot: Stage 46 xhci caplen=0x00000080 slots=64 ports=26
boot: Stage 46 xhci enum p11 vid=0x00000480 did=0x0000a004
boot: Stage 46 xhci bot p11 iface=08/06/50 ep_out=2 ep_in=1
boot: Stage 46 durable LUN usb I/O ready bytes=320072933376

Computer science says

xHCI (eXtensible Host Controller Interface) is the register file a modern USB host uses. After ExitBootServices the firmware’s USB stack is gone, so the hypervisor has to run the state machine itself: reset a port, give the device an address, read its descriptors, then Set Configuration. Class 08/06/50 is mass storage, SCSI transparent, Bulk-Only Transport. A command is a CBW (Command Block Wrapper), the data follows, and a CSW (Command Status Wrapper) says whether the disk accepted it. Skip a step and the stick stays a silent port.

RayNu-V says

Twenty-six ports, one connected device on port 11, descriptors, then a bulk pipe that can read. That walk is how a disk plugged into the R640 survives the moment firmware leaves. The bytes on the wire are the same idea as a spinning disk’s SCSI commands — only the transport is USB instead of a RAID mailbox.

11 · The disks behind the RAID card

COM2 says

boot: perc ld status=0x00 n=2 id=0 class=ubuntu id=1 class=spare pick=1
RAYNU-V-M8-PERC-WRITE-OK
RAYNU-V-M8-PERC-LUN-OK
virtio_blk virtio0: [vda] 20971520 512-byte logical blocks (10.0 GiB)
 vda: vda1 vda2 vda3

Computer science says

A RAID controller hides spindles behind a virtual disk. The host posts a command through a mailbox — here the Fusion-MPT frame — and waits for a status byte. Two logical disks came back: the machine’s own Ubuntu volume, and a spare. The guest must not be handed the host’s boot disk. It is handed a slice of the spare, presented as a virtio block device, which is a shared-memory ring rather than a fake IDE controller.

RayNu-V says

We listed the logical disks, wrote one sector at the spare’s last LBA and read it back, then published a 10 GiB vda. Linux saw vda1, vda2, and vda3. UBUNTU0 stayed the host. The rest of the 2.9 TB spare is not this disk.

12 · A firmware the guest can call

COM2 says

boot: RayNu-F direct — OVMF leg bypassed
boot: RayNu-F found \EFI\ubuntu\grubx64.efi
GNU GRUB  version 2.14
*Ubuntu
boot: RayNu-F initrd ext4 bytes=34338680 name=initrd.img-7.0.0-14-generic
Linux version 7.0.0-14-generic
vikkp@raynusrv2:~$

Computer science says

A guest operating system does not boot from page tables alone. It expects firmware: an EFI system table, boot services, a way to read a disk, and LoadImage / StartImage so its own loader can run. GRUB and the Linux EFI stub call those services the way an application calls an operating system. A hypervisor that only has VMX and EPT has no one for them to call. Borrowing a foreign firmware means living inside invariants you do not own. The friendly path is to be the firmware.

RayNu-V says

RayNu-F is that firmware, inside the same binary. It published the Ubuntu grubx64.efi, let GNU GRUB 2.14 draw the menu, then copied initrd.img-7.0.0-14-generic into the stub’s buffer. Linux 7.0.0-14-generic reached vikkp@raynusrv2:~$. Without RayNu-F, that guest would have had no UEFI to talk to. M8.9 is the next conversation on this wire, in stages. M8.9.1 stores the record. The shell still has no network of its own until a later save.

That is the entire conversation — unedited bytes are in the raw transcript (SHA-256 checksummed in SHA256SUMS). For the days COM2 brought worse news — a hang, a timeout, a red screen — the Stories page keeps those too.

Chapters 1–9 are the E2 boot-ok path of 2026-08-15. Chapters 10–12 are later COM2: the xHCI walk, the PERC spare, and RayNu-F on the Ubuntu disk. More field notes live on Stories.