# SLAT Masterclass: Die Mechanik der Speicher-Virtualisierung

TL;DR / Management Summary Jede VM hat ihre eigene Vorstellung vom Arbeitsspeicher. Doch am Ende muss jede Gast-Adresse auf einen echten physischen RAM-Riegel des Hosts abgebildet werden. Früher musste der Kernel dies mühsam in Software tun (Shadow Page Tables). Heute übernimmt die CPU diese Arbeit mit SLAT (Second Level Address Translation) – bei Intel EPT (Extended Page Tables) und bei AMD NPT (Nested Page Tables) genannt. Ein Senior Admin muss verstehen, wie diese Hardware-Beschleunigung funktioniert, um Speicher-Engpässe in großen VM-Clustern zu beheben.

# 1. Einführung & Architektur

Die zwei Ebenen der Wahrheit.

Normales Linux nutzt eine Seitentabelle (Page Table), um Virtual Memory auf Physical Memory zu mappen. Eine VM fügt eine weitere Ebene hinzu.

# Der Adress-Pfad (Mermaid)

graph LR
    A[Guest App: Virtual Addr] -->|Table 1: Gast OS| B[Guest Physical Addr]
    B -->|Table 2: SLAT / EPT| C[Host Physical Addr: RAM]
    subgraph "Hardware Acceleration (SLAT)"
        B
        C
    end
    D[CPU TLB Cache] --- B
    D --- C

• GVA (Guest Virtual Address): Adresse innerhalb des Programms in der VM.
• GPA (Guest Physical Address): Das, was die VM für “echten RAM” hält.
• HPA (Host Physical Address): Die echte Zelle auf dem RAM-Riegel.

# 2. EPT vs. Shadow Page Tables

Warum Hardware gewinnt.

• Shadow Page Tables (Legacy): Der Hypervisor (KVM) muss jede Änderung im Gast-RAM abfangen und eine “Schatten-Tabelle” manuell synchronisieren. Dies führt zu massiven VM-Exits (Artikel 403) und kostet bis zu 30% Performance.
• EPT / NPT (Hardware): Die CPU-MMU (Memory Management Unit) kennt beide Tabellen und führt den “Page Walk” über beide Schichten in Silizium aus.

# 3. Performance-Tuning: Huge Pages & EPT

Den Index verkleinern.

Das größte Problem bei SLAT ist der “Page Walk”. Der Prozessor muss viele Tabellen-Einträge lesen, um die finale Adresse zu finden.

• Lösung: Nutzen Sie Huge Pages (Artikel 388). Durch 2MB Seiten wird die Anzahl der Einträge in beiden Tabellen drastisch reduziert. Der SLAT-Mechanismus muss weniger “laufen”.

# 4. Day-2 Operations: Support-Check

Kann meine CPU das?

In modernen RZs ist SLAT Standard, aber bei Cloud-Instanzen oder sehr alten Servern lohnt ein Check.

# Prüfung via CLI

# Intel (Extended Page Tables)
grep ept /proc/cpuinfo

# AMD (Nested Page Tables)
grep npt /proc/cpuinfo

# 5. Troubleshooting & “War Stories”

Wenn der Speicher-Bus glüht.

# Story 1: “Der TLB-Trash-Effekt”

Symptom: Mehrere VMs auf einem Host werden gleichzeitig extrem langsam, obwohl die CPU-Last im Gast niedrig ist. Der Host zeigt hohe Last im Kernel-Bereich. Ursache: Zu viele kleine VMs nutzen extrem viel RAM. Der TLB (Translation Lookaside Buffer) der CPU reicht nicht aus, um die EPT-Einträge für alle VMs zu cachen. Die CPU verbringt ihre Zeit mit “Page Table Walking”. Lösung: Reduzieren Sie die VM-Dichte oder nutzen Sie Huge Pages, um die TLB-Effizienz zu steigern.

# Story 2: “Das Nested-Virtualisierungs-Loch”

Symptom: Eine VM in einer VM (L2 Guest) ist unbrauchbar langsam (10% der Speed). Ursache: Die Hardware-Beschleunigung (EPT) wird oft nicht an die L2-VM durchgereicht. Der L1-Hypervisor muss wieder auf die langsamen Shadow Page Tables ausweichen. Lösung: Aktivieren Sie EPT-Passthrough (nested=1). Aber Vorsicht: Jede zusätzliche Ebene erhöht die Latenz beim Adress-Lookup exponentiell.

# 6. Fazit & Empfehlung

• Pflicht: Kaufen Sie niemals Server-Hardware ohne EPT/NPT Support.
• Best Practice: Kombinieren Sie EPT mit Transparent Huge Pages (Artikel 388) für allgemeine Workloads und Explicit Huge Pages für Datenbanken.
• Wissen: SLAT ist der Grund, warum wir heute Datenbanken in VMs betreiben können, ohne Angst vor Speicher-Latenzen zu haben.

# Anhang: Cheatsheet