Kerf: Multikernel Management System

Overview

kerf is a comprehensive multikernel management system designed to orchestrate and manage multiple kernel instances on a single host. Starting with advanced device tree compilation and validation, kerf provides the foundation for complete multikernel lifecycle management.

Unlike standard tools that only perform basic format conversion, kerf understands multikernel semantics and always validates resource allocations and detects conflicts. The system is architected to evolve into a complete multikernel runtime environment.

Features

kerf is a comprehensive multikernel management platform with the following capabilities:

• Resource Pool Initialization: Initialize hardware resource pools available for multikernel allocation
• Resource Conflict Detection: Detect and prevent allocation conflicts for CPUs, memory regions, and devices
• Resource Validation: Ensure allocations don't exceed available resources and references are valid
• Atomicity: Validate all allocations together before deployment
• Kernel Loading & Execution: Load and execute multiple kernel instances with proper isolation
• Instance Lifecycle: Create, delete, and manage kernel instances
• Dynamic Resource Management: Allocation and deallocation of system resources
• Monitoring & Debugging: Real-time monitoring of kernel instances and system health
• Security & Isolation: Advanced security policies and isolation mechanisms
• Orchestration: High-level orchestration of complex multikernel workloads

Architecture

Design Philosophy

The kerf system is built on foundational principles that support both current resource pool management and future multikernel runtime features:

1. Single Source of Truth: Baseline DTS describes hardware resources available for allocation
2. Mandatory Validation: Every operation validates the configuration - validation is not optional
3. Fail-Fast: Catch resource conflicts immediately, never produce invalid output
4. Overlay-based Management: Dynamic instance changes are managed via device tree overlays
5. Extensible Architecture: Designed to support future kernel loading, execution, and management capabilities
6. Developer-Friendly: Clear error messages with suggestions for fixing problems
7. Runtime-Ready: Current design anticipates future kernel execution and lifecycle management needs

Compilation Model

Resource pool initialization:

Input: Baseline DTS (resources only)
         │
         ▼
    ┌─────────┐
    │ kerf    │ ← Initializes resource pool
    │  init   │   and validates
    └─────────┘
         │
         ▼
    Baseline DTB
    (resources only)
    → /sys/fs/multikernel/device_tree

Overlay-based dynamic changes:

Current State              Modified State
(Baseline + Overlays)      (After change)
         │                       │
         ├───────────────────────┤
         │                       │
         ▼                       ▼
    ┌─────────┐             ┌─────────┐
    │ Compute │             │ Compute │
    │   Delta │             │  Delta  │
    └─────────┘             └─────────┘
         │                       │
         └───────────┬───────────┘
                     │
                     ▼
              ┌─────────────┐
              │ kerf        │ ← Validates full state
              │ (create/    │   before generating overlay
              │  update/    │
              │  delete)    │
              └─────────────┘
                     │
                     ▼
                 DTBO Overlay
                     │
                     ▼
    → /sys/fs/multikernel/overlays/new
                     │
                     ▼
              Applied Overlay
    → /sys/fs/multikernel/overlays/tx_XXX/

Complete system state:

Baseline DTB (static)
         │
         ├─── Overlay tx_101 (instance: web-server)
         ├─── Overlay tx_102 (instance: database)
         └─── Overlay tx_103 (update: web-server resources)
                    │
                    ▼
         Effective Device Tree
    (Baseline + All Applied Overlays)
                    │
                    ▼
         Kernel Instance Views
    /sys/fs/multikernel/instances/*

Key Points:

• Baseline contains only resources: Hardware resources available for allocation, loaded once via kerf init
• Instances created via overlays: Dynamic instance lifecycle managed through device tree overlays (DTBO)
• Overlay generation: Computes delta between current and modified state, generates minimal DTBO
• Transactional overlays: Each overlay is a transaction with rollback support via rmdir
• Validation is mandatory: Always validates full state (baseline + all overlays) before applying
• Single source of truth: Baseline DTB is the authoritative resource configuration, overlays add instances dynamically

Current Capabilities

Resource Pool Management & Validation

• Resource Pool Initialization: Initialize hardware resource pools for multikernel allocation
• Advanced Validation: Comprehensive resource conflict detection and validation
• Baseline Management: Initialize and manage baseline device tree containing hardware resources
• Format Support: DTS to DTB compilation for baseline configuration
• Error Reporting: Detailed error messages with actionable suggestions
• Resource Analysis: Complete resource utilization reporting
• CPU & NUMA Topology: Full support for CPU topology and NUMA-aware resource allocation

Command Line Interface

# Initialize resource pool with CPUs and pool memory
# A plain size lands on the NUMA node of the requested CPUs
kerf init --cpus=4-7 --memory=2GB

# Initialize with CPUs, per-node memory and devices
kerf init --cpus=4-31 --memory=8GB@0,8GB@1 --devices=enp9s0_dev,nvme0

# Re-run to reshape the live pool; "none" asks for none of a resource
kerf init --cpus=4-15 --memory=4GB
kerf init --cpus=4-15 --memory=none

# Hand everything back to the host
kerf init --cpus=none --memory=none

# Create kernel instance with resource allocation
kerf create web-server --cpus=4-7 --memory=2GB
kerf create database --cpu-count=8 --memory=16GB

# Load kernel image with initrd and boot parameters
kerf load --kernel=/boot/vmlinuz --initrd=/boot/initrd.img \
          --cmdline="root=/dev/sda1 ro" --id=1

# Boot a kernel instance
kerf exec web-server

# Show kernel instance information
kerf show
kerf show web-server

# Dump the device tree the kernel holds: DTB to replay, --dts to read
kerf dump -o host.dtb
kerf dump web-server -o web.dtb
kerf dump web-server --dts

# Shutdown a running kernel instance
kerf kill web-server

# Unload kernel image from an instance
kerf unload web-server

# Delete a kernel instance
kerf delete web-server

# Use --help for detailed options and usage
kerf --help
kerf <command> --help

Technical Foundation

The current resource pool management provides essential building blocks for future multikernel capabilities:

• Resource Pool Initialization: Initializes hardware resource pools for safe multikernel allocation
• Resource Validation: Ensures safe resource allocation before kernel execution
• Instance Isolation: Provides the foundation for secure kernel isolation
• Configuration Management: Enables consistent and validated system configurations
• Error Handling: Establishes patterns for robust error reporting and recovery
• Extensible Architecture: Designed to support future kernel management APIs

These foundational capabilities are essential for safe and reliable multikernel execution, making kerf the ideal platform for building comprehensive multikernel management systems.

Global Device Tree Format

Structure Overview

The baseline device tree contains only the Resources section, which describes all physical hardware available for allocation. Instances and device references are added dynamically via overlays when using kerf create.

1. Resources (/resources): Complete description of all physical resources (baseline only)
2. Instances (/instances): Resource assignments for each spawn kernel (added via overlays)
3. Device References: Linkage between instances and hardware devices (added via overlays)

Baseline Example

The baseline contains hardware resources used for allocation. Resources are typically passed via command line arguments during the kerf init command. Instances are created dynamically via overlays using kerf create.

Mapping to Kernel Filesystem Interface

Device Tree Structure → Kernel Filesystem Interface:

DTS: /resources                          →  /sys/kernel/multikernel/device_tree (writable, single source of truth)
DTS: /instances/web-server               →  /sys/kernel/multikernelinstances/web-server/ (read-only)
DTS: /instances/database                 →  /sys/kernel/multikernel/instances/database/ (read-only)
DTS: /instances/compute                  →  /sys/kernel/multikernel/instances/compute/ (read-only)

Name-based addressing:

• Instance node name in DTS (web-server) = directory name in kernel filesystem (instances/web-server/)
• Kernel assigns numeric IDs, but users reference by name
• No manual ID coordination needed
• Instance directories are auto-generated by the kernel from the global device tree

Validation Rules

Validation is Mandatory

All kerf operations perform validation automatically:

• Compiling DTS to DTB → validates
• Converting formats → validates
• Generating reports → validates first

Validation cannot be disabled or skipped.

CPU Allocation Validation

Rules:

1. CPUs must be defined in the baseline resource pool
2. No CPU can be allocated to multiple instances
3. CPU lists should be explicitly enumerated

Memory Allocation Validation

Rules:

1. Memory regions must be within the baseline memory pool
2. Memory regions cannot overlap between instances
3. Sum of all allocations must not exceed baseline memory pool size
4. Memory base addresses must be page-aligned (4KB = 0x1000)

Device Allocation Validation

Rules:

1. Referenced devices must be defined in the baseline
2. Devices can only be allocated to one instance (exclusive access)
3. Device references must be valid (no dangling phandles)
4. SR-IOV VF numbers must be within device limits
5. Namespace IDs must be within device limits

Global Resource Validation

Rules:

1. Instance names must be unique
2. All phandle references must resolve
3. Baseline resource configuration must be complete and consistent

Integration with Kernel

Kernel Interface

The kernel exposes a filesystem interface (mounted at /sys/fs/multikernel/) that manages baseline resources and overlay-based instance changes:

Kernel Interface Structure:

/sys/fs/multikernel/
├── device_tree              # Baseline DTB (resources only, writable via kerf init)
├── overlays/                # Overlay subsystem
│   ├── new                 # Write DTBO here to apply overlay
│   ├── tx_101/             # Applied overlay transaction
│   │   ├── id              # Transaction ID: "101"
│   │   ├── status          # "applied" | "failed" | "removed"
│   │   ├── dtbo            # Original overlay blob (binary)
│   │   └── ...
│   └── tx_102/
│       └── ...
└── instances/              # Runtime kernel instances (read-only)
    ├── web-server/
    │   ├── id              # Instance ID
    │   ├── status          # Instance status
    │   └── ...
    └── ...

Key Design Principles:

• Baseline Separation: Baseline (device_tree) contains only resources - no instances
• Overlay-based Changes: All dynamic changes (create, update, delete instances) via overlays
• Rollback Support: Remove overlay transaction directory (rmdir /sys/fs/multikernel/overlays/tx_XXX/) to rollback changes
• Kernel-Generated: Instance directories auto-generated from baseline + applied overlays

Dependencies

Required Dependencies

[tool.poetry.dependencies]
python = "^3.8"
pylibfdt = "^1.7.0"      # Device tree parsing (from dtc project)

Installation

# From PyPI (the distribution is named kerf-multikernel;
# the installed command is still 'kerf')
pip install kerf-multikernel

# Or isolated with pipx, avoiding conflicts with other packages
pipx install kerf-multikernel

# From source (recommended for development)
git clone https://github.com/multikernel/kerf.git
cd kerf
# Installs 'kerf' command to ~/.local/bin/kerf
pip install -e .

# Installs 'kerf' command to the system Python's scripts directory
# (typically /usr/local/bin/kerf, or /usr/bin/kerf if using system Python)
sudo pip install .

Getting Started

# Install in development mode
pip install -e .

# Test the installation
kerf --help
kerf init --help

# Carve a pool out of the host: 7 CPUs (by APIC ID) and 1GB on their NUMA node
sudo kerf init --cpus=128-134 --memory=1GB --report

Reusing a Dumped Baseline

kerf dump writes the device tree the kernel holds, byte for byte, and kerf init --input and kerf create --input accept it back. This is the supported way to capture a configuration and replay it later or on another host; hand-written device tree files are not supported. An instance dump carries its CPUs, memory size, devices and id; options such as --uring and --enable-host-kcore are given again on the command line.

sudo kerf dump -o host.dtb            # baseline
sudo kerf dump web-server -o web.dtb  # a running instance
sudo kerf init --input=host.dtb       # replay the baseline
sudo kerf create --input=web.dtb      # recreate the instance
sudo kerf dump --dts                  # read it; text is not replayable

CPU and NUMA Topology Support

Kerf provides comprehensive support for CPU and NUMA topology management:

Key Features

• CPU Topology: Socket, core, and thread mapping with SMT/hyperthreading support
• NUMA Awareness: NUMA node definition with memory regions and CPU assignments
• Topology Policies: CPU affinity (compact, spread, local) and memory policies (local, interleave, bind)
• Performance Validation: Automatic validation of topology constraints and performance warnings

For detailed information about CPU and NUMA topology support, see CPU_NUMA_TOPOLOGY.md.

References

• Device Tree Specification: https://devicetree-specification.readthedocs.io/
• libfdt Documentation: https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation