Ketika Anda mengaktifkan Hyper-V, di mana Windows host sebenarnya berjalan?

Hypervisor mengambil kendali langsung atas cara CPU fisik dan memori dialokasikan, dan Windows host berjalan di dalam partisi khusus yang disebut root partition. Kendali perangkat fisik biasanya ditangani oleh driver di sisi root partition. Root partition menahan driver perangkat dan tumpukan manajemen virtualisasi, tetapi kepemilikan CPU fisik milik hypervisor.

Apakah "Virtualization: Enabled" di Task Manager berarti Hyper-V sedang berjalan?

Tidak. Tampilan itu menunjukkan apakah ekstensi virtualisasi CPU (Intel VT-x/AMD-V) diaktifkan di firmware. Untuk melihat apakah hypervisor benar-benar berjalan, cari "A hypervisor has been detected" di systeminfo, atau periksa Win32_ComputerSystem.HypervisorPresent.

Mengapa hypervisor berjalan padahal saya tidak pernah membuat VM?

Di Windows 11, virtualization-based security (VBS) diaktifkan secara bawaan pada perangkat yang memenuhi syarat — misalnya instalasi bersih pada perangkat keras yang kompatibel — dan VBS dibangun di atas Windows hypervisor. Hal yang sama berlaku jika Anda memakai WSL2 atau Windows Sandbox. Tidak aneh hypervisor berjalan tanpa hubungan dengan siapa pun yang memakai VM.

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

SLAT (Second Level Address Translation) adalah mekanisme yang dipakai CPU untuk menerjemahkan alamat fisik tamu menjadi alamat fisik sungguhan; Intel EPT dan AMD RVI adalah implementasinya. Tanpanya hypervisor harus merawat tabel terjemahan di perangkat lunak, yang tidak realistis dari sudut performa, jadi Hyper-V terkini memperlakukannya sebagai syarat keras.

Jika saya mengaktifkan Hyper-V, apakah VirtualBox dan VMware berhenti bekerja?

Karena hypervisor memakai ekstensi virtualisasi CPU secara eksklusif, hypervisor pihak ketiga tidak dapat berjalan dengan cara tradisional. VirtualBox dan VMware terkini, namun, punya mode yang berjalan di atas Windows hypervisor (lewat Windows Hypervisor Platform), jadi versi terbaru masing-masing dapat hidup berdampingan.

Kedalaman virtualisasi Windows (Bagian 1) — Di mana Windows Anda sebenarnya berjalan? Hypervisor dan partisi

22 Aug 2026 02:00 · Go Komura · Windows, Virtualisasi, Hyper-V, Hypervisor, SLAT, VMBus

Buka System Information (msinfo32) di Windows 11 dan Anda sering melihat “Running” di bidang “Virtualization-based security” — bahkan pada mesin di mana Anda tidak pernah membuat VM.

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

Seri ini, “Kedalaman virtualisasi Windows”, mengikuti apa yang terjadi di lapisan itu, mulai dari fondasinya.

“Kedalaman virtualisasi Windows” — seluruh 3 bagian

Bagian 1 (artikel ini): Hypervisor dan partisi
Kita mengikuti ke mana Windows host berakhir berjalan ketika Anda mengaktifkan Hyper-V.
Bagian 2: Memori yang bahkan kernel pun tidak bisa lihat — VBS, HVCI, dan Credential Guard
Kita mengikuti di mana Windows menaruh rahasia yang tidak dapat dibaca administrator maupun kernel.
Bagian 3: Mesin virtual yang boot dalam hitungan detik — WSL2, Windows Sandbox, dan kontainer
Kita mengikuti, dari cara memori dan image dibagi, mengapa WSL2 dan Sandbox ringan padahal VM penuh itu berat.

Pertanyaan yang dijawab Bagian 1 hanya satu.

Ketika Anda mengaktifkan Hyper-V, ke mana Windows host berakhir 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. Prasyarat adalah Windows 10/11 x64 atau Windows Server terkini (pembahasan ring, VT-x/AMD-V, dan EPT/RVI di artikel ini mengasumsikan x64; Arm64 memakai mekanisme berbeda seperti exception level). Latar belakang yang dibutuhkan adalah sekitar pembedaan mode kernel dan mode pengguna; Anda tidak perlu pengalaman operasi VM atau pengetahuan pengembangan hypervisor. Tingkat kesulitannya menengah. Kita membahas konsep ekstensi virtualisasi CPU, tetapi tidak masuk ke rincian instruction set.

1. Kesimpulan lebih dulu

Ketika orang mendengar Hyper-V, mereka mungkin membayangkan “perangkat lunak yang menjalankan VM yang duduk di atas Windows”. Struktur sebenarnya terbalik.

Sejak saat Anda mengaktifkan Hyper-V dan reboot, hypervisor-lah yang mengendalikan CPU fisik dan memori, dan Windows host berjalan di atasnya sebagai partisi pertama yang berhak istimewa — “root partition”.

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

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

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

Anda mungkin berpikir, “Jika rasanya tidak berbeda setelah saya mengaktifkannya, apakah pembalikan sebesar itu benar-benar terjadi?” Sudah. Justru karena itu struktur ini biasanya tidak kentara. Di artikel ini kita membongkar diagram tunggal ini sepanjang tiga sumbu: CPU, memori, dan I/O perangkat.

2. Dari CPU — satu hak istimewa lagi di bawah ring

2.1. Rekap perlindungan ring

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

Jadi bagaimana Anda menampung dengan aman beberapa kernel OS, masing-masing berjalan di ring 0, pada CPU fisik yang sama? Setiap kernel ditulis dengan asumsi “saya mengendalikan CPU”. Beri ring 0 kepada semuanya dan mereka bertabrakan; tahan dan mereka tidak akan berjalan.

flowchart TB
    accTitle: Masalah beberapa kernel OS yang menuntut ring 0
    accDescr: Baik kernel host maupun tamu ditulis dengan asumsi wewenang penuh di ring 0, jadi tangga ring tradisional saja tidak dapat menampung mereka dengan aman pada CPU fisik yang sama
    k1["Kernel host (asumsi ring 0)"] --> want["Menuntut kendali CPU fisik"]
    k2["Kernel tamu (asumsi ring 0)"] --> want
    want --> conflict["Ring tradisional tidak bisa merukunkan ini"]
    conflict --> need["Penengah di atas ring 0 dibutuhkan"]

Gambar 2: Tangga ring dibangun dengan asumsi satu OS, jadi menampung beberapa kernel membutuhkan satu hak istimewa lagi di atasnya.

2.2. Ekstensi virtualisasi — mode yang dicadangkan untuk hypervisor

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

Kernel tamu terus berjalan di ring 0, seperti semula. Tidak perlu penulisan ulang.
Ring 0 itu, namun, adalah “ring 0 di dalam mode tamu”, dan ia tidak mengendalikan CPU fisik secara keseluruhan.
Ketika tamu menabrak operasi tertentu yang membutuhkan campur tangan hypervisor (instruksi yang dikonfigurasi sebagai intercept, atau exception atau pelanggaran), CPU secara otomatis memindahkan kendali ke hypervisor (VM Exit). Ketika hypervisor selesai menanganinya, ia kembali ke tamu (VM Entry). Akses memori biasa lewat tanpa VM Exit, selama terjemahan SLAT berhasil.

Interrupt bekerja dengan cara yang sama. Partisi tidak menyentuh prosesor fisik secara langsung; hypervisor menerima interrupt dan mengarahkannya ke setiap partisi.²

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

Gambar 3: OS tamu terus berjalan di ring 0 tanpa penulisan ulang, dan CPU memanggil hypervisor hanya ketika dibutuhkan.

Bolak-balik ini terlihat sangat mirip dengan alur yang kita ikuti di seri memori — “masuk ke kernel pada page fault, lalu kembali ke instruksi yang sama”. CPU mencegat kendali lewat mekanisme exception atau transisi, membiarkan pengelola tingkat lebih tinggi memutuskan, lalu kembali. Di kedalaman Windows, bentuk ini muncul berulang-ulang.

2.3. Tipe 1 dan Tipe 2 — perbedaannya adalah di mana ia duduk

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

Mendengar Tipe 1, orang cenderung membayangkan “konfigurasi hanya-server tanpa OS host”, tetapi Hyper-V berbeda. Windows host tidak hilang — ia “pindah rumah” ke dalam root partition. Ketika Anda mengaktifkan Hyper-V dan reboot, hypervisor start lebih dulu selama boot, dan Windows host lalu muncul sebagai root partition di atasnya.

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

Gambar 4: Di Tipe 2 hypervisor duduk di OS host, sedangkan di Tipe 1 Hyper-V urutannya terbalik dan OS host sendiri duduk di lapisan satu tingkat di bawah.

Dilihat pada linimasa boot, perubahan yang terjadi ketika Anda mengaktifkannya tampak seperti ini.

flowchart TB
    accTitle: Urutan boot setelah Hyper-V diaktifkan
    accDescr: Setelah dinyalakan, hypervisor start lebih dulu selama boot, Windows host lalu muncul sebagai root partition di atasnya, dan VM, VBS, serta sejenisnya start setelah itu
    poweron["Nyala dan boot mulai"] --> bhv["Hypervisor start lebih dulu"]
    bhv --> broot["Windows host start sebagai root partition"]
    broot --> blater["VM, VBS, WSL2, dan sebagainya start di atas itu"]
    broot -.-> feel["Pengalaman pengguna tidak berubah"]

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

3. Partisi — satuan isolasi

3.1. Peran yang hanya dimiliki root partition

Partisi adalah satuan logis isolasi yang disediakan hypervisor.² Tidak setiap partisi setara, walaupun. Ada hal yang hanya dimiliki root partition.

Akses langsung ke perangkat fisik. Driver perangkat untuk disk, NIC, GPU, dan sejenisnya tinggal di Windows di dalam root partition, bukan di hypervisor. Hyper-V di Windows Server memang punya konfigurasi yang menugaskan perangkat PCIe tertentu langsung ke child partition (Discrete Device Assignment); dalam kasus itu root melepaskan perangkat itu (ini tidak tersedia di Windows klien).⁴
Tumpukan manajemen virtualisasi. VMMS (Virtual Machine Management Service), yang mengatur membuat, start, dan menghentikan VM, serta proses worker per-VM (vmwp.exe) berjalan di mode pengguna di root partition.⁵ Ini adalah bagian dari fitur manajemen VM Hyper-V, jadi mereka mungkin absen pada host di mana hanya hypervisor yang berjalan untuk VBS atau WSL2.
Hak membuat child partition. Root partition membuat child partition lewat hypercall API (antarmuka pemanggilan ke hypervisor).²

Desain ini punya alasan. Jika Anda menaruh setiap driver perangkat ke dalam hypervisor sendiri, hypervisor menjadi raksasa dan jumlah bug serta pintu masuk serangan tumbuh. Hypervisor membatasi diri pada pekerjaan minimal menengahi CPU dan memori, dan menyerahkan perawatan perangkat kepada Windows di root partition. Pembagian peran ini yang menjaga Hyper-V tetap tipis.

flowchart TB
    accTitle: Pembagian peran antara root partition dan child partition
    accDescr: Root partition menahan tumpukan manajemen virtualisasi dan driver perangkat fisik serta membuat child partition lewat hypercall; child partition biasanya hanya melihat perangkat virtual, dan di bawah Discrete Device Assignment di Windows Server ia mengakses perangkat yang ditugaskan secara langsung
    subgraph rootp ["Root partition"]
        vmms["VMMS dan proses worker"]
        drv["Driver perangkat fisik"]
    end
    subgraph childp ["Child partition"]
        gos["OS tamu"]
        vdev["Di konfigurasi biasa, hanya perangkat virtual yang terlihat"]
    end
    vmms -->|Buat dan kelola lewat hypercall| childp
    hv2["Hypervisor (membatasi diri menengahi CPU dan memori)"] --- rootp
    hv2 --- childp

Gambar 6: Menaruh driver perangkat dan tumpukan manajemen di sisi root partition-lah yang menjaga hypervisor sendiri tetap tipis.

3.2. Dunia seperti yang dilihat dari child partition

OS tamu di child partition tidak dapat melihat perangkat keras fisik secara langsung dalam konfigurasi perangkat virtual biasa (satu-satunya pengecualian adalah perangkat yang ditugaskan lewat Discrete Device Assignment di Windows Server, seperti dijelaskan di bagian sebelumnya). Yang dapat dilihatnya adalah prosesor virtual, ruang memori yang tampak miliknya, dan perangkat virtual. Permintaan ke perangkat virtual diteruskan ke root partition lewat VMBus atau hypervisor.² Alokasi waktu CPU dan terjemahan memori lewat SLAT, di sisi lain, ditangani langsung oleh hypervisor tanpa melalui root. Yang ditengahi root adalah I/O perangkat, bukan setiap sumber daya fisik.

flowchart TB
    accTitle: Dunia seperti yang dilihat dari child partition
    accDescr: Yang dilihat 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 oleh hypervisor, dan dalam konfigurasi Discrete Device Assignment di Windows Server hanya perangkat yang ditugaskan yang diakses langsung
    gos2["OS tamu（child）"] --> vcpu["Prosesor virtual"]
    gos2 --> rest{"Memori atau perangkat?"}
    rest --> gpa2["Ruang memori privat"]
    rest --> vdev2["Perangkat virtual"]
    vdev2 --> rootx["Diteruskan ke root"]
    rootx -.-> vbus["Lewat VMBus dan sejenisnya"]
    gos2 -.-> phys2["CPU fisik, RAM, perangkat"]
    phys2 -.-> hid["Tidak terlihat langsung"]
    phys2 -.-> dda2["DDA: perangkat yang ditugaskan"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

Gambar 7: Dalam konfigurasi perangkat virtual biasa segala yang dilihat tamu adalah jendela virtual dan jalur ke fisik melalui penengah; hanya perangkat yang ditugaskan lewat DDA di Windows Server yang menjadi pengecualian.

Yang penting di sini adalah bahwa bagi aplikasi yang berjalan di Windows host, struktur ini hampir transparan. Panggilan Win32 API dan penanganan page fault tetap diproses oleh kernel Windows di dalam root partition, seperti semula. Hypervisor campur tangan hanya ketika intercept atau exception yang dikonfigurasi ditabrak.

4. Dari memori — terjemahan alamat mendapat satu tingkat lagi

4.1. Tiga jenis alamat

Di Bagian 1 seri memori kita mengikuti alur di mana alamat virtual diterjemahkan lewat page table menjadi alamat fisik (“Saat alamat virtual menjadi RAM fisik”). Di lingkungan tervirtualisasi satu tingkat lagi ditambahkan di bawah terjemahan itu, dan ada tiga jenis alamat.

Alamat	Singkatan	Siapa yang mengelolanya
Alamat virtual tamu	GVA	Page table OS tamu
Alamat fisik tamu	GPA	Alamat yang OS tamu yakini “fisik”
Alamat fisik sistem	SPA	Hypervisor (lokasi sungguhan di RAM)

OS tamu menerjemahkan GVA ke GPA dengan page table sendiri. GPA yang dilihat tamu, namun, bukan alamat fisik sungguhan; itu ruang memori privat yang dikhususkan untuk setiap partisi.² Memetakan GPA ke lokasi sungguhan di RAM (SPA) adalah pekerjaan hypervisor.

4.2. SLAT — terjemahan dua tingkat di perangkat keras

Jika Anda melakukan terjemahan tingkat kedua ini di perangkat lunak saja, hypervisor harus mengikuti setiap pembaruan page table tamu satu per satu, yang tidak realistis dari sudut performa. Jadi CPU menyediakan mekanisme yang menelusuri tabel terjemahan tingkat kedua di perangkat keras. Itu SLAT (Second Level Address Translation); Intel EPT (Extended Page Tables) dan AMD RVI adalah implementasinya. Hyper-V terkini mensyaratkan prosesor 64-bit yang mampu SLAT.⁴

flowchart TB
    accTitle: Terjemahan alamat dua tingkat lewat SLAT
    accDescr: Alamat virtual tamu diterjemahkan ke alamat fisik tamu oleh page table OS tamu, lalu diterjemahkan lebih lanjut ke alamat fisik sistem oleh SLAT, yang dikelola hypervisor, dan sampai ke RAM sungguhan
    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 tamu hanya yakini fisik"]

Gambar 8: Tabel terjemahan lain, yang dikelola hypervisor, duduk di bawah page table tamu, dan CPU menelusuri keduanya di perangkat keras.

SLAT bukan fitur yang ada hanya untuk efisiensi eksekusi VM. VBS yang akan kita lihat di Bagian 2 memakai sifat bahwa “Anda dapat punya tabel terjemahan SLAT yang berbeda per tingkat hak” sebagai bahan untuk batas keamanan. Alasan Anda dapat membuat memori yang bahkan kernel pun tidak dapat lihat adalah bahwa hypervisor menahan terjemahan tingkat kedua ini. Ini menjadi benang merah seluruh seri, jadi ingat saja satu poin: “pemilik tabel terjemahan adalah hypervisor”.

5. Dari I/O perangkat — VMBus dan dua jenis perangkat

5.1. Batas perangkat teremulasi

Cara klasik menunjukkan perangkat ke child partition adalah meniru sepenuhnya perangkat keras sungguhan (misalnya pengendali IDE lama) di perangkat lunak. Kompatibilitasnya tinggi karena driver inbox OS tamu bekerja apa adanya, tetapi VM Exit terjadi setiap kali tamu menabrak port I/O, dan performa tidak menskala.

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

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

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

Jadi Hyper-V punya mekanisme “perangkat sintetis” yang dirancang dengan asumsi virtualisasi. Ada tiga tokoh.²

VMBus: saluran komunikasi logis antarpartisi. Ia 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, dan menjembataninya ke tumpukan perangkat/backend di sisi root. Permintaan dapat sampai ke perangkat fisik, atau ditangani oleh 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. Ia mengirim permintaan ke VSP lewat VMBus.

Mengambil permintaan penyimpanan OS tamu sebagai contoh, alurnya tampak seperti ini. WriteFile aplikasi tamu turun tumpukan I/O kernel tamu dan, di bawah, sampai ke VSC (alih-alih perangkat keras sungguhan). VSC menaruh permintaan di VMBus dan menyerahkannya ke VSP di root partition, dan VSP mengalirkan permintaan ke tumpukan I/O sisi root. Dalam konfigurasi disk virtual (VHDX), penulisan ini ditangani sebagai penulisan ke berkas VHDX di host dan akhirnya sampai ke disk fisik. Pendekatan ini disebut Enlightened I/O (I/O yang sadar virtualisasi), dan ia menaikkan efisiensi dengan melewati lapisan emulasi perangkat.²

flowchart TB
    accTitle: Jalur I/O untuk perangkat sintetis
    accDescr: Permintaan I/O dari aplikasi di child partition sampai ke VSC lewat kernel tamu, menyeberang VMBus ke VSP di root partition, dan pada tumpukan I/O sisi root yang dijembatani VSP ia dapat sampai ke perangkat sungguhan lewat driver perangkat fisik, atau ditangani 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, dan sebagainya)"]
    pdrv --> dev["Perangkat fisik"]

Gambar 10: Dengan perangkat sintetis, I/O tamu menyeberang ke root partition lewat VMBus dan, melalui tumpukan sisi root, sampai ke perangkat sungguhan atau backend sisi host.

Dengan kata lain, apakah I/O disk atau jaringan VM cepat bergantung tidak hanya pada sisi tamu tetapi juga pada keadaan tumpukan I/O dan driver perangkat di sisi root partition. Alasan observasi sisi host sangat diperlukan ketika Anda menyelidiki masalah performa VM adalah bahwa jalurnya benar-benar melalui host.

flowchart TB
    accTitle: Perangkat teremulasi versus perangkat sintetis
    accDescr: Perangkat teremulasi meniru perangkat keras sungguhan agar driver inbox tamu bekerja tetapi lambat; perangkat sintetis adalah driver tujuan-khusus yang mengasumsikan VMBus dan cepat
    dev2{"Perangkat yang ditunjukkan ke child partition"} --> emu["Perangkat teremulasi"]
    dev2 --> syn["Perangkat sintetis"]
    emu -.-> emuP["Mengemulasi perangkat keras sungguhan; kompatibilitas dulu"]
    emuP -.-> emuC["Butuh campur tangan di setiap I/O; lambat"]
    syn -.-> synP["Dirancang di sekitar VMBus; cepat"]
    synP -.-> synC["Mensyaratkan driver yang cocok di tamu"]

Gambar 11: Dari dua jenis perangkat virtual, perangkat teremulasi membawa kompatibilitas tepat setelah instalasi OS, dan perangkat sintetis membawa performa dalam pemakaian sehari-hari.

6. Mengapa ini bukan urusan orang lain, bahkan jika Anda tidak pernah memakai VM

Struktur sejauh ini mungkin tampak seperti “cerita untuk orang yang mendirikan VM”. Seperti pembukaan katakan, walaupun, di Windows terkini hypervisor adalah bagian dari kehidupan sehari-hari.

Virtualization-based security (VBS). Ia memakai Windows hypervisor untuk membuat lingkungan terisolasi dan menampung fitur keamanan di sana. Di Windows 11 ia diaktifkan secara bawaan ketika syarat seperti instalasi bersih pada perangkat keras yang kompatibel terpenuhi.¹ Rinciannya di Bagian 2.
WSL2. Ia menjalankan kernel Linux sungguhan di dalam utility VM yang ringan.⁶
Windows Sandbox. Lingkungan Windows sekali pakai yang diisolasi oleh hypervisor.⁷ Keduanya dibahas di Bagian 3.

flowchart TB
    accTitle: Fitur sehari-hari yang duduk di hypervisor yang sama
    accDescr: Bukan hanya VM Hyper-V tetapi juga VBS, yang diaktifkan secara bawaan pada perangkat yang memenuhi syarat seperti instalasi bersih, plus WSL2 dan Windows Sandbox, semuanya dibangun di atas Windows hypervisor yang sama
    base["Windows hypervisor"] --> f1["VM Hyper-V"]
    base --> f2["VBS (bawaan pada instalasi bersih dan sejenis)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Mengapa ia berjalan bahkan di PC yang tidak pernah memakai VM"]

Gambar 12: Fondasinya satu, dan gambar ini adalah tempat asumsi “virtualisasi adalah cerita untuk orang yang memakai VM” runtuh.

Satu hal lagi yang sering dilangkahi orang dalam praktik adalah hidup berdampingan dengan perangkat lunak virtualisasi pihak ketiga. Karena hypervisor memakai ekstensi virtualisasi CPU secara eksklusif, di lingkungan di mana Windows hypervisor berjalan, VirtualBox dan sejenisnya tidak dapat berjalan dengan cara tradisional (cara yang memakai ekstensi virtualisasi CPU sendiri). Untuk ini, API publik yang disebut Windows Hypervisor Platform disediakan, dan tumpukan virtualisasi pihak ketiga dapat berjalan dengan duduk di atas Windows hypervisor.⁸ VirtualBox/VMware terkini dapat hidup berdampingan dengan WSL2 berkat mekanisme ini, tetapi perbedaan performa dan fitur yang datang bersama pergantian mode kadang diamati sebagai “setelah saya mengaktifkan Hyper-V (atau VBS), perangkat lunak virtualisasi mulai berperilaku berbeda”.

flowchart TB
    accTitle: Siapa pemilik ekstensi virtualisasi CPU, dan jalur untuk perangkat lunak virtualisasi pihak ketiga
    accDescr: Sementara Windows hypervisor berjalan ia secara eksklusif memiliki ekstensi virtualisasi CPU; perangkat lunak virtualisasi pihak ketiga yang mendukung WHP berjalan di atasnya lewat Windows Hypervisor Platform, sementara implementasi yang tidak mendukung WHP tidak dapat berjalan atau dibatasi fiturnya
    vt["Ekstensi virtualisasi CPU (VT-x/AMD-V)"] --> hvon{"Windows hypervisor berjalan?"}
    hvon -->|Tidak| direct["Perangkat lunak pihak ketiga dapat memakainya langsung"]
    hvon -->|Ya| own["Hypervisor memakai secara eksklusif"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["Perangkat lunak pihak ketiga yang mampu WHP berjalan di atasnya"]
    third -.-> nowhp["Implementasi yang tidak mampu tidak dapat berjalan, atau terbatas"]

Gambar 13: Ada satu pemilik ekstensi virtualisasi, dan satu-satunya perangkat lunak pihak ketiga yang dapat hidup berdampingan sementara hypervisor berjalan adalah perangkat lunak yang mendukung API publik (WHP).

7. Lihat sendiri

Anda dapat mengonfirmasi di mesin sendiri apakah hypervisor sedang berjalan.

Pertama, pemeriksaan yang dapat dijalankan tanpa hak administrator.

# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS status (same source as "Virtualization-based security" in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus mengembalikan keadaan berjalan VBS sebagai angka (2 adalah “Running”).⁹

Satu peringatan. Semua yang HypervisorPresent katakan kepada Anda adalah “apakah kita berjalan di atas hypervisor”; ia tidak membedakan root dari child. Jika Anda menjalankannya di Windows di dalam VM, ia tetap mengembalikan True, sebagai child partition. Jika True di Windows pada PC fisik, Windows itu berada di dalam root partition — Anda membacanya bersama lingkungan eksekusi.

Berikutnya, yang klasik dari Command Prompt.

systeminfo

Lihat “Hyper-V Requirements” di akhir keluaran. Pada mesin di mana hypervisor belum berjalan, syarat individual — dukungan SLAT, apakah ekstensi virtualisasi diaktifkan, dan sebagainya — tercantum. Pada mesin di mana hypervisor sudah berjalan, alih-alih syarat Anda mendapat satu baris: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”⁴ Satu baris itu karena itu pernyataan bahwa Windows Anda berjalan di atas suatu hypervisor. Seperti HypervisorPresent, Anda perlu membacanya sebagai “di dalam root partition” pada PC fisik, atau “sebagai child partition” di dalam VM.

Bahkan jika setiap syarat systeminfo adalah “Yes”, itu hanya berarti sisi perangkat keras siap. Fitur Hyper-V sendiri tersedia di edisi Pro, Enterprise, dan Education, dan tidak di Home.¹⁰

Di GUI, periksa baris “Virtualization-based security” di bawah “System Summary” di msinfo32. Perhatikan bahwa “Virtualization: Enabled” di panel CPU Task Manager hanya menunjukkan apakah ekstensi virtualisasi diaktifkan di firmware, yang merupakan informasi terpisah dari apakah hypervisor berjalan.

flowchart TB
    accTitle: Cara memeriksa apakah hypervisor berjalan
    accDescr: Jika systeminfo mengatakan hypervisor telah terdeteksi Anda berjalan di hypervisor (di dalam root partition pada PC fisik); jika daftar Hyper-V Requirements muncul ia belum berjalan jadi Anda memeriksa setiap syarat seperti SLAT, VM Monitor Mode Extensions, dan DEP, tetapi semua Yes hanya berarti sisi perangkat keras siap dan fitur Hyper-V juga punya syarat edisi
    start2["Jalankan systeminfo"] --> q1{"Bidang Requirements?"}
    q1 -->|Detected| running["Hypervisor sedang berjalan"]
    running -.-> runN["Di dalam root"]
    runN -.-> runN2["pada PC fisik"]
    q1 -->|Listed| notyet["Belum berjalan"]
    notyet --> q2{"Semua syarat Yes?"}
    q2 -->|Semua Yes| can["Sisi perangkat keras siap"]
    can -.-> ed["Butuh Pro / Ent / Edu"]
    q2 -->|Ada yang No| uefi["Periksa item UEFI/BIOS"]

Gambar 14: Bidang “Hyper-V Requirements” di systeminfo berfungsi ganda sebagai pemeriksaan keadaan berjalan dan pemeriksaan prasyarat.

8. Tiga salah baca yang harus dihindari dalam praktik

8.1. “Kami belum mengaktifkan Hyper-V, jadi virtualisasi tidak ada hubungannya dengan PC kami”

Bahkan jika Anda belum mengaktifkan fitur Hyper-V (alat manajemen dan lingkungan eksekusi VM), Windows hypervisor berjalan jika VBS diaktifkan. Ketika Anda menyelidiki masalah kompatibilitas driver, uji performa, atau gangguan dengan perangkat lunak virtualisasi pihak ketiga, periksa HypervisorPresent dan keadaan berjalan VBS — bukan apakah fiturnya diaktifkan.

8.2. “Task Manager bilang ‘Virtualization: Enabled’, jadi Hyper-V sedang berjalan”

Tampilan itu tentang pengaturan firmware (apakah VT-x/AMD-V tersedia). Nilai keadaan berjalan hypervisor dari “A hypervisor has been detected” di systeminfo. Sebaliknya, jika Task Manager bilang “Disabled”, Anda tidak dapat mengaktifkan Hyper-V atau WSL2 juga, jadi periksa pengaturan UEFI/BIOS lebih dulu.

flowchart TB
    accTitle: Tiga pemeriksaan yang mudah dikacaukan
    accDescr: Bidang Virtualization 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{"Pertanyaan yang mana?"}
    q3 --> fw{"Firmware atau Windows?"}
    q3 --> c3["Hypervisor berjalan?"]
    fw --> a3["Ekstensi firmware?"]
    fw --> b3["Fitur Hyper-V nyala?"]
    a3 -.-> a3t["Panel CPU Task Manager"]
    b3 -.-> b3t["UI Windows Features"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

Gambar 15: Ini tiga pertanyaan independen, dan menyimpulkan dua lainnya dari satu tampilan adalah salah baca.

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

I/O perangkat sintetis menyeberang VMBus ke VSP di root partition dan melalui tumpukan perangkat/backend sisi root (driver fisik, plus pemrosesan virtual switch dan disk virtual). Jika Anda hanya menonton penghitung di dalam tamu, Anda tidak akan menemukan bottleneck yang duduk di penyimpanan sisi host atau NIC. Prinsip untuk masalah performa VM adalah mengamati dari kedua sisi: tamu dan host (root partition).

9. Ringkasan

Ketika Anda mengaktifkan Hyper-V, hypervisor berjalan langsung di perangkat keras dan Windows host berjalan sebagai root partition.²
Kernel OS tamu terus berjalan di ring 0, dan hanya operasi yang dikonfigurasi sebagai intercept, plus exception, yang diserahkan ke hypervisor lewat VM Exit. Akses memori biasa lewat lewat terjemahan SLAT.
Hanya root partition yang menahan driver perangkat fisik dan tumpukan manajemen virtualisasi, dan ia membuat child partition lewat hypercall.²
Memori menjadi terjemahan dua tingkat GVA→GPA→SPA, dan tingkat kedua ditangani di perangkat keras oleh SLAT (EPT/RVI). Hyper-V terkini mensyaratkan SLAT.⁴
I/O perangkat didominasi oleh jalur perangkat sintetis VSC→VMBus→VSP, dan performa juga bergantung pada tumpukan I/O sisi host.²
Di Windows 11, karena VBS diaktifkan secara bawaan pada perangkat yang memenuhi syarat seperti instalasi bersih, tidak aneh hypervisor berjalan bahkan di PC yang tidak pernah memakai VM.¹ Anda dapat mengonfirmasi keadaan berjalan dengan HypervisorPresent dan systeminfo.

Gambaran besar Bagian 1 memadat ke diagram satu ini.

flowchart TB
    accTitle: Gambaran besar Bagian 1
    accDescr: Hypervisor duduk di bawah root partition dan child partition; CPU dialokasikan dengan menjadwalkan prosesor virtual (VM Exit hanya pada intercept dan exception yang dikonfigurasi), memori ditengahi terjemahan SLAT dua tingkat, I/O perangkat sintetis diteruskan lewat VMBus dan ditangani VSP root partition, dan perangkat teremulasi serta Discrete Device Assignment punya jalur lain
    up["Root + child partition"] --> hvS["Hypervisor"]
    hvS --> cpuS["CPU: jadwalkan VP"]
    hvS --> memS["Memori: SLAT"]
    cpuS -.-> cpuN["VM Exit pada intercept"]
    memS -.-> memN["Terjemahan dua tingkat"]
    memS ~~~ devS
    devS["Perangkat: I/O VMBus"] --> vspS["VSP sisi root menangani"]
    devS -.-> devN["Teremulasi / DDA: lain"]

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

Bersambung di Bagian 2, “Memori yang bahkan kernel pun tidak bisa lihat — VBS, HVCI, dan Credential Guard“.

Kita mengambil benang merah artikel ini — bahwa hypervisor menahan tabel terjemahan SLAT — dan mengikuti bagaimana Windows membuat “memori yang tidak dapat dibaca administrator maupun kernel”.

Area konsultasi terkait

KomuraSoft LLC menangani desain lingkungan validasi untuk aplikasi Windows, investigasi performa di lingkungan tervirtualisasi, dan analisis masalah kompatibilitas driver serta periferal.

Tautan referensi

Microsoft Learn, Silicon assisted security. Tentang VBS yang memakai virtualisasi perangkat keras untuk mengisolasi Secure Kernel dari OS biasa, dan tentang VBS serta HVCI yang diaktifkan secara bawaan pada perangkat yang memenuhi prasyarat pada instalasi baru Windows 11. ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. Tentang hypervisor yang menyediakan partisi sebagai satuan isolasi; root partition yang membuat child partition lewat hypercall API; partisi yang berjalan di ruang memori virtual privat tanpa akses langsung ke prosesor fisik; peran VMBus, VSP, VSC, dan Enlightened I/O; serta ekstensi virtualisasi perangkat keras (Intel VT/AMD-V) yang disyaratkan. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). Tentang Hyper-V sebagai hypervisor Tipe 1, root partition yang memiliki perangkat I/O fisik, dan VMBus yang menyediakan komunikasi antarpartisi berkinerja tinggi yang memakai memori bersama. ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. Tentang prosesor 64-bit yang mampu SLAT dan VM Monitor Mode Extensions yang disyaratkan; kemampuan mengonfirmasi bahwa syarat terpenuhi di bidang “Hyper-V Requirements” systeminfo; “A hypervisor has been detected” yang ditampilkan sementara hypervisor berjalan; dan Discrete Device Assignment yang dapat menugaskan perangkat tertentu langsung ke child partition. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. Tentang VMMS (Virtual Machine Management Service) yang mengelola keadaan VM di child partition, dan proses worker (VMWP) yang start di mode pengguna di root partition untuk setiap VM. ↩
Microsoft Learn, Comparing WSL Versions. Tentang WSL2 yang menjalankan kernel Linux sungguhan di dalam utility VM yang ringan, dan tentang peringatan memakainya bersama VMware dan VirtualBox terkini. ↩
Microsoft Learn, Windows Sandbox architecture. Tentang Windows Sandbox sebagai lingkungan Windows ringan yang menggabungkan teknologi kontainer dengan isolasi oleh hypervisor. ↩
Microsoft Learn, Windows Hypervisor Platform. Tentang API mode pengguna yang disediakan agar tumpukan virtualisasi pihak ketiga dapat membuat dan mengelola partisi di atas Windows hypervisor. ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. Tentang dapat mengonfirmasi keadaan berjalan VBS (virtual secure mode) lewat VirtualizationBasedSecurityStatus pada kelas Win32_DeviceGuard. ↩
Microsoft Learn, Install Hyper-V. Tentang Hyper-V yang dapat diaktifkan di Windows 10/11 Pro atau Enterprise dan sejenisnya, dan tidak dapat diinstal di edisi Home. ↩

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

Kedalaman virtualisasi Windows (Bagian 3) — Mesin virtual yang boot dalam hitungan detik: mengapa WSL2, Windows Sandbox, dan kontainer begitu ringan

Mengapa WSL2 dan Windows Sandbox start dalam hitungan detik dan terasa begitu ringan? Artikel ini menjelaskan mekanismenya, dari dynamic ...

Baca artikel

Kedalaman virtualisasi Windows (Bagian 2) — Memori yang bahkan kernel pun tidak bisa lihat: cara kerja VBS, HVCI, dan Credential Guard

Pada instalasi bersih ke perangkat keras yang kompatibel, VBS diaktifkan secara bawaan dan memakai hypervisor serta SLAT untuk membuat is...

Baca artikel

Topik terkait

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

Topik teknis Windows

Portal tentang pengembangan Windows, investigasi bug, dan pemanfaatan aset yang ada.

Lihat topik

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pengembangan aplikasi Windows

Aplikasi bisnis, integrasi perangkat, dan alat komunikasi, dari kebutuhan hingga pengembangan.

Lihat layanan Hubungi kami

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Ketika Anda mengaktifkan Hyper-V, di mana Windows host sebenarnya berjalan?: Hypervisor mengambil kendali langsung atas cara CPU fisik dan memori dialokasikan, dan Windows host berjalan di dalam partisi khusus yang disebut root partition. Kendali perangkat fisik biasanya ditangani oleh driver di sisi root partition. Root partition menahan driver perangkat dan tumpukan manajemen virtualisasi, tetapi kepemilikan CPU fisik milik hypervisor.
Apakah "Virtualization: Enabled" di Task Manager berarti Hyper-V sedang berjalan?: Tidak. Tampilan itu menunjukkan apakah ekstensi virtualisasi CPU (Intel VT-x/AMD-V) diaktifkan di firmware. Untuk melihat apakah hypervisor benar-benar berjalan, cari "A hypervisor has been detected" di systeminfo, atau periksa Win32_ComputerSystem.HypervisorPresent.
Mengapa hypervisor berjalan padahal saya tidak pernah membuat VM?: Di Windows 11, virtualization-based security (VBS) diaktifkan secara bawaan pada perangkat yang memenuhi syarat — misalnya instalasi bersih pada perangkat keras yang kompatibel — dan VBS dibangun di atas Windows hypervisor. Hal yang sama berlaku jika Anda memakai WSL2 atau Windows Sandbox. Tidak aneh hypervisor berjalan tanpa hubungan dengan siapa pun yang memakai VM.
Apa itu SLAT, dan mengapa ia wajib untuk Hyper-V?: SLAT (Second Level Address Translation) adalah mekanisme yang dipakai CPU untuk menerjemahkan alamat fisik tamu menjadi alamat fisik sungguhan; Intel EPT dan AMD RVI adalah implementasinya. Tanpanya hypervisor harus merawat tabel terjemahan di perangkat lunak, yang tidak realistis dari sudut performa, jadi Hyper-V terkini memperlakukannya sebagai syarat keras.
Jika saya mengaktifkan Hyper-V, apakah VirtualBox dan VMware berhenti bekerja?: Karena hypervisor memakai ekstensi virtualisasi CPU secara eksklusif, hypervisor pihak ketiga tidak dapat berjalan dengan cara tradisional. VirtualBox dan VMware terkini, namun, punya mode yang berjalan di atas Windows hypervisor (lewat Windows Hypervisor Platform), jadi versi terbaru masing-masing dapat 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.

Lihat profil Hubungi kami

Tautan publik

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Kembali ke blog