Metadata-Version: 2.1
Name: kerf-multikernel
Version: 0.2.0
Summary: Multikernel Management CLI tool
Author: Cong Wang
Requires-Python: >=3.9,<4.0
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Requires-Dist: click (>=8.0.0,<9.0.0)
Requires-Dist: pylibfdt (>=1.7.0,<2.0.0)
Requires-Dist: pyudev (>=0.24.0,<0.25.0)
Requires-Dist: pyyaml (>=6.0,<7.0)
Requires-Dist: rdtsc (>=0.2.1,<0.3.0)
Description-Content-Type: text/markdown

![Kerf Logo](logo.png)

# 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
```bash
# 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

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

### Installation

```bash
# 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

```bash
# 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.

```bash
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](docs/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


