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şen | Güvenlik Seviyesi | OS | Bölme |
|---|---|---|---|
| IVI / Multimedya | QM (Quality Managed) | Android / Linux | domU / non-root cell |
| Telematics / Bağlantı | ASIL-B | Linux + TEE | domU / non-root cell |
| ADAS | ASIL-B/C | Linux (güvenli) | ayrı domU |
| Powertrain / Güvenlik | ASIL-D | RTOS (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.
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
| Özellik | Type-1 (Bare-metal) | Type-2 (Hosted) |
|---|---|---|
| Çalışma katmanı | Doğrudan donanım üzerinde | Host OS üzerinde |
| Performans | Yüksek — donanım erişimi doğrudan | Düşük — host OS overhead |
| Güvenlik yüzeyi | Küçük — minimal hypervisor kodu | Büyük — host OS dahil |
| Determinizm | Yüksek — real-time mümkün | Düşük — host OS jitter |
| Örnekler | Xen, Jailhouse, ACRN, seL4/CAmkES | VirtualBox, VMware Workstation, QEMU |
| Gömülü kullanım | Tercih edilen | Geliş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.
| Hypervisor | TCB Büyüklüğü | Sertifikasyon Uygunluğu |
|---|---|---|
| Jailhouse | ~20.000 satır | ASIL-D için uygun |
| Xen (minimal subset) | ~100.000 satır | ASIL-B/C için zorlu |
| KVM + Linux | ~25.000.000 satır | ASIL için pratik değil |
| seL4 | ~10.000 satır | Formally 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şama | Giriş | Çıkış | Kontrol Eden |
|---|---|---|---|
| Stage-1 | VA (Virtual Address) | IPA (Intermediate Physical Address) | Guest OS (EL1) |
| Stage-2 | IPA (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.
; 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.
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şım | Guest OS Değişimi | Performans | Uyumluluk | Örnek |
|---|---|---|---|---|
| Full Virtualization | Yok — değiştirilmemiş guest | Orta — her privileged instr. trap | Yüksek — herhangi bir OS | QEMU (binary translation) |
| Paravirtualization (PV) | Yüksek — guest hypercall kullanır | Yüksek — trap sayısı az | Düşük — kernel değiştirilmeli | Xen PV, virtio |
| HW-Assisted | Minimal — driver-level | En yüksek — donanım trap | Yüksek — değiştirilmemiş guest | Xen 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.
# 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.
# 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.
# 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.
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
| Hypervisor | Mimari | Lisans | Güvenlik | Ekosistem | Gömülü Uygunluk |
|---|---|---|---|---|---|
| Xen | Type-1, mikro-kernel benzeri | GPL-2.0 | FLASK/XSM, Xen Security Modules | Geniş — Yocto, OpenEmbedded | Yüksek — ARM, x86 |
| Jailhouse | Type-1, static partitioning | GPL-2.0 | Minimal saldırı yüzeyi | Orta — Yocto destekli | Çok yüksek — determinizm |
| KVM/ARM | Type-1 (Linux modülü) | GPL-2.0 | Linux güvenlik modülleri | Çok geniş — QEMU, libvirt | Orta — overhead yüksek |
| ACRN | Type-1, Intel odaklı | BSD-3-Clause | ACRN-DM güvenlik modeli | Orta — Intel ekosistemi | Yüksek — IVI odaklı |
| seL4 | Mikro-kernel | GPL-2.0 / ticari | Formal verification | Kı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
# 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ı
| Standart | Sektör | Hypervisor Gereksinimi | Uygun Seçenek |
|---|---|---|---|
| ISO 26262 ASIL-D | Otomotiv | Formal kanıt + küçük TCB | Jailhouse, seL4 |
| IEC 61508 SIL-3 | Endüstriyel | Güvenlik analizi + test | Jailhouse, Xen |
| DO-178C Level A | Aviyonik | MC/DC coverage + formal | seL4, PikeOS |
| CC EAL4+ | Güvenlik | Formal doğrulama | seL4, 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
Savunma stratejileri
# 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
# 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)
# 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ı
| Mod | Açıklama | Gecikme | Kullanım |
|---|---|---|---|
| Trap-and-emulate | GIC register erişimi EL2'ye trap olur, hypervisor emüle eder | Yüksek (~1µs) | Eski GICv2 |
| Virtual IRQ injection | Hypervisor sanal IRQ oluşturur, guest CPU arayüzüne yazar | Orta (~500ns) | GICv3 |
| LPI direct injection | Fiziksel IRQ doğrudan guest'e — hypervisor müdahalesi yok | Düşük (~100ns) | GICv4, passthrough |
Xen'de interrupt yönetimi
# 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.
# 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.
# 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
# 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:
| Durum | Host OS | Hypervisor | Guest OS |
|---|---|---|---|
| VHE öncesi | EL1 | EL2 | EL1 (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
/* 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ü
# 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).
# 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
/* 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.
/* 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.
# 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