Kedalaman virtualisasi Windows (Bagian 1) — Di mana Windows Anda berjalan: hypervisor dan partisi

Jika Informasi Sistem (msinfo32) dibuka di Windows 11, tidak sedikit PC yang menampilkan “Berjalan” pada bidang “Keamanan berbasis virtualisasi”. Termasuk mesin yang belum pernah membuat satu pun VM.

Artinya adalah fakta berikut. Di PC itu, Windows host sendiri sudah berjalan di atas hypervisor. “Virtualisasi” bukan lagi teknologi hanya bagi orang yang membuat VM di Hyper-V Manager. Di Windows 11, virtualization-based security (VBS) diaktifkan secara default pada konfigurasi yang memenuhi syarat, misalnya instalasi bersih ke perangkat keras yang didukung¹, dan baik WSL2 maupun Windows Sandbox bertumpu pada Windows hypervisor yang sama. Di bawah Windows yang dipakai sehari-hari, ada satu lapisan perangkat lunak lagi.

Seri “Kedalaman virtualisasi Windows” menelusuri apa yang terjadi di lapisan itu, mulai dari fondasinya secara berurutan.

“Kedalaman virtualisasi Windows” — 3 bagian

1. Bagian 1 (artikel ini): hypervisor dan partisi
   Menelusuri di mana Windows host berjalan setelah Hyper-V diaktifkan.
2. Bagian 2: Memori yang tidak terlihat bahkan dari kernel — VBS, HVCI, Credential Guard
   Menelusuri di mana Windows menaruh rahasia yang tidak bisa dibaca, baik dengan hak administrator maupun dari kernel.
3. Bagian 3: Mesin virtual yang menyala dalam hitungan detik — WSL2, Windows Sandbox, kontainer
   Menelusuri, dari berbagi memori dan image, mengapa WSL2 dan Sandbox ringan padahal VM penuh terasa berat.

Pertanyaan yang dijawab Bagian 1 hanya satu.

Ketika Hyper-V diaktifkan, di mana Windows host berjalan?

Pembaca sasaran adalah pengembang dan operator yang memakai Hyper-V, WSL2, atau Windows Sandbox, dan ingin memahami dari mekanismenya apa yang berjalan di bawahnya. Lingkungan prasyarat adalah Windows 10/11 x64 atau Windows Server terkini (penjelasan ring, VT-x/AMD-V, dan EPT/RVI di artikel ini mengasumsikan x64; Arm64 memakai mekanisme lain seperti exception level). Pengetahuan prasyarat cukup membedakan mode kernel dan mode pengguna; pengalaman operasi VM atau pengetahuan pengembangan hypervisor tidak diperlukan. Tingkat kesulitannya menengah. Konsep fitur bantuan virtualisasi CPU dibahas, tetapi rincian instruction set tidak dimasuki.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 22, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

1. Mulai dari kesimpulan

Mendengar Hyper-V, yang terbayang mungkin “perangkat lunak pelaksana VM yang berjalan di atas Windows”. Strukturnya justru terbalik.

Sejak Hyper-V diaktifkan dan sistem di-reboot, yang menguasai CPU fisik dan memori adalah hypervisor, dan Windows host berjalan di atasnya sebagai partisi pertama yang memiliki hak istimewa, bernama “root partition”.

Hypervisor adalah lapisan perangkat lunak tipis yang masuk di antara perangkat keras dan OS, membuat lingkungan eksekusi terisolasi yang disebut “partisi”, lalu menengahi akses ke perangkat keras.² Tempat Windows host masuk adalah root partition; tempat VM masuk adalah child partition. Root partition diperlakukan khusus (memiliki akses langsung ke perangkat fisik dan tumpukan manajemen), tetapi dalam hal tidak menguasai CPU fisik secara langsung, posisinya sama dengan child partition.

flowchart TB
    accTitle: Struktur keseluruhan setelah Hyper-V diaktifkan
    accDescr: Langsung di atas perangkat keras fisik ada hypervisor, dan di atasnya berjajar root partition yang menampung Windows host serta child partition yang menampung VM
    hw["Perangkat keras fisik"] --> hv["Hypervisor"]
    hv --> root["Root partition (Windows host)"]
    hv --> child1["Child partition (VM)"]
    root -.-> stack["Memiliki tumpukan manajemen virtualisasi dan driver perangkat"]

Gambar 1: Hyper-V bukan “perangkat lunak VM di atas Windows”, melainkan lapisan yang masuk di bawah Windows, dan OS host sendiri berjalan di dalam root partition.

Mungkin terasa aneh: “rasanya tidak berubah setelah diaktifkan, apakah benar terjadi pembalikan sebesar itu?” Ya, terjadi. Justru karena itu struktur ini biasanya tidak disadari. Artikel ini membongkar satu diagram itu dari tiga arah: CPU, memori, dan I/O perangkat.

2. Dilihat dari CPU — satu hak istimewa lagi di bawah ring

2.1. Mengingat ring protection

CPU x64 memiliki tingkat hak istimewa (ring), dan Windows menjalankan mode kernel di ring 0 serta mode pengguna di ring 3. Aplikasi tidak bisa menyentuh perangkat keras secara langsung karena instruksi istimewa tidak dapat dieksekusi dari ring 3.

Lalu, bagaimana beberapa kernel OS yang masing-masing berjalan di ring 0 bisa hidup berdampingan dengan aman di CPU fisik yang sama? Setiap kernel ditulis dengan anggapan “akulah yang menguasai CPU”. Jika ring 0 diberikan kepada semua, mereka bentrok; jika tidak diberikan, mereka tidak berjalan.

flowchart TB
    accTitle: Masalah beberapa kernel OS yang menuntut ring 0
    accDescr: Kernel host dan tamu keduanya ditulis dengan anggapan wewenang penuh di ring 0, sehingga tangga ring tradisional saja tidak cukup untuk menampung mereka dengan aman di CPU fisik yang sama
    k1["Kernel host (anggapan ring 0)"] --> want["Menuntut hak kendali CPU fisik"]
    k2["Kernel tamu (anggapan ring 0)"] --> want
    want --> conflict["Ring tradisional saja tidak bisa merukunkan ini"]
    conflict --> need["Diperlukan penengah di atas ring 0"]

Gambar 2: Tangga ring dibuat dengan anggapan satu OS, sehingga menampung beberapa kernel membutuhkan satu hak istimewa lagi di atasnya.

2.2. Fitur bantuan virtualisasi — mode khusus hypervisor

Yang menyelesaikan masalah ini adalah fitur bantuan virtualisasi CPU (Intel VT-x/AMD-V). Hyper-V mensyaratkan prosesor yang memiliki fitur ini.² Fitur bantuan virtualisasi menambahkan, pada sumbu terpisah dari ring tradisional, “mode eksekusi untuk hypervisor” dan “mode eksekusi untuk tamu”. Itu hak istimewa yang lebih kuat lagi daripada ring 0, kadang dijuluki “ring -1”.

• Kernel tamu tetap berjalan di ring 0 seperti semula. Tidak perlu ditulis ulang.
• Namun ring 0 itu adalah “ring 0 di dalam mode tamu”, dan tidak menguasai CPU fisik secara keseluruhan.
• Ketika tamu menabrak operasi tertentu yang memerlukan campur tangan hypervisor (instruksi yang ditetapkan sebagai sasaran intercept, atau exception/pelanggaran), CPU secara otomatis memindahkan kendali ke hypervisor (VM Exit). Setelah hypervisor selesai menangani, kendali dikembalikan ke tamu (VM Entry). Akses memori biasa lewat tanpa VM Exit selama terjemahan SLAT berhasil.

Interrupt juga sama. Partisi tidak menyentuh prosesor fisik secara langsung; interrupt diterima hypervisor lalu diarahkan ke masing-masing partisi.²

flowchart TB
    accTitle: Alur eksekusi tamu dan VM Exit
    accDescr: Kernel dan aplikasi tamu berjalan di ring 0 dan ring 3 dalam mode tamu; akses memori biasa lewat berkat terjemahan SLAT, sementara operasi yang ditetapkan sebagai sasaran intercept atau exception memicu VM Exit yang memindahkan kendali ke hypervisor, lalu kembali ke tamu lewat VM Entry
    guest["Sedang berjalan di mode tamu (termasuk kernel ring 0)"] --> op{"Operasi yang butuh campur tangan? (intercept/exception yang ditetapkan)"}
    op -->|Tidak| cont["Lanjut mengeksekusi apa adanya"]
    op -->|Ya| exitEv["VM Exit (CPU memindahkan kendali)"]
    exitEv --> hvp["Hypervisor menangani"]
    hvp --> entry["Kembali ke tamu lewat VM Entry"]
    entry --> guest

Gambar 3: OS tamu tetap berjalan di ring 0 tanpa ditulis ulang, dan CPU memanggil hypervisor hanya ketika diperlukan.

Bolak-balik ini sangat mirip dengan alur yang ditelusuri di seri memori: “masuk ke kernel pada page fault, lalu kembali ke instruksi yang sama”. CPU mencegat kendali lewat mekanisme exception/transisi, membiarkan pengelola tingkat lebih tinggi memutuskan, lalu mengembalikan ke semula. Di kedalaman Windows, bentuk ini muncul berulang kali.

2.3. Type 1 dan Type 2 — bedanya di lapisan mana ia berada

Hypervisor secara garis besar dibagi menjadi Type 1 (bare-metal) yang berjalan langsung di perangkat keras, dan Type 2 (hosted) yang berjalan di atas OS host. Hyper-V adalah Type 1.³ VirtualBox dan VMware Workstation (ketika dijalankan mandiri) diklasifikasikan sebagai Type 2.

Mendengar Type 1, orang cenderung membayangkan “konfigurasi khusus server tanpa OS host”, tetapi Hyper-V berbeda. Windows host tidak hilang; ia “pindah rumah” ke dalam root partition. Setelah Hyper-V diaktifkan dan sistem di-reboot, dalam proses boot hypervisor start lebih dulu, lalu Windows host bangkit sebagai root partition di atasnya.

flowchart TB
    accTitle: Perbedaan hypervisor Type 1 dan Type 2
    accDescr: Pada Type 2 OS host ada di atas perangkat keras dan hypervisor serta VM duduk di atas OS host, sedangkan pada Type 1 Hyper-V hypervisor ada langsung di atas perangkat keras dan OS host sendiri masuk ke root partition di atasnya
    subgraph t2 ["Type 2 (hosted)"]
        hw2["Perangkat keras"] --> hostos["OS host"]
        hostos --> hv2["Hypervisor"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Type 1 (Hyper-V)"]
        hw1["Perangkat keras"] --> hv1["Hypervisor"]
        hv1 --> root1["Root partition (OS host)"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

Gambar 4: Pada Type 2 hypervisor duduk di atas OS host, sedangkan pada Type 1 Hyper-V urutannya terbalik dan OS host sendiri duduk di atas lapisan di bawahnya.

Perubahan sebelum dan sesudah pengaktifan, jika dilihat pada sumbu waktu boot, seperti ini.

flowchart TB
    accTitle: Urutan boot setelah Hyper-V diaktifkan
    accDescr: Setelah daya dinyalakan, dalam proses boot hypervisor start lebih dulu, lalu Windows host bangkit sebagai root partition, dan VM serta VBS dan sejenisnya mulai setelah itu
    poweron["Daya dinyalakan, boot mulai"] --> bhv["Hypervisor start lebih dulu"]
    bhv --> broot["Windows host start sebagai root partition"]
    broot --> blater["VM, VBS, WSL2, dan sejenisnya mulai di atasnya"]
    broot -.-> feel["Pengalaman pengguna tetap seperti semula"]

Gambar 5: Pembalikan urutan sudah selesai sebelum layar logon muncul, dan OS host bangkit dari awal di atas hypervisor.

3. Partisi — satuan isolasi

3.1. Peran yang hanya dimiliki root partition

Partisi adalah satuan logis isolasi yang disediakan hypervisor.² Namun tidak semua partisi setara. Ada yang hanya dimiliki root partition.

• Akses langsung ke perangkat fisik. Driver perangkat untuk disk, NIC, GPU, dan sejenisnya dimiliki Windows di dalam root partition, bukan hypervisor. Catatan: Hyper-V di Windows Server memiliki konfigurasi yang menugaskan perangkat PCIe tertentu langsung ke child partition (Discrete Device Assignment); dalam kasus itu root melepaskan perangkat tersebut (tidak tersedia di Windows edisi klien).⁴
• Tumpukan manajemen virtualisasi. VMMS (Virtual Machine Management Service) yang mengatur pembuatan, start, dan penghentian VM, serta proses worker per VM (vmwp.exe), berjalan di mode pengguna root partition.⁵ Ini bagian dari fungsi manajemen VM Hyper-V, sehingga bisa tidak ada di host yang hanya menjalankan hypervisor untuk VBS atau WSL2.
• Hak membuat child partition. Root partition membuat child partition lewat hypercall API (antarmuka pemanggilan ke hypervisor).²

Desain ini ada alasannya. Jika semua driver perangkat dimasukkan ke badan hypervisor, hypervisor membengkak, dan pintu masuk bug serta serangan ikut bertambah. Hypervisor menuntaskan pekerjaan minimal: menengahi CPU dan memori, lalu urusan perangkat diserahkan ke Windows di root partition. Pembagian peran ini yang menopang ketipisan Hyper-V.

flowchart TB
    accTitle: Pembagian peran root partition dan child partition
    accDescr: Root partition memiliki tumpukan manajemen virtualisasi dan driver perangkat fisik, lalu membuat child partition lewat hypercall; child partition pada konfigurasi biasa hanya melihat perangkat virtual, dan pada Discrete Device Assignment untuk Windows Server mengakses langsung perangkat yang ditugaskan
    subgraph rootp ["Root partition"]
        vmms["VMMS dan proses worker"]
        drv["Driver perangkat fisik"]
    end
    subgraph childp ["Child partition"]
        gos["OS tamu"]
        vdev["Pada konfigurasi biasa hanya perangkat virtual yang terlihat"]
    end
    vmms -->|Dibuat dan dikelola lewat hypercall| childp
    hv2["Hypervisor (menuntaskan penengahan CPU dan memori)"] --- rootp
    hv2 --- childp

Gambar 6: Dengan menempatkan driver perangkat dan tumpukan manajemen di sisi root partition, badan hypervisor tetap tipis.

3.2. Dunia yang terlihat dari child partition

OS tamu di child partition, pada konfigurasi perangkat virtual biasa, tidak dapat melihat perangkat keras fisik secara langsung (pengecualian hanya perangkat yang ditugaskan lewat Discrete Device Assignment untuk Windows Server yang dibahas di bagian sebelumnya). Yang terlihat adalah prosesor virtual, ruang memori yang tampak milik sendiri, dan perangkat virtual. Permintaan ke perangkat virtual diteruskan ke root partition lewat VMBus atau lewat hypervisor.² Di sisi lain, pembagian waktu CPU dan terjemahan memori oleh SLAT ditangani langsung hypervisor tanpa melewati root. Yang ditengahi root adalah I/O perangkat, bukan semua sumber daya fisik.

flowchart TB
    accTitle: Dunia yang terlihat dari child partition
    accDescr: Yang terlihat bagi OS tamu adalah prosesor virtual, ruang memori privat partisi, dan perangkat virtual; permintaan ke perangkat virtual diteruskan ke root partition lewat VMBus dan sejenisnya, waktu CPU dan terjemahan memori ditangani langsung hypervisor, dan pada konfigurasi Discrete Device Assignment untuk Windows Server hanya perangkat yang ditugaskan yang diakses langsung
    gos2["OS tamu di child partition"] --> vcpu["Prosesor virtual"]
    gos2 --> gpa2["Ruang memori privat"]
    gos2 --> vdev2["Perangkat virtual"]
    vdev2 -->|"Lewat VMBus dan sejenisnya"| rootx["Diteruskan ke root partition"]
    gos2 -.->|Tidak terlihat langsung| phys2["CPU fisik, RAM, perangkat nyata"]
    phys2 -.-> dda2["Pada konfigurasi DDA (Windows Server) hanya perangkat yang ditugaskan yang diakses langsung"]
    vcpu ~~~ phys2

Gambar 7: Pada konfigurasi perangkat virtual biasa, semua yang terlihat tamu adalah jendela virtual dan jalur ke fisik melewati penengah; hanya perangkat yang ditugaskan lewat DDA di Windows Server yang menjadi pengecualian.

Yang penting di sini: bagi aplikasi yang berjalan di Windows host, struktur ini hampir transparan. Baik pemanggilan Win32 API maupun penanganan page fault tetap diproses kernel Windows di dalam root partition seperti semula. Hypervisor campur tangan hanya pada saat menabrak sasaran intercept yang ditetapkan atau exception.

4. Dilihat dari memori — terjemahan alamat bertambah satu tingkat

4.1. Tiga jenis alamat

Di Bagian 1 seri memori, alur terjemahan alamat virtual menjadi alamat fisik lewat page table ditelusuri (“Saat alamat virtual menjadi RAM fisik”). Di lingkungan virtualisasi, satu tingkat lagi ditambahkan di bawah terjemahan itu, sehingga ada tiga jenis alamat.

OS tamu menerjemahkan GVA menjadi GPA dengan page tablenya sendiri. Namun GPA yang dilihat tamu bukan alamat fisik sungguhan, melainkan ruang memori privat khusus masing-masing partisi.² Memetakan GPA ke posisi di RAM sebenarnya (SPA) adalah pekerjaan hypervisor.

4.2. SLAT — terjemahan dua tingkat di perangkat keras

Jika terjemahan tingkat kedua ini dilakukan hanya di perangkat lunak, hypervisor harus mengikuti setiap pembaruan page table tamu satu per satu, yang tidak realistis dari sisi performa. Karena itu CPU menyediakan mekanisme untuk menelusuri tabel terjemahan tingkat kedua di perangkat keras. Itulah SLAT (Second Level Address Translation); yang termasuk di dalamnya adalah Intel EPT (extended page table) dan AMD RVI. Hyper-V terkini mensyaratkan prosesor 64-bit yang mendukung SLAT.⁴

flowchart TB
    accTitle: Terjemahan alamat dua tingkat oleh SLAT
    accDescr: Alamat virtual tamu diterjemahkan menjadi alamat fisik tamu oleh page table OS tamu, lalu diterjemahkan lagi menjadi alamat fisik sistem oleh SLAT yang dikelola hypervisor, sampai mencapai RAM sebenarnya
    gva["Alamat virtual tamu (GVA)"] -->|Page table OS tamu| gpa["Alamat fisik tamu (GPA)"]
    gpa -->|"SLAT (tabel terjemahan EPT/RVI)"| spa["Alamat fisik sistem (SPA)"]
    spa --> ram["RAM fisik"]
    gpa -.-> note["Lapisan yang hanya diyakini tamu sebagai fisik"]

Gambar 8: Di bawah page table tamu masuk satu tabel terjemahan lagi yang dikelola hypervisor, dan CPU menelusuri keduanya di perangkat keras.

SLAT bukan fitur hanya untuk efisiensi eksekusi VM. VBS yang dibahas di Bagian 2 memakai sifat “setiap tingkat hak istimewa dapat memiliki tabel terjemahan SLAT yang berbeda” sebagai bahan batas keamanan. Alasan memori yang bahkan tidak diperlihatkan ke kernel bisa dibuat adalah karena terjemahan tingkat kedua ini dipegang hypervisor. Ini menjadi benang merah seluruh seri, jadi ingat satu poin saja: “pengelola tabel terjemahan adalah hypervisor”.

5. Dilihat dari I/O perangkat — VMBus dan dua jenis perangkat

5.1. Batas perangkat teremulasi

Cara klasik menampilkan perangkat ke child partition adalah meniru perangkat keras nyata (misalnya pengontrol IDE lama) secara lengkap di perangkat lunak. Kompatibilitas tinggi karena driver standar OS tamu bisa dipakai apa adanya, tetapi setiap kali tamu mengakses port I/O terjadi VM Exit, sehingga performa tidak naik.

flowchart TB
    accTitle: Alasan I/O perangkat teremulasi lambat
    accDescr: Setiap kali tamu mengoperasikan port I/O, kendali pindah ke sisi hypervisor lewat VM Exit, perangkat ditiru di perangkat lunak, lalu kembali ke tamu; bolak-balik itu berulang sehingga lambat
    gio["Tamu mengoperasikan port I/O"] --> vex["VM Exit terjadi"]
    vex --> emu2["Perangkat ditiru di perangkat lunak"]
    emu2 --> back["Kembali ke tamu lewat VM Entry"]
    back -->|Berulang lagi pada operasi port berikutnya| gio

Gambar 9: Di balik satu akses disk, bolak-balik ini berjalan berkali-kali, dan harga kompatibilitas dibayar dengan performa.

5.2. VMBus dan VSP/VSC — jalur cepat yang dirancang dengan anggapan virtualisasi

Karena itu Hyper-V memiliki mekanisme “perangkat sintetis” yang dirancang dengan anggapan virtualisasi. Ada tiga pelaku.²

• VMBus: saluran komunikasi logis antarpartisi. Menyediakan komunikasi antarpartisi berkecepatan tinggi yang memakai memori bersama.³
• VSP (Virtualization Service Provider): layanan yang tinggal di sisi root partition, menerima permintaan perangkat dari child, lalu menjembatani ke tumpukan perangkat/backend di sisi root. Permintaan kadang sampai ke perangkat fisik, kadang diproses di backend sisi host seperti disk virtual atau virtual switch.
• VSC (Virtualization Service Consumer): driver perangkat sintetis yang masuk ke OS tamu di sisi child partition. Mengirim permintaan ke VSP lewat VMBus.

Jika permintaan penyimpanan OS tamu dipakai sebagai contoh, alurnya sebagai berikut. WriteFile aplikasi tamu turun lewat tumpukan I/O kernel tamu, dan di lapisan terbawah sampai ke VSC (sebagai ganti perangkat keras nyata). VSC menaruh permintaan di VMBus dan menyerahkannya ke VSP di root partition, lalu VSP mengalirkan permintaan ke tumpukan I/O sisi root. Pada konfigurasi disk virtual (VHDX), penulisan ini diproses sebagai penulisan ke file VHDX di host, dan akhirnya sampai ke disk fisik. Cara ini disebut Enlightened I/O (I/O yang sadar virtualisasi), dan menaikkan efisiensi dengan melewati lapisan emulasi perangkat.²

flowchart TB
    accTitle: Jalur I/O perangkat sintetis
    accDescr: Permintaan I/O aplikasi di child partition sampai ke VSC lewat kernel tamu, menyeberang ke VSP di root partition lewat VMBus, lalu di tumpukan I/O sisi root yang dijembatani VSP kadang sampai ke perangkat nyata lewat driver perangkat fisik, kadang diproses di backend sisi host seperti disk virtual atau virtual switch
    app["Aplikasi di child partition"] --> gk["Tumpukan I/O kernel tamu"]
    gk --> vsc["VSC (driver perangkat sintetis)"]
    vsc -->|VMBus| vsp["VSP (sisi root partition)"]
    vsp --> rio["Tumpukan I/O sisi root"]
    rio --> pdrv["Driver perangkat fisik"]
    rio --> hb["Backend sisi host (disk virtual, virtual switch, dll.)"]
    pdrv --> dev["Perangkat fisik"]

Gambar 10: Pada perangkat sintetis, I/O tamu menyeberang ke root partition lewat VMBus, lalu sampai ke perangkat nyata atau backend sisi host lewat tumpukan sisi root.

Artinya, apakah I/O disk atau jaringan VM cepat tidak hanya bergantung pada sisi tamu, tetapi juga pada keadaan tumpukan I/O dan driver perangkat di sisi root partition. Alasan observasi sisi host tidak bisa dilewatkan saat menelusuri masalah performa VM adalah karena jalurnya memang melewati host.

flowchart TB
    accTitle: Perbandingan perangkat teremulasi dan perangkat sintetis
    accDescr: Perangkat teremulasi meniru perangkat keras nyata sehingga driver standar tamu bisa dipakai tetapi lambat; perangkat sintetis memakai driver khusus dengan anggapan VMBus dan cepat
    dev2{"Perangkat yang ditampilkan ke child partition"} --> emu["Perangkat teremulasi"]
    dev2 --> syn["Perangkat sintetis"]
    emu -.-> emuP["Meniru perangkat keras nyata, mengutamakan kompatibilitas"]
    emuP -.-> emuC["Setiap I/O butuh campur tangan, lambat"]
    syn -.-> synP["Dirancang dengan anggapan VMBus, cepat"]
    synP -.-> synC["Tamu memerlukan driver yang sesuai"]

Gambar 11: Dari dua jenis perangkat virtual, kompatibilitas segera setelah OS diinstal ditanggung emulasi, dan performa pemakaian sehari-hari ditanggung perangkat sintetis.

6. Mengapa ini bukan urusan orang lain, meski tidak memakai VM

Struktur sampai di sini mungkin tampak “cerita orang yang membuat VM”. Namun seperti di awal, di Windows sekarang hypervisor adalah bagian dari keseharian.

• Virtualization-based security (VBS). Memakai Windows hypervisor untuk membuat lingkungan terisolasi, lalu menampung fungsi keamanan di sana. Di Windows 11, diaktifkan secara default jika syarat terpenuhi, misalnya instalasi bersih ke perangkat keras yang didukung.¹ Rinciannya dibahas di Bagian 2.
• WSL2. Menjalankan kernel Linux sungguhan di dalam utility VM yang ringan.⁶
• Windows Sandbox. Lingkungan Windows sekali pakai yang dipisahkan oleh hypervisor.⁷ Keduanya dibahas di Bagian 3.

flowchart TB
    accTitle: Fungsi sehari-hari yang duduk di hypervisor yang sama
    accDescr: Bukan hanya VM Hyper-V; VBS yang diaktifkan secara default pada perangkat yang memenuhi syarat seperti instalasi bersih, WSL2, dan Windows Sandbox juga bertumpu pada Windows hypervisor yang sama
    base["Windows hypervisor"] --> f1["VM Hyper-V"]
    base --> f2["VBS (default pada instalasi bersih, dll.)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Alasan ia berjalan di PC yang tidak memakai VM"]

Gambar 12: Fondasinya satu, dan anggapan “virtualisasi adalah urusan orang yang memakai VM” runtuh di diagram ini.

Satu lagi yang sering terbentur di praktik adalah hidup berdampingan dengan perangkat lunak virtualisasi pihak lain. Fitur bantuan virtualisasi CPU dipakai hypervisor secara eksklusif, sehingga di lingkungan yang Windows hypervisor-nya sedang berjalan, VirtualBox dan sejenisnya tidak bisa berjalan dengan cara lama (cara memakai bantuan virtualisasi CPU sendiri). Untuk itu disediakan API publik bernama Windows Hypervisor Platform, dan tumpukan virtualisasi pihak lain dapat berjalan dengan duduk di atas Windows hypervisor.⁸ VirtualBox/VMware terkini dan WSL2 bisa hidup berdampingan berkat mekanisme ini, tetapi selisih performa dan fungsi yang menyertai pergantian cara kadang teramati sebagai “setelah Hyper-V (atau VBS) diaktifkan, perangkat lunak virtualisasi berubah kelakuannya”.

flowchart TB
    accTitle: Pemilik bantuan virtualisasi CPU dan jalur perangkat lunak virtualisasi pihak lain
    accDescr: Saat Windows hypervisor berjalan, fitur bantuan virtualisasi CPU dikuasai hypervisor; perangkat lunak virtualisasi pihak lain yang mendukung WHP berjalan di atasnya lewat Windows Hypervisor Platform, sedangkan implementasi yang tidak mendukung WHP tidak berjalan atau fungsinya dibatasi
    vt["Bantuan virtualisasi CPU (VT-x/AMD-V)"] --> hvon{"Windows hypervisor sedang berjalan?"}
    hvon -->|Tidak| direct["Perangkat lunak pihak lain dapat memakai langsung"]
    hvon -->|Ya| own["Dikuasai hypervisor"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["Perangkat lunak pihak lain yang mendukung WHP berjalan di atasnya"]
    third -.-> nowhp["Implementasi yang tidak mendukung tidak berjalan atau fungsinya dibatasi"]

Gambar 13: Pemilik fitur bantuan virtualisasi hanya satu, dan yang bisa hidup berdampingan saat hypervisor berjalan terbatas pada perangkat lunak pihak lain yang mendukung API publik (WHP).

7. Memeriksa sendiri

Apakah hypervisor sedang berjalan di PC sendiri dapat dicek langsung.

Pertama, pemeriksaan yang bisa dijalankan tanpa hak administrator.

# Apakah sedang berjalan di atas hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# Keadaan VBS (sumber informasi yang sama dengan "Keamanan berbasis virtualisasi" di msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus mengembalikan keadaan berjalan VBS sebagai angka (2 berarti “Berjalan”).⁹

Ada satu catatan. HypervisorPresent hanya menunjukkan “apakah sedang berjalan di atas hypervisor”, tanpa membedakan root atau child. Jika dijalankan di Windows di dalam VM, hasilnya True sebagai child partition. Jika True pada Windows di PC fisik, Windows itu berada di dalam root partition — dibaca bersama lingkungan eksekusinya.

Berikutnya, cara andalan dari Command Prompt.

systeminfo

Lihat “Persyaratan Hyper-V” di ujung keluaran. Pada mesin yang hypervisornya belum berjalan, syarat seperti dukungan SLAT dan aktif/tidaknya bantuan virtualisasi ditampilkan satu per satu. Pada mesin yang hypervisornya sudah berjalan, sebagai ganti daftar syarat hanya muncul satu baris bahwa hypervisor terdeteksi dan fitur yang diperlukan Hyper-V tidak ditampilkan.⁴ Dengan kata lain, satu baris itu adalah pernyataan bahwa Windows Anda sedang berjalan di atas suatu hypervisor. Sama seperti HypervisorPresent, perlu dibedakan: di PC fisik berarti di dalam root partition; di dalam VM berarti sebagai child partition.

Meski semua syarat di systeminfo “Ya”, artinya sisi perangkat keras sudah siap. Fitur Hyper-V sendiri tersedia di edisi Pro, Enterprise, dan Education, dan tidak ada di Home.¹⁰

Dari GUI, periksa baris “Keamanan berbasis virtualisasi” di “Ringkasan sistem” msinfo32. Perhatikan bahwa “Virtualisasi: Diaktifkan” di kolom CPU Task Manager hanya menunjukkan apakah fitur bantuan virtualisasi diaktifkan di firmware, dan itu informasi yang berbeda dari apakah hypervisor sedang berjalan.

flowchart TB
    accTitle: Langkah memeriksa keadaan berjalan hypervisor
    accDescr: Jika systeminfo menampilkan bahwa hypervisor terdeteksi maka sedang berjalan di atas hypervisor (di PC fisik berarti di dalam root partition); jika daftar persyaratan Hyper-V muncul maka belum berjalan, jadi periksa semua syarat seperti SLAT, VM Monitor Mode Extensions, DEP; meski semua Ya, itu kesiapan sisi perangkat keras, dan fitur Hyper-V juga punya syarat edisi
    start2["Jalankan systeminfo"] --> q1{"Kolom persyaratan Hyper-V?"}
    q1 -->|Hypervisor terdeteksi| running["Hypervisor sedang berjalan (di PC fisik: di dalam root)"]
    q1 -->|Daftar syarat ditampilkan| notyet["Hypervisor belum berjalan"]
    notyet --> q2{"Semua syarat Ya?"}
    q2 -->|Semua Ya| can["Sisi perangkat keras sudah siap"]
    can -.-> ed["Hyper-V juga memerlukan Pro/Enterprise/Education"]
    q2 -->|Ada yang tidak| uefi["Periksa item terkait di UEFI/BIOS"]

Gambar 14: Kolom “Persyaratan Hyper-V” di systeminfo merangkap pemeriksaan keadaan berjalan dan pemeriksaan prasyarat.

8. Tiga salah baca yang sebaiknya dihindari di praktik

8.1. “Hyper-V belum diaktifkan, jadi virtualisasi tidak ada urusannya dengan PC kami”

Meski fitur Hyper-V (alat manajemen dan lingkungan eksekusi VM) belum diaktifkan, Windows hypervisor tetap berjalan jika VBS aktif. Saat menelusuri masalah kompatibilitas driver, uji performa, atau gangguan perangkat lunak virtualisasi pihak lain, yang dicek bukan apakah fiturnya diaktifkan, melainkan HypervisorPresent dan keadaan berjalan VBS.

8.2. “Task Manager menampilkan ‘Virtualisasi: Diaktifkan’, jadi Hyper-V sedang berjalan”

Tampilan itu soal pengaturan firmware (apakah VT-x/AMD-V dapat dipakai). Keadaan berjalan hypervisor dinilai dari tampilan bahwa hypervisor terdeteksi di systeminfo. Sebaliknya, jika Task Manager menampilkan “Dinonaktifkan”, Hyper-V maupun WSL2 tidak bisa diaktifkan, jadi pengaturan UEFI/BIOS diperiksa lebih dulu.

flowchart TB
    accTitle: Tiga item pemeriksaan yang mudah dikacaukan
    accDescr: Kolom virtualisasi Task Manager menunjukkan pengaturan firmware, daftar Windows Features menunjukkan keadaan instalasi, dan systeminfo atau HypervisorPresent menunjukkan keadaan berjalan; masing-masing menjawab pertanyaan yang berbeda
    q3{"Apa yang ingin diketahui?"} --> a3["Apakah bantuan virtualisasi aktif di firmware"]
    q3 --> b3["Apakah fitur Hyper-V sudah dipasang"]
    q3 --> c3["Apakah hypervisor sedang berjalan sekarang"]
    a3 -.-> a3t["Kolom CPU Task Manager"]
    b3 -.-> b3t["Layar pengaktifan Windows Features"]
    c3 -.-> c3t["systeminfo dan HypervisorPresent"]

Gambar 15: Ketiganya pertanyaan yang independen, dan menyimpulkan dua yang lain dari satu tampilan adalah salah baca.

8.3. “Jika VM lambat, itu masalah OS tamu”

I/O perangkat sintetis menyeberang ke VSP di root partition lewat VMBus, lalu melewati tumpukan perangkat/backend sisi root (selain driver fisik, juga pemrosesan virtual switch dan disk virtual). Jika hanya memandang penghitung di dalam tamu, bottleneck yang ada di penyimpanan atau NIC sisi host tidak ditemukan. Prinsip masalah performa VM adalah mengamati dari kedua sisi: tamu dan host (root partition).

9. Ringkasan

• Setelah Hyper-V diaktifkan, hypervisor berjalan langsung di atas perangkat keras, dan Windows host berjalan sebagai root partition.²
• Kernel OS tamu tetap berjalan di ring 0, dan hanya operasi yang ditetapkan sebagai sasaran intercept serta exception yang diserahkan ke hypervisor lewat VM Exit. Akses memori biasa lewat berkat terjemahan SLAT.
• Hanya root partition yang memiliki driver perangkat fisik dan tumpukan manajemen virtualisasi, dan membuat child partition lewat hypercall.²
• Memori menjadi terjemahan dua tingkat GVA→GPA→SPA, dan tingkat kedua ditangani SLAT (EPT/RVI) di perangkat keras. Hyper-V terkini mensyaratkan SLAT.⁴
• I/O perangkat didominasi jalur perangkat sintetis VSC→VMBus→VSP, dan performa juga bergantung pada tumpukan I/O sisi host.²
• Di Windows 11, karena VBS yang diaktifkan secara default pada perangkat yang memenuhi syarat seperti instalasi bersih, tidak jarang hypervisor berjalan bahkan di PC yang tidak memakai VM.¹ Keadaan berjalan dapat dicek dengan HypervisorPresent dan systeminfo.

Gambaran besar Bagian 1 terangkum di satu diagram ini.

flowchart TB
    accTitle: Gambaran besar Bagian 1
    accDescr: Di bawah root partition dan child partition ada hypervisor; CPU dialokasikan dengan menjadwalkan prosesor virtual (VM Exit hanya pada intercept dan exception yang ditetapkan), memori ditengahi terjemahan dua tingkat SLAT, I/O perangkat sintetis diteruskan lewat VMBus dan ditangani VSP root partition, dan perangkat teremulasi serta Discrete Device Assignment punya jalur lain
    up["Root partition dan child partition"] --> hvS["Hypervisor"]
    hvS --> cpuS["CPU: mengalokasikan prosesor virtual"]
    hvS --> memS["Memori: terjemahan dua tingkat SLAT"]
    hvS --> devS["Perangkat: sintetis diteruskan lewat VMBus"]
    cpuS -.-> cpuN["VM Exit hanya saat campur tangan"]
    devS --> vspS["VSP sisi root yang menangani"]
    devS -.-> devN["Emulasi dan DDA adalah jalur lain"]

Gambar 16: Penjadwalan CPU dan terjemahan memori ditangani langsung hypervisor (VM Exit hanya saat campur tangan), dan I/O perangkat sintetis ditengahi root partition (VSP) di seberang VMBus.

Lanjutannya adalah Bagian 2, “Memori yang tidak terlihat bahkan dari kernel — VBS, HVCI, Credential Guard”.

Benang merah artikel ini — bahwa hypervisor memegang tabel terjemahan SLAT — akan ditarik, dan ditelusuri bagaimana Windows membuat “memori yang tidak bisa dibaca, baik dengan hak administrator maupun dari kernel”.

Artikel terkait

• Kedalaman memori Windows (Bagian 1) — Saat alamat virtual menjadi RAM fisik: page fault dari awal sampai akhir
• Apa arti “pemakaian memori” Windows — Membaca Working Set, Private Bytes, Commit, dan page file dengan benar
• Membuat lingkungan uji aplikasi bisnis dengan Windows Sandbox
• Inti P/E Windows dan penjadwalan prosesor

Area konsultasi terkait

KomuraSoft LLC menangani perancangan lingkungan uji aplikasi Windows, investigasi performa di lingkungan virtualisasi, serta analisis masalah kompatibilitas driver dan periferal.

• Pengembangan aplikasi Windows
• Investigasi bug dan analisis penyebab
• Pemanfaatan aset yang ada dan dukungan migrasi
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Setelah Hyper-V diaktifkan, di mana Windows host berjalan?

Hypervisor yang mengendalikan langsung pembagian CPU fisik dan memori, dan Windows host berjalan di dalam partisi khusus yang disebut root partition. Pengendalian perangkat fisik biasanya ditangani driver di sisi root partition. Root partition memiliki driver perangkat dan tumpukan manajemen virtualisasi, tetapi hak kendali atas CPU fisik ada di sisi hypervisor.

Apakah "Virtualisasi: Diaktifkan" di Task Manager berarti Hyper-V sedang berjalan?

Tidak. Tampilan itu menunjukkan apakah fitur bantuan virtualisasi CPU (Intel VT-x/AMD-V) diaktifkan di firmware. Apakah hypervisor benar-benar sedang berjalan dicek dari tampilan bahwa hypervisor terdeteksi di systeminfo, atau dari HypervisorPresent pada Win32_ComputerSystem.

Mengapa hypervisor berjalan padahal belum ada VM yang dibuat?

Di Windows 11, virtualization-based security (VBS) diaktifkan secara default pada perangkat yang memenuhi syarat — misalnya instalasi bersih ke perangkat keras yang didukung — dan VBS bertumpu pada Windows hypervisor. Hal yang sama berlaku saat memakai WSL2 atau Windows Sandbox. Tidak jarang hypervisor sudah berjalan, terlepas dari pemakaian VM.

Apa itu SLAT, dan mengapa wajib untuk Hyper-V?

SLAT (Second Level Address Translation) adalah mekanisme agar CPU menerjemahkan alamat fisik tamu menjadi alamat fisik sebenarnya; Intel EPT dan AMD RVI termasuk di dalamnya. Tanpa ini, hypervisor harus merawat tabel terjemahan di perangkat lunak, yang tidak realistis dari sisi performa, sehingga Hyper-V terkini menjadikannya syarat wajib.

Jika Hyper-V diaktifkan, apakah VirtualBox dan VMware tidak bisa dipakai?

Hypervisor memakai fitur bantuan virtualisasi CPU secara eksklusif, sehingga hypervisor pihak lain tidak bisa berjalan dengan cara lama. Namun VirtualBox dan VMware terkini memiliki mode yang berjalan di atas Windows hypervisor (lewat Windows Hypervisor Platform), sehingga kombinasi versi terbaru bisa hidup berdampingan.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.