Xen & Jailhouse
TEKNİK REHBER GÖMÜLÜ LİNUX HYPERVİSOR 2026

Hypervisor Temelleri
ARM EL2 & İzolasyon

Mixed-criticality gereksinimleri, ARM Stage-2 MMU, EL2 exception flow, SMMU/IOMMU, interrupt virtualization ve embedded hypervisor seçim rehberi.

00 Neden hypervisor — mixed-criticality

Modern gömülü sistemlerde tek bir SoC üzerinde farklı güvenlik ve kritiklik seviyelerine sahip yazılımların çalıştırılması zorunlu hale gelmiştir. Bu durum mixed-criticality problem olarak tanımlanır ve çözümü hypervisor teknolojisindedir.

Endüstriyel motivasyon

Otomotiv ECU'larında IVI (In-Vehicle Infotainment), ADAS algoritmları ve powertrain kontrolü artık aynı SoC üzerinde çalışmaktadır. Bu bileşenlerin farklı güvenlik seviyeleri vardır: IVI için güvenilirlik önemli ancak güvenlik kritik değilken, powertrain kontrolü ASIL-D seviyesindedir. Hypervisor bu bileşenler arasında sert bir duvar çizer.

BileşenGüvenlik SeviyesiOSBölme
IVI / MultimedyaQM (Quality Managed)Android / LinuxdomU / non-root cell
Telematics / BağlantıASIL-BLinux + TEEdomU / non-root cell
ADASASIL-B/CLinux (güvenli)ayrı domU
Powertrain / GüvenlikASIL-DRTOS (FreeRTOS/AUTOSAR)non-root cell

ISO 26262 ve IEC 61508 gereksinimleri

ISO 26262 (otomotiv) ve IEC 61508 (fonksiyonel güvenlik) standartları, farklı ASIL/SIL seviyelerindeki bileşenler arasında freedom from interference (girişim özgürlüğü) gerektirir. Hypervisor bu izolasyonu yazılım ve donanım katmanlarında sağlar.

Temporal IsolationBir bölmenin CPU zamanını aşırı tüketmesi diğer bölmeleri etkilememelidir — watchdog, CPU quota
Spatial IsolationBellek erişimi: bir bölme diğerinin fiziksel belleğine erişemez — Stage-2 MMU, SMMU
Communication ChannelsBölmeler arası iletişim kontrollü ve tanımlı olmalıdır — shared memory, virtio, IVSHMEM
Freedom from InterferenceDüşük kritiklik bölmesindeki hata yüksek kritiklik bölmesini etkilememeli

Hypervisor olmadan ne olur?

Hypervisor olmadan tüm bileşenler aynı Linux çekirdeği üzerinde process olarak çalışır. Bu durumda kernel exploit, bir sürecin başka süreçlerin belleğine erişmesi veya aşırı kaynak tüketimi tüm sistemi tehdit eder. Güvenlik sertifikasyonu ise neredeyse imkânsız hale gelir.

Bu bölümde

  • Mixed-criticality: tek SoC, farklı ASIL seviyeleri — izolasyon zorunlu
  • ISO 26262 / IEC 61508: freedom from interference gereksinimi
  • Hypervisor: temporal + spatial izolasyon sağlayan katman
  • ASIL-D bileşeni ASIL-QM bileşenden tamamen yalıtılmalı

01 Type-1 vs Type-2 hypervisor

Hypervisor'lar donanım ile olan ilişkilerine göre iki temel kategoriye ayrılır. Gömülü sistemlerde deterministik davranış ve düşük overhead gerektiren uygulamalar için Type-1 tercih edilir.

Temel fark

ÖzellikType-1 (Bare-metal)Type-2 (Hosted)
Çalışma katmanıDoğrudan donanım üzerindeHost OS üzerinde
PerformansYüksek — donanım erişimi doğrudanDüşük — host OS overhead
Güvenlik yüzeyiKüçük — minimal hypervisor koduBüyük — host OS dahil
DeterminizmYüksek — real-time mümkünDüşük — host OS jitter
ÖrneklerXen, Jailhouse, ACRN, seL4/CAmkESVirtualBox, VMware Workstation, QEMU
Gömülü kullanımTercih edilenGeliştirme/test ortamı

Jailhouse: Linux üzerinde Type-1

Jailhouse ilginç bir hibrit yaklaşım sunar: başlangıçta Linux üzerinde çalışır ancak jailhouse enable komutuyla Linux kendisini bir cell içine alır ve Jailhouse doğrudan donanımı kontrol eden gerçek bir Type-1 hypervisor'a dönüşür. Bu yüzden Jailhouse hem "Linux üzerinde çalışır" hem de "Type-1'dir" ifadeleri doğrudur.

TCB (Trusted Computing Base) perspektifi

Güvenlik sertifikasyonunda TCB, güvenilir olması gereken kod tabanının büyüklüğünü tanımlar. Hypervisor türüne göre TCB boyutu önemli ölçüde değişir.

HypervisorTCB BüyüklüğüSertifikasyon Uygunluğu
Jailhouse~20.000 satırASIL-D için uygun
Xen (minimal subset)~100.000 satırASIL-B/C için zorlu
KVM + Linux~25.000.000 satırASIL için pratik değil
seL4~10.000 satırFormally verified — ASIL-D
Başlangıç:   [ Linux (bare-metal) ]
                     |
jailhouse enable komutu
                     ↓
Sonra:       [ Jailhouse Hypervisor ]
             [ Root Cell (Linux) ] [ Non-root Cell (RTOS) ]
    

Mikro-kernel yaklaşımı — seL4

seL4 gibi formally verified mikro-kernel tabanlı hypervisor'lar, matematiksel olarak kanıtlanmış izolasyon sağlar. Kod tabanı binlerce satır mertebesinde olup ASIL-D sertifikasyonu için idealdir ancak geliştirme ekosistemi Xen/Jailhouse'a kıyasla daha kısıtlıdır.

Bu bölümde

  • Type-1: donanım üzerinde doğrudan — düşük overhead, yüksek güvenlik
  • Type-2: host OS üzerinde — geliştirme kolaylığı, yüksek overhead
  • Jailhouse: Linux enable → Type-1'e dönüşen hibrit model
  • seL4: formally verified — ASIL-D için uygun ama ekosistem kısıtlı

02 ARM virtualization extensions

ARMv7-A ve ARMv8-A/v9-A mimarilerinde donanım sanallaştırma desteği EL2 (Exception Level 2) ile sağlanır. Bu seviye, hypervisor kodunun çalıştığı ayrıcalıklı kattır.

ARM exception level hiyerarşisi

EL3  — Secure Monitor (TrustZone, ATF BL31)        ← en ayrıcalıklı
EL2  — Hypervisor (Xen, Jailhouse, KVM/ARM)
EL1  — OS Kernel (Linux, RTOS)
EL0  — Userspace (uygulamalar)                      ← en az ayrıcalıklı
    

Stage-2 MMU (İki aşamalı bellek çevirisi)

ARM sanallaştırmasının temel taşı Stage-2 MMU'dur. Normal bellek çevirisi (Stage-1) guest OS tarafından yönetilirken, Stage-2 hypervisor tarafından kontrol edilir ve guest'in fiziksel adres görünümünü gerçek fiziksel adreslerle eşler.

AşamaGirişÇıkışKontrol Eden
Stage-1VA (Virtual Address)IPA (Intermediate Physical Address)Guest OS (EL1)
Stage-2IPA (Intermediate Physical)PA (Real Physical Address)Hypervisor (EL2)

HCR_EL2 — Hypervisor Configuration Register

HCR_EL2 kaydı hypervisor'ın guest kontrolünü belirler. Bu kayıttaki bitler hangi işlemlerin EL1'de trap oluşturacağını ve EL2'ye geçiş yapacağını tanımlar.

ARM assembly — HCR_EL2 temel bit'leri
; HCR_EL2 önemli bit'ler
; VM  [0]  : Stage-2 MMU etkinleştir (1 = enabled)
; SWIO[1]  : Set/Way cache operations trap
; PTW [2]  : Protected Table Walk
; FMO[8]   : FIQ routing to EL2
; IMO[9]   : IRQ routing to EL2
; AMO[10]  : Async abort routing to EL2
; RW [31]  : Register Width — 1=aarch64 guest
; TGE[27]  : Trap General Exceptions to EL2

; Hypervisor başlangıcında HCR_EL2 ayarı
mov  x0, #(1 << 31)    ; RW — AArch64 guest
orr  x0, x0, #(1 << 1) ; SWIO
orr  x0, x0, #(1 << 0) ; VM — Stage-2 aktif
msr  HCR_EL2, x0
isb

VGIC — Virtualized Generic Interrupt Controller

ARM GICv3/GICv4, donanım düzeyinde interrupt sanallaştırmayı destekler. VGIC, her guest'e kendi sanal interrupt controller görünümünü sunar. LPI (Locality-specific Peripheral Interrupts) ile fiziksel interruptlar doğrudan guest'e iletilebilir — bu direct injection olarak bilinir ve VM-exit gerektirmez.

VGIC DistributorHer guest kendi GICD register'larını görür; hypervisor bu register erişimlerini trap eder
VGIC RedistributorPer-vCPU redistributor — GICv3'te her CPU'ya ait interrupt state
LPI Direct InjectionGICv4: MSI interrupt'ları hypervisor müdahalesi olmadan guest'e iletilir
Virtual CPU InterfaceICC_IAR1_EL1 gibi system register'lar guest tarafından doğrudan erişilebilir

Bu bölümde

  • EL2: ARM'da hypervisor seviyesi — EL3 (secure monitor) altında, EL1 (kernel) üstünde
  • Stage-2 MMU: VA→IPA (guest) + IPA→PA (hypervisor) — çift katmanlı çeviri
  • HCR_EL2: hypervisor konfigürasyon kaydı — VM bit, routing, RW flag
  • VGIC: donanım destekli interrupt sanallaştırma — GICv3/v4

03 Paravirtualization vs full vs HW-assisted

Guest OS ile hypervisor arasındaki etkileşim modeli performansı ve uyumluluk karmaşıklığını doğrudan belirler. ARM donanım sanallaştırması ile bu farklar önemli ölçüde azalmıştır.

Üç yaklaşımın karşılaştırması

YaklaşımGuest OS DeğişimiPerformansUyumlulukÖrnek
Full VirtualizationYok — değiştirilmemiş guestOrta — her privileged instr. trapYüksek — herhangi bir OSQEMU (binary translation)
Paravirtualization (PV)Yüksek — guest hypercall kullanırYüksek — trap sayısı azDüşük — kernel değiştirilmeliXen PV, virtio
HW-AssistedMinimal — driver-levelEn yüksek — donanım trapYüksek — değiştirilmemiş guestXen HVM, KVM, Jailhouse

ARM PV (Paravirtualized) sürücüler

Xen ARM'da tam paravirtualization yerine PVHVM yaklaşımı kullanılır: guest değiştirilmemiş Linux çekirdeğidir ancak PV sürücüler (xen-blkfront, xen-netfront) I/O için hypercall arayüzünü kullanır. Bu emülasyona kıyasla çok daha yüksek I/O throughput sağlar.

bash — Xen PV sürücü durumu
# Guest içinde PV sürücü yüklü mü?
lsmod | grep xen
# xen_netfront    24576  0
# xen_blkfront    40960  2
# xenbus_probe_frontend  16384  2 xen_netfront,xen_blkfront

# Xen hypervisor üzerinde olduğumuzu doğrula
cat /proc/xen/capabilities
# control_d  (dom0 ise)

xl dmesg | grep -i "virt"
# (XEN) ARM64 Virtualization Extensions enabled

Virtio — standart PV I/O arayüzü

Virtio, Xen ve KVM gibi farklı hypervisor'larda kullanılabilen standart bir paravirtualized I/O arayüzüdür. virtio-net, virtio-blk, virtio-serial gibi sürücüler Linux kernel'ında hazır gelir.

bash — virtio sürücü kontrolü
# Virtio sürücülerini listele
lspci | grep -i virtio
# 00:01.0 Ethernet controller: Red Hat, Inc. Virtio network device

# Virtio disk performans testi
dd if=/dev/vda of=/dev/null bs=1M count=512 iflag=direct
# 512+0 records in ... 1.23 GB/s

# Virtio ağ arayüzü
ip link show
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ... virtio_net

Shared memory IPC — PV iletişim kanalları

Paravirtualized sistemlerde bölmeler arası iletişim için doğrudan paylaşımlı bellek en verimli yöntemdir. Xen'de grant table, Jailhouse'da IVSHMEM bu mekanizmayı sağlar.

bash — Xen grant table bilgisi (dom0)
# Dom0'da grant table bilgisi
cat /proc/xen/grant_tables
# nr_pages: 16
# max_nr_pages: 4096

# Aktif grant referansları
ls /sys/kernel/debug/xen/
# grant-table  grant-tables  runstate  xenbus

# DomU'nun grant ettiği sayfalar
cat /sys/kernel/debug/xen/grant-table
# domid=1: 128 active grants

VM-exit overhead analizi

Her VM-exit (trap), guest CPU'nun kaydedilmesi ve hypervisor işlemciye geçmesi anlamına gelir. Bu geçiş yüzlerce nanosaniyeden birkaç mikroşaniyeye kadar sürebilir ve sistem performansını direkt etkiler.

ARM EL1→EL2 geçişi~200-500ns — register save/restore dahil
MMIO emülasyonuHer MMIO erişimi = VM-exit → ~1-5µs overhead
Interrupt injection~500ns-1µs — VGIC üzerinden sanal IRQ
Jailhouse overheadMinimal — static partitioning sayesinde çok az VM-exit

Bu bölümde

  • Full virt: değiştirilmemiş guest, orta performans — tüm trap'ler emüle edilir
  • Paravirt: guest hypercall kullanır, yüksek I/O performansı — kernel değişikliği gerekli
  • HW-assisted: ARM EL2 ile donanım trap — en iyi performans ve uyumluluk
  • Virtio: cross-hypervisor standart PV I/O — net/blk/serial
  • Grant table: Xen zero-copy IPC — domU → dom0 bellek sayfası paylaşımı
  • VM-exit overhead: 200ns-5µs — Jailhouse statik yapısıyla minimize eder

04 Embedded hypervisor karşılaştırması

Gömülü sistemler için birden fazla hypervisor seçeneği mevcuttur. Her birinin güçlü ve zayıf yönleri farklı kullanım senaryolarına uyum sağlar.

Kapsamlı karşılaştırma tablosu

HypervisorMimariLisansGüvenlikEkosistemGömülü Uygunluk
XenType-1, mikro-kernel benzeriGPL-2.0FLASK/XSM, Xen Security ModulesGeniş — Yocto, OpenEmbeddedYüksek — ARM, x86
JailhouseType-1, static partitioningGPL-2.0Minimal saldırı yüzeyiOrta — Yocto destekliÇok yüksek — determinizm
KVM/ARMType-1 (Linux modülü)GPL-2.0Linux güvenlik modülleriÇok geniş — QEMU, libvirtOrta — overhead yüksek
ACRNType-1, Intel odaklıBSD-3-ClauseACRN-DM güvenlik modeliOrta — Intel ekosistemiYüksek — IVI odaklı
seL4Mikro-kernelGPL-2.0 / ticariFormal verificationKısıtlıASIL-D için ideal

Jailhouse'un avantajları — gömülü perspektif

Jailhouse, static partitioning yaklaşımıyla öne çıkar. Dinamik VM oluşturma/silme yoktur; her şey önceden yapılandırılmıştır. Bu yaklaşım:

  • Çok küçük hypervisor kod tabanı (~20.000 satır) — daha kolay sertifikasyon
  • Deterministik davranış — real-time bölmeler için kritik
  • Linux sürücü ekosistemini root cell üzerinden kullanma imkânı
  • Bare-metal inmate ile custom firmware yazılabilmesi

Xen'in avantajları

Xen, olgunlaşmış bir proje olup sunucu sanallaştırmasında kanıtlanmış güvenlik kaydına sahiptir. Gömülü alanda dom0-less boot ile Linux olmadan çalışabilir, FLASK/XSM ile MAC politikaları uygulanabilir.

ACRN — Otomotiv odaklı hypervisor

Intel'in geliştirdiği ACRN (A Cracking Real-time hypervisor for embedded), otomotiv IVI sistemleri için özel olarak tasarlanmıştır. x86 Intel VT-x üzerinde çalışır, Android guest desteği güçlüdür. ARM desteği kısıtlı olup i.MX8 gibi ARM SoC'larda tercih edilmez.

Gömülü hypervisor seçim kriterleri

bash — Hypervisor seçim yardımcısı
# Platform: ARM mı, x86 mi?
# ARM + gömülü → Xen veya Jailhouse
# x86 + IVI → ACRN veya KVM

# Sertifikasyon gerekli mi?
# ASIL-D → Jailhouse (küçük TCB) veya seL4
# ASIL-B/C → Xen (olgun, FLASK/XSM)

# Dinamik VM yönetimi gerekli mi?
# Evet → Xen (xl toolstack) veya KVM (libvirt)
# Hayır → Jailhouse (static, deterministic)

# Real-time garantisi?
# Sıkı RT → Jailhouse bare-metal cell
# Esnek RT → Xen RTDS scheduler + KVM CPU pinning

# Platform kontrolü
jailhouse hardware check  # Jailhouse uyumluluğu
xl info 2>/dev/null        # Xen çalışıyor mu?
ls /dev/kvm 2>/dev/null    # KVM mevcut mu?

Hypervisor güvenlik sertifika yolları

StandartSektörHypervisor GereksinimiUygun Seçenek
ISO 26262 ASIL-DOtomotivFormal kanıt + küçük TCBJailhouse, seL4
IEC 61508 SIL-3EndüstriyelGüvenlik analizi + testJailhouse, Xen
DO-178C Level AAviyonikMC/DC coverage + formalseL4, PikeOS
CC EAL4+GüvenlikFormal doğrulamaseL4, Xen (CC belgelenmiş)

Bu bölümde

  • Jailhouse: static partitioning, küçük kod tabanı, determinizm — gömülü ideal
  • Xen: olgun, FLASK/XSM güvenlik, dom0-less — ARM gömülü için güçlü
  • KVM: geniş ekosistem ama overhead yüksek — cloud/geliştirme uygun
  • ACRN: Intel IVI odaklı — ARM'da kısıtlı destek
  • seL4: formal verification — ASIL-D, DO-178C Level A için
  • Seçim kriterleri: ARM/x86, sertifikasyon, dinamik VM, RT garantisi

05 Hypervisor attack surface ve güvenlik

Hypervisor güvenliği, tüm üstündeki sistemlerin güvenliğini belirler. Hypervisor compromise = tüm guest'lerin compromise'ı anlamına gelir. Bu yüzden saldırı yüzeyi minimize edilmelidir.

Temel saldırı vektörleri

VM escapeGuest'ten hypervisor'a geçiş — güvenlik açığı sömürülerek Stage-2 MMU bypass
MMIO emülasyon açıklarıEmüle edilen I/O cihazlarında buffer overflow veya integer overflow
Hypercall interfaceXen hypercall'larında validation eksikliği — saldırgan guest olarak exploit
Side-channelSpectre/Meltdown — paylaşılan CPU önbelleği üzerinden bilgi sızıntısı
DMA saldırılarıKötü niyetli donanım sürücüsü — SMMU olmadan fiziksel belleğe DMA erişimi

Savunma stratejileri

bash — Xen güvenlik sertleştirme
# Xen komut satırı güvenlik seçenekleri
# /boot/extlinux.conf veya GRUB'da Xen parametreleri

# SMMU etkinleştir (IOMMU)
xen.gz iommu=on iommu_inclusive_mappings=on

# Spectre/Meltdown azaltmaları
xen.gz spec-ctrl=full bti-thunk=retpoline

# Dom0 yeteneklerini kısıtla
xen.gz dom0_max_vcpus=2 dom0_mem=512M,max:512M

# XSM (Xen Security Modules) etkinleştir
xen.gz flask=enforcing

# Dom0 için driver domain modeli — minimum yetki
# Ayrı driver domain'ler dom0'dan bağımsız sürücü çalıştırır

Jailhouse minimal saldırı yüzeyi

Jailhouse'un en büyük güvenlik avantajı minimal kod tabanıdır. Hypervisor kodu yalnızca ~20.000 satırdır ve dinamik bellek yönetimi veya kompleks hypercall interface içermez. Sertifikasyon için bu kritik bir avantajdır.

Güvenli hypervisor konfigürasyon kontrol listesi

bash — Jailhouse güvenlik kontrol listesi
# 1. SMMU/IOMMU etkin mi?
jailhouse hardware check | grep IOMMU
# [  OK  ] IOMMU available

# 2. Cell'lerin bellek bölgeleri örtüşüyor mu?
# (Jailhouse enable sırasında otomatik kontrol edilir)
jailhouse enable root.cell 2>&1 | grep -i overlap
# (çıktı olmamalı)

# 3. Xen: FLASK enforcing mod
xl getenforce
# Enforcing

# 4. Secure boot zinciri (platform bütünlüğü)
dmesg | grep -i "secure boot\|verified boot"

# 5. Spectre/Meltdown azaltmaları
cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
# Mitigation: CSV2, BHB
cat /sys/devices/system/cpu/vulnerabilities/meltdown
# Mitigation: Stage-2 isolation

TrustZone ile hypervisor entegrasyonu

ARM TrustZone ve EL2 hypervisor birlikte kullanılabilir. TrustZone (EL3/Secure EL1) güvenli dünyayı yönetirken, Xen/Jailhouse (EL2) normal dünya sanallaştırmasını yürütür. Bu katmanlama ASIL-D güvenli depolama ve şifreleme için idealdir.

Normal World (NS=1)          Secure World (NS=0)
EL2: Xen/Jailhouse           EL3: ATF BL31 (Secure Monitor)
EL1: Guest Linux/RTOS        EL1-S: OP-TEE / OPTEE_OS
EL0: Guest Userspace         EL0-S: Trusted Applications
         ↑                            ↑
         └──── SMC (Secure Monitor Call) ────┘
    

Bu bölümde

  • VM escape: en kritik saldırı — Stage-2 MMU bypass
  • SMMU/IOMMU: DMA saldırılarına karşı zorunlu koruma
  • Spectre/Meltdown: Xen spec-ctrl parametreleri + ARM CSV2/BHB
  • Jailhouse: küçük kod tabanı = küçük saldırı yüzeyi
  • TrustZone + EL2: normal dünya hypervisor + güvenli dünya TEE
  • FLASK enforcing + secure boot: katmanlı güvenlik yaklaşımı

06 Memory isolation — SMMU/IOMMU

Stage-2 MMU CPU bellek erişimini izole eder ancak DMA-capable cihazlar bu korumayı atlayabilir. SMMU (System Memory Management Unit) bu boşluğu kapatır.

SMMU mimarisi

ARM SMMU (SMMUv2/SMMUv3), bir DMA master cihazının gerçekleştireceği bellek işlemlerini Stream ID'ye göre filtreleme ve çevirme yeteneği sunar. Bu sayede bir guest'e atanmış bir DMA cihazı yalnızca o guest'in fiziksel bellek bölgesine erişebilir.

DMA Master (NIC, USB, PCIe) → SMMU → Stage-2 benzeri çeviri → Fiziksel Bellek
        Stream ID ↗              ↑
                         Context Descriptor Table
                         (hypervisor tarafından yönetilir)
    
bash — SMMU durum kontrolü (Linux)
# ARM SMMU sürücü yüklü mü?
dmesg | grep -i smmu
# [    1.234567] arm-smmu 51400000.iommu: probing hardware configuration
# [    1.234890] arm-smmu 51400000.iommu: stage 2 translation only

# IOMMU gruplarını listele
ls /sys/kernel/iommu_groups/
# 0  1  2  3  ...

# Belirli bir grubun cihazlarını gör
ls /sys/kernel/iommu_groups/1/devices/
# 0000:00:01.0 -> ../../../devices/pci0000:00/0000:00:01.0

# VFIO ile cihazı guest'e ata (Xen passthrough için)
echo vfio-pci > /sys/bus/pci/devices/0000:00:01.0/driver_override
echo 0000:00:01.0 > /sys/bus/pci/drivers/vfio-pci/bind

Memory color ve cache partitioning

Gelişmiş mixed-criticality sistemlerde DRAM bankı renklendirme (memory coloring) ile önbellek kirliliği azaltılır. L2/L3 önbelleği farklı bölmeler arasında paylaştırılmaz — her bölme kendi önbellek setlerini kullanır.

Bu bölümde

  • SMMU: DMA master'ları için Stage-2 benzeri bellek çevirisi ve izolasyon
  • Stream ID: her DMA cihazına ait bağlam tanımlayıcısı
  • VFIO: Linux'ta güvenli device passthrough için SMMU entegrasyonu
  • Memory coloring: cache kirliliğini önlemek için DRAM bankı renklendirme

07 Interrupt virtualization

Interrupt'ların guest'lere dağıtımı hypervisor'ın en kritik görevlerinden biridir. ARM GICv3/v4 bu işlemi donanım düzeyinde optimize eder.

Interrupt yönlendirme modları

ModAçıklamaGecikmeKullanım
Trap-and-emulateGIC register erişimi EL2'ye trap olur, hypervisor emüle ederYüksek (~1µs)Eski GICv2
Virtual IRQ injectionHypervisor sanal IRQ oluşturur, guest CPU arayüzüne yazarOrta (~500ns)GICv3
LPI direct injectionFiziksel IRQ doğrudan guest'e — hypervisor müdahalesi yokDüşük (~100ns)GICv4, passthrough

Xen'de interrupt yönetimi

xl.cfg — IRQ passthrough (Xen)
# domU'ya fiziksel interrupt atama
irqs = [ 32, 33 ]    # SPI 0 ve 1 (32 = SPI 0)

# IRQ numaraları: /proc/interrupts veya device tree'den
# cat /proc/interrupts | grep uart
#  32:     1234   GICv3  32 Level  uart0

# VGIC v3 kullan (GICv3 donanım gerektirir)
gic_version = "v3"

Timer virtualization

ARM Generic Timer (arch_timer) sanal timer sağlar. EL1 Physical Timer, EL1 Virtual Timer ve EL2 Physical Timer olmak üzere ayrı timer register'ları mevcuttur. Guest'ler virtual timer kullanırken hypervisor EL2 timer ile kendi zamanlama görevlerini yürütür.

bash — Timer sanallaştırma kontrolü
# ARM arch_timer interrupt'ları
cat /proc/interrupts | grep arch_timer
# 11:    123456    GICv3  11 Level    arch_timer
# 12:      5678    GICv3  12 Level    arch_timer (virtual)

# Timer frekansı
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
# arch_sys_counter

SGI — Software Generated Interrupt

SGI (Software Generated Interrupt, IPI), yazılım tarafından üretilen ve işlemciler arası iletişim için kullanılan bir GIC interrupt türüdür. Hypervisor ortamında SGI'lar sanal CPU'lar arasında da kullanılabilir — örneğin dom0 bir domU vCPU'sunu SGI ile uyandırabilir.

bash — GIC interrupt türleri
# GIC interrupt kategorileri
# SGI (Software Generated): 0-15   — IPI, işlemciler arası
# PPI (Private Peripheral):  16-31 — CPU'ya özel (timer, PMU)
# SPI (Shared Peripheral):   32+   — paylaşılan (UART, DMA)
# LPI (Locality-spec):       8192+ — MSI, PCIe

# /proc/interrupts ile interrupt dağılımı
cat /proc/interrupts | head -20
#           CPU0   CPU1   CPU2   CPU3
#  1:        100      0      0      0  GICv3   1 Edge  IPI reschedule
#  2:          0    150      0      0  GICv3   2 Edge  IPI call func
# 11:      45678  23456  12345   9876  GICv3  11 Level arch_timer

# Xen: virtual SGI kullanımı
xl dmesg | grep -i "SGI\|IPI"
# (XEN) VGIC: virtual SGI injection for domain 1

Interrupt affinity ve real-time

bash — Interrupt affinity yönetimi
# Interrupt'ı belirli CPU'ya yönlendir
cat /proc/irq/58/smp_affinity_list
# 0-3  (tüm CPU'larda)

# Sadece CPU 0-1'de işle (real-time CPU 2-3 korunur)
echo "0,1" > /proc/irq/58/smp_affinity_list

# UART interrupts → CPU 0'a yönlendir
for irq in $(grep -l serial /proc/irq/*/type 2>/dev/null | \
             grep -o '[0-9]\+'); do
    echo 1 > /proc/irq/$irq/smp_affinity
done

# Jailhouse'da inmate CPU'larına interrupt routing
# Cell config irqchips.pin_bitmap ile kontrol edilir

Bu bölümde

  • Trap-and-emulate: en yüksek gecikme, eski GIC ile zorunlu
  • Virtual IRQ injection: GICv3 — orta gecikme, yaygın kullanım
  • LPI direct injection: GICv4 — donanım hızında, en düşük gecikme
  • ARM Generic Timer: EL1 virtual / EL2 physical — guest/hypervisor ayrımı
  • SGI (IPI): yazılım interrupt — vCPU'lar arası uyandırma mekanizması
  • smp_affinity: interrupt CPU yönlendirmesi — RT CPU koruması

08 ARM VHE ve EL2 exception flow

ARM VHE (Virtualization Host Extensions, ARMv8.1) host OS'u EL2'de çalıştırmayı mümkün kılar. Bu, KVM gibi hosted hypervisor'ların EL1↔EL2 geçişi overhead'ını ortadan kaldırır.

VHE nedir?

Geleneksel ARM sanallaştırmada host OS EL1'de, hypervisor EL2'de çalışır. KVM gibi hypervisor'larda EL1 (host Linux) ile EL2 (kvm.ko) arasındaki context switch overhead sorunuydu. VHE ile:

DurumHost OSHypervisorGuest OS
VHE öncesiEL1EL2EL1 (ayrı)
VHE sonrasıEL2 (HCR_EL2.E2H=1)EL2 (kernel modülü)EL1

EL2 exception entry/exit akışı

Guest (EL1) çalışıyor
       |
       | Privileged instruction / Stage-2 fault / IRQ (IMO=1)
       ↓
EL2 exception vector (VBAR_EL2)
       |
       | Hypervisor exception handler
       | - ESR_EL2: exception syndrome register okuma
       | - FAR_EL2: fault address register (page fault ise)
       | - HPFAR_EL2: IPA fault address
       ↓
Hypervisor işlemi tamamlar (page table güncelle, IRQ inject, emüle et)
       |
       | ERET (Exception Return)
       ↓
Guest (EL1) kaldığı yerden devam eder
    

ESR_EL2 — Exception Syndrome Register

C — ESR_EL2 decode örneği (Jailhouse stili)
/* ESR_EL2 EC (Exception Class) alanı [31:26] */
/* Yaygın EC değerleri */
#define ESR_EC_UNKNOWN       0x00  /* bilinmeyen neden */
#define ESR_EC_WFX           0x01  /* WFI/WFE trap */
#define ESR_EC_SVC_A64       0x15  /* SVC instruction (AArch64) */
#define ESR_EC_HVC_A64       0x16  /* HVC hypercall */
#define ESR_EC_SMC_A64       0x17  /* SMC secure monitor call */
#define ESR_EC_INSTR_ABORT   0x20  /* instruction abort (Stage-2) */
#define ESR_EC_DATA_ABORT    0x24  /* data abort (Stage-2) */
#define ESR_EC_SYS_REG       0x18  /* system register access */

static void handle_exception(uint64_t esr_el2)
{
    uint32_t ec = (esr_el2 >> 26) & 0x3F;

    switch (ec) {
    case ESR_EC_HVC_A64:
        handle_hypercall(esr_el2);
        break;
    case ESR_EC_DATA_ABORT:
        handle_mmio(esr_el2);
        break;
    case ESR_EC_SYS_REG:
        handle_sysreg(esr_el2);
        break;
    default:
        panic("Unhandled exception EC=0x%x", ec);
    }
}

Pratik: VHE kontrolü

bash — VHE desteği kontrolü
# CPU özelliklerini kontrol et
grep -o 'sve\|vhe\|lse\|atomics' /proc/cpuinfo | sort -u
# Doğrudan VHE flag görünmeyebilir; kernel loguna bak

dmesg | grep -i "vhe\|el2\|hyp"
# [    0.000000] CPU: All CPU(s) booted fully, EL2 available
# [    0.000001] kvm: hypervisor initialized (VHE mode)

# ARM CPU ID register — ARMv8.1 veya üstü gerekli
cat /sys/devices/system/cpu/cpu0/regs/identification/midr_el1
# 0x00000000410fd034  (Cortex-A53 örneği)
# VHE için en az Cortex-A72 / ARMv8.1 gerekli

# KVM VHE mod doğrulama
dmesg | grep "kvm:"
# [    2.345678] kvm: Hyp mode initialized successfully

VMID — Virtual Machine Identifier

ARM MMU her sanal makine için ayrı bir VMID (Virtual Machine Identifier) kullanır. VMID TLB'yi etiketler, böylece farklı guest'lerin çeviri girdileri birbirini geçersiz kılmaz. VMID alanı 8 veya 16 bit olabilir (VTCR_EL2.VS bit ile).

bash — VMID ve TLB invalidation
# ARM64 TLB invalidation komutları (hypervisor context)
# Tüm TLB girişlerini temizle (VMID bağımsız)
tlbi alle2     ; EL2 TLB hepsini temizle
tlbi alle1is   ; EL1 TLB (inner shareable)

# Belirli IPA için Stage-2 TLB invalidation
tlbi ipas2e1is, x0   ; x0 = IPA >> 12

# VMID tabanlı TLB invalidation
# VTTBR_EL2 kaydında VMID[63:48] alanı
# msr VTTBR_EL2, x0  ; x0 = (vmid << 48) | (s2_pgdir >> 1)
isb
dsb ish

Stage-2 sayfa tablosu konfigürasyonu

C — Stage-2 MMU konfigürasyonu (VTCR_EL2)
/* VTCR_EL2 — Virtualization Translation Control Register */
/* T0SZ[5:0]: (64 - IPA_size_bits) — IPA adres uzunluğu */
/* SL0[7:6]:  başlangıç seviyesi (00=L2, 01=L1, 10=L0)  */
/* TG0[15:14]: granüle boyutu (00=4KB, 01=64KB, 10=16KB) */
/* PS[18:16]:  fiziksel adres boyutu                     */

#define VTCR_T0SZ_40BIT  (64 - 40)   /* 40-bit IPA */
#define VTCR_SL0_L1      (0x1 << 6)  /* Level 1 başlangıç */
#define VTCR_TG0_4KB     (0x0 << 14)
#define VTCR_PS_40BIT    (0x2 << 16) /* 40-bit PA */
#define VTCR_SH0_IS      (0x3 << 12) /* Inner Shareable */
#define VTCR_ORGN0_WBWA  (0x1 << 10)
#define VTCR_IRGN0_WBWA  (0x1 << 8)

static uint64_t vtcr_el2 = VTCR_T0SZ_40BIT | VTCR_SL0_L1 |
                            VTCR_TG0_4KB    | VTCR_PS_40BIT |
                            VTCR_SH0_IS     | VTCR_ORGN0_WBWA |
                            VTCR_IRGN0_WBWA;

/* Hypervisor başlangıcında VTCR_EL2 yazılır */
void setup_stage2_mmu(void)
{
    asm volatile("msr vtcr_el2, %0\n isb" :: "r"(vtcr_el2));
}

Hypercall mekanizması

Guest OS, hypervisor ile HVC (Hypervisor Call) talimatı aracılığıyla iletişim kurar. HVC çalıştırıldığında EL2'ye trap oluşur. Xen, KVM ve Jailhouse farklı hypercall arayüzleri tanımlar.

C — Xen ARM hypercall mekanizması
/* Xen ARM hypercall calling convention */
/* x0: hypercall numarası                */
/* x1-x5: parametreler                  */
/* Sonuç: x0                            */

#define __HYPERVISOR_console_io    18
#define __HYPERVISOR_grant_table_op 20
#define __HYPERVISOR_memory_op     12

static long xen_hypercall(unsigned long op,
                          unsigned long a1,
                          unsigned long a2)
{
    long ret;
    asm volatile(
        "mov x0, %1\n"
        "mov x1, %2\n"
        "mov x2, %3\n"
        "hvc #0\n"
        "mov %0, x0\n"
        : "=r"(ret)
        : "r"(op), "r"(a1), "r"(a2)
        : "x0", "x1", "x2", "memory"
    );
    return ret;
}

/* Örnek: Xen console'a yazdır */
void xen_console_write(const char *str, int len)
{
    xen_hypercall(__HYPERVISOR_console_io, 0,
                  (unsigned long)str);
}

PSCI — Power State Coordination Interface

PSCI, ARM işlemcilerde güç yönetimi için standart bir hypercall arayüzüdür. CPU_ON, CPU_OFF, SYSTEM_RESET gibi operasyonlar PSCI üzerinden gerçekleştirilir. Hypervisor PSCI çağrılarını yakalar ve guest'in CPU'ları açıp kapamasına izin verir.

bash — PSCI doğrulama
# PSCI versiyonu kontrol et
cat /sys/firmware/devicetree/base/psci/compatible
# arm,psci-1.0

# PSCI metodunu kontrol et (hvc veya smc)
cat /sys/firmware/devicetree/base/psci/method
# hvc  (hypervisor varsa hvc, yoksa smc)

# CPU hotplug (PSCI CPU_ON çağrısı kullanır)
echo 0 > /sys/devices/system/cpu/cpu3/online
echo 1 > /sys/devices/system/cpu/cpu3/online

Bu bölümde

  • VHE (ARMv8.1): host OS'u EL2'de çalıştır — EL1↔EL2 overhead yok
  • EL2 exception entry: VBAR_EL2 → handler → ESR_EL2 decode → işlem
  • VMID: TLB etiketleme — farklı guest'lerin çeviri girişleri çakışmaz
  • VTCR_EL2: Stage-2 MMU konfigürasyonu — T0SZ, SL0, PS alanları
  • HVC: guest → hypervisor hypercall — x0=numara, x1-x5=parametreler
  • PSCI: güç yönetimi için standart hypercall — hvc veya smc metodu
  • ERET: EL2'den EL1'e dönüş — guest kaldığı yerden devam eder