Technology

Boot Sequence

Silicon uses the PVH (Para-Virtualized Hardware) boot protocol. The hypervisor loads the binary into memory and jumps directly to a 32-bit protected-mode entry point - no BIOS, no bootloader, no UEFI.

From that entry point, the kernel:

1. Builds page tables - a single PML4 and PDPT, using 1 GB huge pages, identity-mapping the first 512 GB of physical memory in just 512 page table entries
2. Enters 64-bit long mode - enables paging, sets IA32_EFER.LME, jumps to Rust code
3. Enables SSE/AVX - configures CR0 and CR4 for floating-point and SIMD
4. Loads the GDT and IDT - three-entry GDT (null, 64-bit code, data) plus a TSS with IST stacks for double-fault and NMI handling
5. Calibrates the TSC - uses CPUID (preferred) or PIT hardware timing to determine the CPU timestamp counter frequency
6. Reads ACPI tables - MADT for CPU topology, FADT for power management, MCFG for PCIe configuration
7. Initializes the physical memory manager - a bitmap allocator walks the PVH memory map and marks available pages
8. Starts the heap allocator - 4 MB initial allocation, grows dynamically on demand
9. Configures the interrupt controllers - remaps the legacy 8259A PIC, enables the Local APIC, configures the I/O APIC
10. Starts the LAPIC timer - TSC deadline mode for sub-microsecond precision, periodic fallback for older CPUs
11. Initializes the scheduler - creates the boot task (TID 0) and the heartbeat task
12. Boots additional CPU cores - INIT-SIPI-SIPI sequence per core, each AP transitions 16-bit real mode to 64-bit long mode independently
13. Mounts the filesystem - discovers virtio-blk device via PCI, mounts or auto-formats SiliconFS
14. Starts the application - hands control to Traverse

There is no kernel to decompress, no initramfs to unpack, no systemd to run, no services to start. The path from power-on to main() is a straight line through hardware initialization.

Memory Mapping

Silicon uses 1 GB huge pages to identity-map the first 512 GB of physical address space. The entire mapping requires only two page table levels (PML4 + PDPT) and 512 entries. Physical addresses equal virtual addresses. There is no virtual memory abstraction, no ASLR, no page swapping. The database operates directly on physical memory.

Multi-Core Architecture

Silicon supports up to 64 CPU cores. The boot processor initializes the kernel, then boots additional application processors using the Intel INIT-SIPI-SIPI sequence.

Each core receives its own:

• Kernel stack - 64 KB with a hardware guard page (a page fault fires immediately on overflow)
• Double-fault IST stack - 16 KB dedicated stack for handling double faults
• NMI IST stack - 8 KB dedicated stack for non-maskable interrupts
• GDT and TSS - per-core descriptor tables
• CoreLocal state - per-core run queue, current task, LAPIC ID, accessed via the GS segment base register

Preemptive Scheduler with Work-Stealing

The scheduler is preemptive and SMP-aware. Each core maintains its own run queue. When a core has no ready tasks, it steals work from other cores using a three-phase protocol: peek at the remote queue, validate affinity under the global task lock, then re-acquire and steal if available.

The LAPIC timer fires periodically on each core, driving preemption. A task that never yields is still interrupted and rescheduled. Cross-core wakeups use inter-processor interrupts - when a task is woken on a remote core, a reschedule IPI ensures immediate dispatch without polling.

Context switches save and restore callee-saved registers, the stack pointer, the FS base, and the full FPU/SSE/AVX state via XSAVE or FXSAVE. The outgoing task is not pushed back to the run queue until the incoming task is fully running, preventing a race where work-stealing grabs a task whose context is still being saved.

Memory Management

Physical Memory Allocator

Silicon manages physical memory directly through a bitmap allocator. Each bit represents one 4 KB page. The bitmap supports up to 512 GB of physical RAM. To reduce lock contention, each core maintains a page cache of 128 pre-allocated addresses, refilled in batches of 64 from the global allocator.

Dual-Heap Architecture

Silicon runs two independent heap allocators behind a single interface:

• Main heap - serves all server allocations: the network stack, the async runtime, HTTP framework, filesystem caches, and scheduler state. Starts at 4 MB and grows dynamically.
• Database heap - dedicated to database data (nodes, edges, indexes, property maps). Routing uses a thread-local flag during database loading.

Deallocation routing uses a pair of physical-page bitmaps - one bit per 4 KB page - for O(1) lookup. This separation means unloading a database returns its physical memory without disturbing the server's allocations. In a traditional allocator, database and server allocations would be interleaved, making it impossible to return memory without stopping the server.

There is no swap file, no overcommit, no copy-on-write fork. Memory allocation is deterministic: if the allocator returns a pointer, the physical pages are already mapped and zeroed.

SiliconFS

Silicon includes its own filesystem designed specifically for database workloads on virtual block devices. Written entirely in Rust (no_std), approximately 4,000 lines, prioritizing crash safety over generality.

On-Disk Layout

Crash Safety

Every write follows a strict protocol:

1. New data is written to fresh blocks (copy-on-write - the original is never modified in place)
2. A flush barrier ensures the data is durable on the virtual disk
3. The metadata update is written to the write-ahead journal with a CRC32 integrity check
4. A second flush barrier ensures the journal entry is durable
5. The metadata is checkpointed to its final location on disk

Either the write completed fully, or it didn't happen at all.

Checksums

Every data block on disk has a CRC32 checksum stored in a dedicated checksum table. Every read verifies the checksum before returning data. If a block is corrupted - by a disk error, a firmware bug, or a bit flip - the filesystem detects it instead of silently delivering corrupt data.

The superblock is stored in duplicate (primary at block 1, backup at block 2) so that a single-block corruption cannot prevent mounting. Inodes, journal headers, and journal commits are all individually checksummed.

Copy-on-Write

File writes never overwrite existing data blocks. New blocks are allocated, written through, and tracked in a per-file CoW table. On fsync or close, the inode's extent map is updated atomically through the journal. Each inode holds up to 6 inline extents, with automatic defragmentation when fragmentation would exceed this limit.

Automatic Recovery

On mount, SiliconFS replays the journal and runs a 7-phase consistency check: superblock integrity, inode CRC validation, block bitmap cross-referencing, inode bitmap verification, free count validation, directory tree walk, and data block checksum verification. Detected inconsistencies are automatically repaired.

Performance

Network Stack

Pure Rust TCP/IP

Silicon implements its own TCP/IP stack using smoltcp, a pure-Rust no_std networking library. The stack runs in the same address space as the database - there is no kernel network layer and no system call boundary. Supported protocols: IPv4 with full TCP and UDP, DHCPv4 with automatic lease renewal, and DNS resolution.

Virtio-net Driver

Silicon communicates with the hypervisor through a custom multi-queue virtio-net driver:

• Up to 16 transmit/receive queue pairs - negotiated via VIRTIO_NET_F_MQ
• Per-core transmit queues - each CPU core sends on its own queue, eliminating lock contention
• Pre-allocated receive buffers - 1,536-byte buffers recycled without copying
• Loopback - packets to the local IP bypass the virtio device entirely

Adding CPU cores to the VM scales network throughput linearly.

TLS

A full TLS stack built on rustls with the ring cryptographic library. TLS 1.2 and 1.3 are both supported. Entropy comes from a virtio-rng device with RDRAND as a fallback.

Storage I/O

Virtio-blk Driver

Silicon accesses virtual block devices through a custom multi-queue virtio-blk driver:

• Up to 64 block I/O queues - negotiated via VIRTIO_BLK_F_MQ
• Per-core queue selection - each CPU core uses its own queue
• 64 descriptors per queue - allowing multiple outstanding I/O requests
• Flush support - VIRTIO_BLK_F_FLUSH for write-barrier enforcement used by SiliconFS journaling

Hypervisor Compatibility

The same binary adapts to both Cloud Hypervisor and Firecracker automatically:

TSC Calibration

Accurate timing is critical for query timeouts, keepalives, and watchdog timers. Silicon calibrates the TSC at boot using five methods in priority order:

After calibration, all timing is derived from rdtsc - a single instruction with no system call, no MMIO, no privilege transition.

ACPI and Power Management

Silicon implements ACPI HW-Reduced power management. On Cloud Hypervisor, a power button press triggers a GED interrupt. The handler broadcasts SIGTERM to all tasks, the database flushes and unmounts, APs halt, and the BSP writes the ACPI S5 sleep command.

On Firecracker (no GED or SLEEP_CONTROL_REG), Silicon falls back to the i8042 keyboard controller reset, which Firecracker intercepts as VM termination. Both paths are transparent - the same binary works on both hypervisors.

Watchdog

A software watchdog timer driven by the LAPIC timer interrupt. When enabled, it is petted every time the scheduler selects a non-idle task. If no task runs for the configured timeout, the watchdog prints per-CPU diagnostics and triggers shutdown. Zero overhead when disabled.