เมื่อเปิด Hyper-V แล้ว Windows ฝั่งโฮสต์รันอยู่ที่ไหนจริง ๆ

hypervisor ควบคุมโดยตรงว่า CPU จริงและหน่วยความจำถูกจัดสรรอย่างไร และ Windows ฝั่งโฮสต์รันในพาร์ติชันพิเศษที่เรียกว่า root partition การควบคุมอุปกรณ์จริงโดยปกติจัดการด้วยไดรเวอร์ฝั่ง root partition root partition ถือไดรเวอร์อุปกรณ์และสแต็กจัดการการจำลองเสมือน แต่ความเป็นเจ้าของ CPU จริงเป็นของ hypervisor

คำว่า "Virtualization: Enabled" ใน Task Manager หมายความว่า Hyper-V กำลังรันอยู่หรือไม่

ไม่ การแสดงนั้นบอกว่าส่วนขยายการจำลองเสมือนของ CPU (Intel VT-x/AMD-V) ถูกเปิดในเฟิร์มแวร์หรือไม่ หากจะดูว่า hypervisor กำลังรันจริงหรือไม่ ให้ดู "A hypervisor has been detected" ใน systeminfo หรือตรวจ Win32_ComputerSystem.HypervisorPresent

ทำไม hypervisor ถึงรันอยู่ทั้งที่ฉันไม่เคยสร้าง VM

บน Windows 11 ความปลอดภัยบนฐานการจำลองเสมือน (VBS) เปิดตามค่าเริ่มต้นบนอุปกรณ์ที่เข้าเงื่อนไข — เช่น การติดตั้งใหม่บนฮาร์ดแวร์ที่รองรับ — และ VBS สร้างบน Windows hypervisor เช่นเดียวกันหากคุณใช้ WSL2 หรือ Windows Sandbox จึงไม่แปลกที่ hypervisor จะรันโดยไม่เกี่ยวกับใครใช้ VM

SLAT คืออะไร และทำไม Hyper-V จึงต้องการ

SLAT (Second Level Address Translation) คือกลไกที่ CPU แปลที่อยู่จริงของเกสต์เป็นที่อยู่จริงแท้ Intel EPT และ AMD RVI คือการอิมพลีเมนต์ หากไม่มี hypervisor จะต้องรักษาตารางการแปลในซอฟต์แวร์ ซึ่งไม่สมจริงจากมุมมองประสิทธิภาพ ดังนั้น Hyper-V ปัจจุบันถือว่าเป็นข้อกำหนดแข็ง

หากเปิด Hyper-V แล้ว VirtualBox และ VMware จะหยุดทำงานหรือไม่

เพราะ hypervisor ใช้ส่วนขยายการจำลองเสมือนของ CPU แบบเฉพาะ hypervisor ของบุคคลที่สามจึงรันแบบดั้งเดิมไม่ได้ อย่างไรก็ตาม VirtualBox และ VMware ปัจจุบันมีโหมดที่รันบน Windows hypervisor (ผ่าน Windows Hypervisor Platform) ดังนั้นรุ่นล่าสุดของแต่ละตัวสามารถอยู่ร่วมกันได้

เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 1) — Windows ของคุณรันอยู่ที่ไหนจริง ๆ? Hypervisor และพาร์ติชัน

22 Aug 2026 02:00 · Go Komura · Windows, การจำลองเสมือน, Hyper-V, Hypervisor, SLAT, VMBus

เปิดข้อมูลระบบ (msinfo32) บน Windows 11 แล้วคุณมักเห็น “Running” ในช่อง “Virtualization-based security” — แม้บนเครื่องที่คุณไม่เคยสร้าง VM

ความหมายคือข้อเท็จจริงต่อไปนี้ บนเครื่องนั้น Windows ฝั่งโฮสต์เองกำลังรันอยู่บน hypervisor แล้ว “การจำลองเสมือน” ไม่ใช่เทคโนโลยีเฉพาะคนที่สร้าง VM ใน Hyper-V Manager อีกต่อไป บน Windows 11 ความปลอดภัยบนฐานการจำลองเสมือน (VBS) เปิดตามค่าเริ่มต้นในการตั้งค่าที่เข้าเงื่อนไข — เช่น การติดตั้งใหม่บนฮาร์ดแวร์ที่รองรับ¹ — และทั้ง WSL2 กับ Windows Sandbox สร้างบน Windows hypervisor เดียวกัน ใต้ Windows ที่คุณใช้ทุกวัน มีชั้นซอฟต์แวร์อีกชั้นหนึ่งอยู่แล้ว

ซีรีส์นี้ “เชิงลึกของการจำลองเสมือนบน Windows” ตามสิ่งที่เกิดขึ้นในชั้นนั้น เริ่มจากรากฐาน

“เชิงลึกของการจำลองเสมือนบน Windows” — ทั้ง 3 ตอน

ตอนที่ 1 (บทความนี้): Hypervisor และพาร์ติชัน
เราตามว่า Windows ฝั่งโฮสต์ไปรันอยู่ที่ไหนเมื่อคุณเปิด Hyper-V
ตอนที่ 2: หน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็น — VBS, HVCI และ Credential Guard
เราตามว่า Windows วางความลับที่ทั้งผู้ดูแลระบบและเคอร์เนลอ่านไม่ได้ไว้ที่ไหน
ตอนที่ 3: เครื่องเสมือนที่บูตในไม่กี่วินาที — WSL2, Windows Sandbox และคอนเทนเนอร์
เราตามจากวิธีที่หน่วยความจำและอิมเมจถูกใช้ร่วมกัน ว่าทำไม WSL2 และ Sandbox จึงเบาทั้งที่ VM เต็มตัวหนัก

คำถามที่ตอนที่ 1 ตอบมีเพียงข้อเดียว

เมื่อเปิด Hyper-V แล้ว Windows ฝั่งโฮสต์ไปรันอยู่ที่ไหน?

ผู้อ่านที่ตั้งใจ คือนักพัฒนาและผู้ปฏิบัติการที่ใช้ Hyper-V, WSL2 หรือ Windows Sandbox และอยากเข้าใจจากกลไกขึ้นมาว่าอะไรกำลังรันอยู่ข้างใต้ ข้อกำหนดเบื้องต้น คือ x64 Windows 10/11 หรือ Windows Server รุ่นปัจจุบัน (การพูดถึงริง VT-x/AMD-V และ EPT/RVI ในบทความนี้สมมติ x64 ส่วน Arm64 ใช้กลไกอื่น เช่น exception level) พื้นความรู้ที่ต้องมี คือความต่างระหว่างเคอร์เนลโหมดกับยูสเซอร์โหมด คุณไม่ต้องมีประสบการณ์ปฏิบัติการ VM หรือความรู้การพัฒนา hypervisor ความยากคือระดับกลาง เราครอบคลุมแนวคิดส่วนขยายการจำลองเสมือนของ CPU แต่ไม่ลงรายละเอียดชุดคำสั่ง

1. สรุปก่อนเลย

เมื่อคนได้ยิน Hyper-V อาจนึกภาพ “ซอฟต์แวร์รัน VM ที่นั่งอยู่บน Windows” โครงสร้างจริงกลับด้าน

ตั้งแต่วินาทีที่คุณเปิด Hyper-V แล้วรีบูต hypervisor คือผู้ควบคุม CPU จริงและหน่วยความจำ และ Windows ฝั่งโฮสต์รันอยู่บนนั้นในฐานะพาร์ติชันแรกที่มีสิทธิ์ — “root partition”

hypervisor คือชั้นซอฟต์แวร์บางที่นั่งระหว่างฮาร์ดแวร์กับ OS สร้างสภาพแวดล้อมการรันที่แยกกันเรียกว่า “พาร์ติชัน” และเป็นตัวกลางในการเข้าถึงฮาร์ดแวร์² อันที่ Windows ฝั่งโฮสต์เข้าไปคือ root partition อันที่ VM เข้าไปคือ child partition root partition ถูกปฏิบัติพิเศษ (เข้าถึงอุปกรณ์จริงโดยตรงและถือสแต็กจัดการ) แต่ในแง่ที่มันไม่ควบคุม CPU จริงโดยตรง มันยืนอยู่ในตำแหน่งเดียวกับ child partition

flowchart TB
    accTitle: โครงสร้างรวมหลังเปิด Hyper-V
    accDescr: hypervisor นั่งตรงบนฮาร์ดแวร์จริง และเหนือนั้นคือ root partition ที่ถือ Windows ฝั่งโฮสต์กับ child partition ที่ถือ VM
    hw["ฮาร์ดแวร์จริง"] --> hv["Hypervisor"]
    hv --> root["Root partition （Windows โฮสต์）"]
    hv --> child1["Child partition （VM）"]
    root -.-> stack["ถือสแต็กจัดการและไดรเวอร์อุปกรณ์"]

ภาพ 1: Hyper-V ไม่ใช่ “ซอฟต์แวร์ VM บน Windows” แต่เป็นชั้นที่ไปอยู่ใต้ Windows และ OS ฝั่งโฮสต์เองรันใน root partition

คุณอาจคิดว่า “ถ้าเปิดแล้วไม่รู้สึกต่าง มีการพลิกกลับครั้งใหญ่แบบนั้นจริงหรือ” มี นั่นแหละคือเหตุที่โครงสร้างนี้มักไม่ถูกสังเกต ในบทความนี้เราแยกแผนภาพเดียวนี้ตามสามแกน: CPU หน่วยความจำ และ I/O อุปกรณ์

2. จากฝั่ง CPU — สิทธิ์อีกชั้นใต้ริง

2.1. ทบทวนการป้องกันแบบริง

CPU x64 มีระดับสิทธิ์ (ริง) และ Windows รันเคอร์เนลโหมดที่ริง 0 และยูสเซอร์โหมดที่ริง 3 แอปพลิเคชันแตะฮาร์ดแวร์โดยตรงไม่ได้เพราะคำสั่งที่มีสิทธิ์รันจากริง 3 ไม่ได้

แล้วคุณจะบรรจุเคอร์เนล OS หลายตัว ซึ่งแต่ละตัวรันที่ริง 0 บน CPU จริงตัวเดียวกันอย่างปลอดภัยได้อย่างไร ทุกเคอร์เนลถูกเขียนโดยสมมติว่า “ฉันควบคุม CPU” ให้ริง 0 แก่ทั้งหมดแล้วพวกมันชนوكกัน ยึดไว้แล้วพวกมันจะไม่รัน

flowchart TB
    accTitle: ปัญหาที่เคอร์เนล OS หลายตัวต้องการริง 0
    accDescr: ทั้งเคอร์เนลโฮสต์และเกสต์ถูกเขียนโดยสมมติอำนาจเต็มที่ริง 0 ดังนั้นบันไดริงแบบดั้งเดิมเพียงอย่างเดียวบรรจุพวกมันบน CPU จริงตัวเดียวกันอย่างปลอดภัยไม่ได้
    k1["เคอร์เนลโฮสต์ （สมมติริง 0）"] --> want["ต้องการควบคุม CPU จริง"]
    k2["เคอร์เนลเกสต์ （สมมติริง 0）"] --> want
    want --> conflict["ริงแบบดั้งเดิมไกล่เกลี่ยไม่ได้"]
    conflict --> need["ต้องการตัวกลางเหนือริง 0"]

ภาพ 2: บันไดริงถูกสร้างโดยสมมติ OS เดียว ดังนั้นการบรรจุหลายเคอร์เนลต้องการสิทธิ์อีกชั้นเหนือนั้น

2.2. ส่วนขยายการจำลองเสมือน — โหมดสงวนไว้ให้ hypervisor

สิ่งที่แก้ปัญหานี้คือส่วนขยายการจำลองเสมือนของ CPU (Intel VT-x/AMD-V) Hyper-V ต้องการโปรเซสเซอร์ที่มีคุณสมบัตินี้² ส่วนขยายการจำลองเสมือนเพิ่ม บนแกนแยกจากริงแบบดั้งเดิม “โหมดการรันสำหรับ hypervisor” และ “โหมดการรันสำหรับเกสต์” เป็นสิทธิ์ที่แข็งกว่าแม้แต่ริง 0 บางครั้งมีชื่อเล่นว่า “ริง -1”

เคอร์เนลเกสต์ยังรันที่ริง 0 ตามเดิม ไม่ต้องเขียนใหม่
อย่างไรก็ตาม ริง 0 นั้นคือ “ริง 0 ในโหมดเกสต์” และมันไม่ควบคุม CPU จริงทั้งก้อน
เมื่อเกสต์เจอการทำงานเฉพาะที่ต้องการการแทรกของ hypervisor (คำสั่งที่ตั้งเป็น intercept หรือข้อยกเว้นหรือการละเมิด) CPU โอนการควบคุมไปยัง hypervisor อัตโนมัติ (VM Exit) เมื่อ hypervisor จัดการเสร็จ มันกลับสู่เกสต์ (VM Entry) การเข้าถึงหน่วยความจำปกติผ่านโดยไม่มี VM Exit ตราบที่การแปล SLAT สำเร็จ

อินเทอร์รัปต์ทำงานแบบเดียวกัน พาร์ติชันไม่แตะโปรเซสเซอร์จริงโดยตรง hypervisor รับอินเทอร์รัปต์และส่งไปยังแต่ละพาร์ติชัน²

flowchart TB
    accTitle: ลำดับการรันของเกสต์และ VM Exit
    accDescr: เคอร์เนลเกสต์และแอปรันที่ริง 0 และริง 3 ในโหมดเกสต์ การเข้าถึงหน่วยความจำปกติผ่านการแปล SLAT ส่วน intercept และข้อยกเว้นที่ตั้งไว้ก่อ VM Exit ที่โอนการควบคุมไปยัง hypervisor ซึ่งจากนั้นกลับสู่เกสต์ผ่าน VM Entry
    guest["รันในโหมดเกสต์ （รวมเคอร์เนลริง 0）"] --> op{"งานที่ต้องแทรก? （intercept/ข้อยกเว้นที่ตั้ง）"}
    op -->|ไม่| cont["รันต่อไปตามเดิม"]
    op -->|ใช่| exitEv["VM Exit （CPU โอนการควบคุม）"]
    exitEv --> hvp["Hypervisor จัดการ"]
    hvp --> entry["กลับสู่เกสต์ผ่าน VM Entry"]
    entry --> guest

ภาพ 3: OS เกสต์ยังรันที่ริง 0 โดยไม่ต้องเขียนใหม่ และ CPU เรียก hypervisor เฉพาะเมื่อจำเป็น

การไปกลับนี้ดูคล้ายลำดับที่เราตามในซีรีส์หน่วยความจำ — “เข้าเคอร์เนลเมื่อ page fault แล้วกลับสู่คำสั่งเดิม” CPU สกัดการควบคุมผ่านกลไกข้อยกเว้นหรือการเปลี่ยนสถานะ ให้ผู้จัดการระดับสูงตัดสิน แล้วกลับ ในเชิงลึกของ Windows รูปนี้ปรากฏซ้ำแล้วซ้ำอีก

2.3. Type 1 และ Type 2 — ความต่างอยู่ที่ตำแหน่งที่นั่ง

hypervisor แบ่งกว้าง ๆ เป็น Type 1 (bare-metal) ซึ่งรันตรงบนฮาร์ดแวร์ และ Type 2 (hosted) ซึ่งรันบน OS โฮสต์ Hyper-V คือ Type 1³ VirtualBox และ VMware Workstation (เมื่อรันเดี่ยว) ถูกจัดเป็น Type 2

เมื่อได้ยิน Type 1 คนมักนึกภาพ “การตั้งค่าเฉพาะเซิร์ฟเวอร์ที่ไม่มี OS โฮสต์” แต่ Hyper-V ต่าง Windows ฝั่งโฮสต์ไม่หายไป — มัน “ย้ายบ้าน” เข้า root partition เมื่อคุณเปิด Hyper-V แล้วรีบูต hypervisor เริ่มก่อนระหว่างบูต และ Windows ฝั่งโฮสต์จึงขึ้นมาเป็น root partition บนนั้น

flowchart TB
    accTitle: ความต่างระหว่าง hypervisor Type 1 กับ Type 2
    accDescr: ใน Type 2 OS โฮสต์นั่งบนฮาร์ดแวร์ และ hypervisor กับ VM นั่งบน OS โฮสต์ ส่วนใน Type 1 Hyper-V hypervisor นั่งตรงบนฮาร์ดแวร์ และ OS โฮสต์เองเข้าไปใน root partition เหนือนั้น
    subgraph t2 ["Type 2 （hosted）"]
        hw2["ฮาร์ดแวร์"] --> hostos["OS โฮสต์"]
        hostos --> hv2["Hypervisor"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Type 1 （Hyper-V）"]
        hw1["ฮาร์ดแวร์"] --> hv1["Hypervisor"]
        hv1 --> root1["Root partition （OS โฮสต์）"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

ภาพ 4: ใน Type 2 hypervisor นั่งบน OS โฮสต์ ส่วนใน Type 1 Hyper-V ลำดับกลับด้านและ OS โฮสต์เองนั่งบนชั้นที่ต่ำลงหนึ่งขั้น

มองบนไทม์ไลน์การบูต การเปลี่ยนแปลงที่เกิดเมื่อคุณเปิดมีลักษณะดังนี้

flowchart TB
    accTitle: ลำดับบูตหลังเปิด Hyper-V
    accDescr: หลังเปิดเครื่อง hypervisor เริ่มก่อนระหว่างบูต จากนั้น Windows ฝั่งโฮสต์ขึ้นมาเป็น root partition บนนั้น และ VM, VBS เป็นต้นเริ่มหลังจากนั้น
    poweron["เปิดเครื่องและเริ่มบูต"] --> bhv["Hypervisor เริ่มก่อน"]
    bhv --> broot["Windows โฮสต์เริ่มเป็น root partition"]
    broot --> blater["VM, VBS, WSL2 เป็นต้นเริ่มบนนั้น"]
    broot -.-> feel["ประสบการณ์ผู้ใช้ไม่เปลี่ยน"]

ภาพ 5: การพลิกลำดับจบแล้วก่อนหน้าจอลงชื่อเข้าใช้ปรากฏ และ OS โฮสต์ขึ้นมาบน hypervisor ตั้งแต่ต้น

3. พาร์ติชัน — หน่วยของการแยก

3.1. บทบาทที่มีเฉพาะ root partition

พาร์ติชันคือหน่วยตรรกะของการแยกที่ hypervisor จัดให้² แต่ไม่ใช่ทุกพาร์ติชันเท่ากัน มีสิ่งที่มีเฉพาะ root partition

การเข้าถึงอุปกรณ์จริงโดยตรง ไดรเวอร์อุปกรณ์สำหรับดิสก์ NIC GPU เป็นต้น อยู่ใน Windows ใน root partition ไม่ใช่ใน hypervisor Hyper-V บน Windows Server มีการตั้งค่าที่กำหนดอุปกรณ์ PCIe เฉพาะให้ child partition โดยตรง (Discrete Device Assignment) ในกรณีนั้น root ปล่อยอุปกรณ์นั้น (ไม่มีบน Windows ฝั่งไคลเอนต์)⁴
สแต็กจัดการการจำลองเสมือน VMMS (Virtual Machine Management Service) ซึ่งกำกับสร้าง เริ่ม และหยุด VM และโปรเซสเวิร์กเกอร์ราย VM (vmwp.exe) รันในยูสเซอร์โหมดใน root partition⁵ สิ่งเหล่านี้เป็นส่วนของฟีเจอร์จัดการ VM ของ Hyper-V จึงอาจไม่มีบนโฮสต์ที่ hypervisor รันเพียงเพื่อ VBS หรือ WSL2
สิทธิ์สร้าง child partition root partition สร้าง child partition ผ่าน hypercall API (อินเทอร์เฟซเรียกเข้า hypervisor)²

การออกแบบนี้มีเหตุผล หากคุณใส่ไดรเวอร์อุปกรณ์ทุกตัวเข้า hypervisor เอง hypervisor จะใหญ่ขึ้น และจำนวนบั๊กกับจุดเข้าโจมตีจะโต hypervisor จำกัดตนเองที่งานน้อยที่สุดคือการเป็นตัวกลางของ CPU และหน่วยความจำ และปล่อยการดูแลอุปกรณ์ให้ Windows ใน root partition การแบ่งบทบาทนี้คือสิ่งที่ทำให้ Hyper-V บาง

flowchart TB
    accTitle: การแบ่งบทบาทระหว่าง root partition กับ child partition
    accDescr: root partition ถือสแต็กจัดการการจำลองเสมือนและไดรเวอร์อุปกรณ์จริง และสร้าง child partition ผ่าน hypercall child partition โดยปกติเห็นเฉพาะอุปกรณ์เสมือน และภายใต้ Discrete Device Assignment บน Windows Server จะเข้าถึงอุปกรณ์ที่ถูกกำหนดโดยตรง
    subgraph rootp ["Root partition"]
        vmms["VMMS และโปรเซสเวิร์กเกอร์"]
        drv["ไดรเวอร์อุปกรณ์จริง"]
    end
    subgraph childp ["Child partition"]
        gos["OS เกสต์"]
        vdev["ในการตั้งค่าปกติ เห็นเฉพาะอุปกรณ์เสมือน"]
    end
    vmms -->|สร้างและจัดการผ่าน hypercall| childp
    hv2["Hypervisor （จำกัดที่ตัวกลาง CPU และหน่วยความจำ）"] --- rootp
    hv2 --- childp

ภาพ 6: การวางไดรเวอร์อุปกรณ์และสแต็กจัดการฝั่ง root partition คือสิ่งที่ทำให้ hypervisor เองบาง

3.2. โลกตามที่เห็นจาก child partition

OS เกสต์ใน child partition มองไม่เห็นฮาร์ดแวร์จริงโดยตรงในการตั้งค่าอุปกรณ์เสมือนปกติ (ข้อยกเว้นเดียวคืออุปกรณ์ที่กำหนดผ่าน Discrete Device Assignment บน Windows Server ตามที่อธิบายในส่วนก่อน) สิ่งที่มันเห็นคือโปรเซสเซอร์เสมือน พื้นที่หน่วยความจำที่ดูเหมือนเป็นของตนเอง และอุปกรณ์เสมือน คำขอไปยังอุปกรณ์เสมือนถูกส่งต่อไปยัง root partition ผ่าน VMBus หรือ hypervisor² ในทางกลับกัน การจัดสรรเวลา CPU และการแปลหน่วยความจำผ่าน SLAT จัดการโดย hypervisor โดยตรงโดยไม่ผ่าน root สิ่งที่ root เป็นตัวกลางคือ I/O อุปกรณ์ ไม่ใช่ทรัพยากรจริงทุกอย่าง

flowchart TB
    accTitle: โลกตามที่เห็นจาก child partition
    accDescr: สิ่งที่ OS เกสต์เห็นคือโปรเซสเซอร์เสมือน พื้นที่หน่วยความจำส่วนตัวของพาร์ติชัน และอุปกรณ์เสมือน คำขอไปยังอุปกรณ์เสมือนถูกส่งต่อไปยัง root partition ผ่าน VMBus เป็นต้น เวลา CPU และการแปลหน่วยความจำจัดการโดย hypervisor โดยตรง และในการตั้งค่า Discrete Device Assignment บน Windows Server เฉพาะอุปกรณ์ที่ถูกกำหนดถูกเข้าถึงโดยตรง
    gos2["OS เกสต์（child）"] --> vcpu["โปรเซสเซอร์เสมือน"]
    gos2 --> rest{"หน่วยความจำหรืออุปกรณ์?"}
    rest --> gpa2["พื้นที่หน่วยความจำส่วนตัว"]
    rest --> vdev2["อุปกรณ์เสมือน"]
    vdev2 --> rootx["ส่งต่อไปยัง root"]
    rootx -.-> vbus["ผ่าน VMBus เป็นต้น"]
    gos2 -.-> phys2["CPU จริง RAM อุปกรณ์"]
    phys2 -.-> hid["มองไม่เห็นโดยตรง"]
    phys2 -.-> dda2["DDA: อุปกรณ์ที่ถูกกำหนด"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

ภาพ 7: ในการตั้งค่าอุปกรณ์เสมือนปกติ ทุกอย่างที่เกสต์เห็นคือหน้าต่างเสมือน และเส้นทางสู่ของจริงผ่านตัวกลาง เฉพาะอุปกรณ์ที่กำหนดผ่าน DDA บน Windows Server คือข้อยกเว้น

สิ่งที่สำคัญที่นี่คือ สำหรับแอปที่รันบน Windows ฝั่งโฮสต์ โครงสร้างนี้เกือบโปร่งใส การเรียก Win32 API และการจัดการ page fault ยังถูกประมวลผลโดยเคอร์เนล Windows ใน root partition ตามเดิม hypervisor แทรกเฉพาะเมื่อเจอ intercept หรือข้อยกเว้นที่ตั้งไว้

4. จากฝั่งหน่วยความจำ — การแปลที่อยู่ได้ระดับอีกหนึ่งระดับ

4.1. ที่อยู่สามชนิด

ในตอนที่ 1 ของซีรีส์หน่วยความจำ เราตามลำดับที่ที่อยู่เสมือนถูกแปลผ่านตารางเพจเป็นที่อยู่จริง (“วินาทีที่ที่อยู่เสมือนกลายเป็น RAM จริง”) ในสภาพแวดล้อมจำลองเสมือนมีระดับอีกหนึ่งระดับถูกเพิ่มใต้การแปลนั้น และมีที่อยู่สามชนิด

ที่อยู่	ตัวย่อ	ผู้จัดการ
Guest virtual address	GVA	ตารางเพจของ OS เกสต์
Guest physical address	GPA	ที่อยู่ที่ OS เกสต์เชื่อว่าเป็น “จริง”
System physical address	SPA	Hypervisor (ตำแหน่งจริงใน RAM)

OS เกสต์แปล GVA เป็น GPA ด้วยตารางเพจของตนเอง อย่างไรก็ตาม GPA ที่เกสต์เห็นไม่ใช่ที่อยู่จริงแท้ แต่เป็นพื้นที่หน่วยความจำส่วนตัวที่อุทิศให้แต่ละพาร์ติชัน² การแมป GPA ลงตำแหน่งจริงใน RAM (SPA) คืองานของ hypervisor

4.2. SLAT — การแปลสองระดับในฮาร์ดแวร์

หากคุณทำการแปลระดับที่สองนี้ในซอฟต์แวร์อย่างเดียว hypervisor ต้องติดตามทุกการอัปเดตตารางเพจของเกสต์ทีละรายการ ซึ่งไม่สมจริงจากมุมมองประสิทธิภาพ ดังนั้น CPU จึงจัดกลไกที่เดินตารางการแปลระดับที่สองในฮาร์ดแวร์ นั่นคือ SLAT (Second Level Address Translation) Intel EPT (Extended Page Tables) และ AMD RVI คือการอิมพลีเมนต์ Hyper-V ปัจจุบันต้องการโปรเซสเซอร์ 64 บิตที่รองรับ SLAT⁴

flowchart TB
    accTitle: การแปลที่อยู่สองระดับผ่าน SLAT
    accDescr: ที่อยู่เสมือนของเกสต์ถูกแปลเป็นที่อยู่จริงของเกสต์โดยตารางเพจของ OS เกสต์ จากนั้นถูกแปลต่อเป็นที่อยู่จริงของระบบโดย SLAT ซึ่ง hypervisor จัดการ และถึง RAM จริง
    gva["ที่อยู่เสมือนเกสต์ （GVA）"] -->|ตารางเพจของ OS เกสต์| gpa["ที่อยู่จริงเกสต์ （GPA）"]
    gpa -->|"SLAT （ตารางแปล EPT/RVI）"| spa["ที่อยู่จริงระบบ （SPA）"]
    spa --> ram["RAM จริง"]
    gpa -.-> note["ชั้นที่เกสต์เพียงเชื่อว่าเป็นจริง"]

ภาพ 8: ตารางการแปลอีกตารางที่ hypervisor จัดการ นั่งใต้ตารางเพจของเกสต์ และ CPU เดินทั้งคู่ในฮาร์ดแวร์

SLAT ไม่ใช่คุณสมบัติที่มีอยู่เพียงเพื่อประสิทธิภาพการรัน VM VBS ที่เราจะเห็นในตอนที่ 2 ใช้คุณสมบัติที่ “คุณมีตารางแปล SLAT ต่างกันต่อระดับสิทธิ์” เป็นวัสดุสำหรับขอบเขตความปลอดภัย เหตุที่คุณสร้างหน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็นได้ คือเพราะ hypervisor ถือการแปลระดับที่สองนี้ นี่กลายเป็นเส้นผ่านของทั้งซีรีส์ ดังนั้นจำไว้ข้อเดียว: “เจ้าของตารางการแปลคือ hypervisor”

5. จากฝั่ง I/O อุปกรณ์ — VMBus และอุปกรณ์สองชนิด

5.1. ข้อจำกัดของอุปกรณ์จำลอง

วิธีคลาสสิกในการแสดงอุปกรณ์ให้ child partition คือการเลียนแบบฮาร์ดแวร์จริงทั้งก้อน (เช่น ตัวควบคุม IDE เก่า) ในซอฟต์แวร์ ความเข้ากันได้สูงเพราะไดรเวอร์ในกล่องของ OS เกสต์ทำงานตามเดิม แต่ VM Exit เกิดทุกครั้งที่เกสต์เจอพอร์ต I/O และประสิทธิภาพไม่ขยาย

flowchart TB
    accTitle: ทำไม I/O ไปยังอุปกรณ์จำลองจึงช้า
    accDescr: ทุกครั้งที่เกสต์ทำงานกับพอร์ต I/O การควบคุมโอนไปฝั่ง hypervisor ผ่าน VM Exit อุปกรณ์ถูกเลียนแบบในซอฟต์แวร์ และเกสต์ถูกส่งกลับ ดังนั้นการไปกลับวนซ้ำและช้า
    gio["เกสต์ทำงานกับพอร์ต I/O"] --> vex["เกิด VM Exit"]
    vex --> emu2["อุปกรณ์ถูกจำลองในซอฟต์แวร์"]
    emu2 --> back["กลับสู่เกสต์ผ่าน VM Entry"]
    back -->|วนซ้ำตอนทำงานพอร์ตถัดไป| gio

ภาพ 9: การไปกลับนี้รันหลายครั้งเบื้องหลังการเข้าถึงดิสก์ครั้งเดียว และราคาของความเข้ากันได้ถูกจ่ายด้วยประสิทธิภาพ

5.2. VMBus และ VSP/VSC — เส้นทางเร็วที่ออกแบบเพื่อการจำลองเสมือน

ดังนั้น Hyper-V จึงมีกลไก “อุปกรณ์สังเคราะห์” ที่ออกแบบโดยสมมติการจำลองเสมือน มีสามตัวละคร²

VMBus: ช่องสื่อสารตรรกะระหว่างพาร์ติชัน ให้การสื่อสารระหว่างพาร์ติชันความเร็วสูงที่ใช้หน่วยความจำร่วม³
VSP (Virtualization Service Provider): บริการที่อยู่ฝั่ง root partition รับคำขออุปกรณ์จาก child และเชื่อมไปยังสแต็กอุปกรณ์/แบ็กเอนด์ฝั่ง root คำขออาจถึงอุปกรณ์จริง หรือถูกจัดการโดยแบ็กเอนด์ฝั่งโฮสต์ เช่น ดิสก์เสมือนหรือสวิตช์เสมือน
VSC (Virtualization Service Consumer): ไดรเวอร์อุปกรณ์สังเคราะห์ที่เข้าไปใน OS เกสต์ฝั่ง child partition ส่งคำขอไปยัง VSP ผ่าน VMBus

เอาคำขอสตอเรจของ OS เกสต์เป็นตัวอย่าง ลำดับมีลักษณะดังนี้ WriteFile ของแอปเกสต์ลงสแต็ก I/O ของเคอร์เนลเกสต์ และที่ก้นสุด ถึง VSC (แทนฮาร์ดแวร์จริง) VSC วางคำขอบน VMBus และส่งให้ VSP ใน root partition และ VSP ไหลคำขอเข้าสแต็ก I/O ฝั่ง root ในการตั้งค่าดิสก์เสมือน (VHDX) การเขียนนี้ถูกจัดการเป็นการเขียนไปยังไฟล์ VHDX บนโฮสต์ และในที่สุดถึงดิสก์จริง แนวทางนี้เรียกว่า Enlightened I/O (I/O ที่รู้ตัวเรื่องการจำลองเสมือน) และเพิ่มประสิทธิภาพด้วยการข้ามชั้นจำลองอุปกรณ์²

flowchart TB
    accTitle: เส้นทาง I/O ของอุปกรณ์สังเคราะห์
    accDescr: คำขอ I/O จากแอปใน child partition ถึง VSC ผ่านเคอร์เนลเกสต์ ข้าม VMBus ไปยัง VSP ใน root partition และบนสแต็ก I/O ฝั่ง root ที่ VSP เชื่อมเข้าไป อาจถึงอุปกรณ์จริงผ่านไดรเวอร์อุปกรณ์จริง หรือถูกจัดการโดยแบ็กเอนด์ฝั่งโฮสต์ เช่น ดิสก์เสมือนหรือสวิตช์เสมือน
    app["แอปใน child partition"] --> gk["สแต็ก I/O ของเคอร์เนลเกสต์"]
    gk --> vsc["VSC （ไดรเวอร์อุปกรณ์สังเคราะห์）"]
    vsc -->|VMBus| vsp["VSP （ฝั่ง root partition）"]
    vsp --> rio["สแต็ก I/O ฝั่ง root"]
    rio --> pdrv["ไดรเวอร์อุปกรณ์จริง"]
    rio --> hb["แบ็กเอนด์ฝั่งโฮสต์ （ดิสก์เสมือน สวิตช์เสมือน เป็นต้น）"]
    pdrv --> dev["อุปกรณ์จริง"]

ภาพ 10: ด้วยอุปกรณ์สังเคราะห์ I/O ของเกสต์ข้ามไปยัง root partition ผ่าน VMBus และผ่านสแต็กฝั่ง root ถึงอุปกรณ์จริงหรือแบ็กเอนด์ฝั่งโฮสต์

กล่าวคือ ว่า I/O ดิสก์หรือเครือข่ายของ VM จะเร็วหรือไม่ ไม่ได้ขึ้นกับฝั่งเกสต์อย่างเดียว แต่ยังขึ้นกับสถานะของสแต็ก I/O และไดรเวอร์อุปกรณ์ฝั่ง root partition เหตุที่การสังเกตฝั่งโฮสต์ขาดไม่ได้เมื่อคุณสอบสวนปัญหาประสิทธิภาพของ VM คือเพราะเส้นทางจริงผ่านโฮสต์

flowchart TB
    accTitle: อุปกรณ์จำลองเทียบกับอุปกรณ์สังเคราะห์
    accDescr: อุปกรณ์จำลองเลียนแบบฮาร์ดแวร์จริงจึงให้ไดรเวอร์เกสต์ในกล่องทำงานแต่ช้า อุปกรณ์สังเคราะห์เป็นไดรเวอร์ที่สร้างเฉพาะโดยสมมติ VMBus และเร็ว
    dev2{"อุปกรณ์ที่แสดงให้ child partition"} --> emu["อุปกรณ์จำลอง"]
    dev2 --> syn["อุปกรณ์สังเคราะห์"]
    emu -.-> emuP["จำลองฮาร์ดแวร์จริง ความเข้ากันได้มาก่อน"]
    emuP -.-> emuC["ต้องแทรกทุก I/O ช้า"]
    syn -.-> synP["ออกแบบรอบ VMBus เร็ว"]
    synP -.-> synC["ต้องการไดรเวอร์ที่เข้ากันในเกสต์"]

ภาพ 11: ในอุปกรณ์เสมือนสองชนิด อุปกรณ์จำลองแบกความเข้ากันได้ทันทีหลังติดตั้ง OS และอุปกรณ์สังเคราะห์แบกประสิทธิภาพในการใช้ประจำวัน

6. ทำไมเรื่องนี้ไม่ใช่เรื่องของคนอื่น แม้คุณไม่เคยใช้ VM

โครงสร้างจนถึงตอนนี้อาจดูเหมือน “เรื่องสำหรับคนที่ยืน VM” อย่างไรก็ตาม ตามที่กล่าวตอนต้น บน Windows ปัจจุบัน hypervisor เป็นส่วนของชีวิตประจำวัน

ความปลอดภัยบนฐานการจำลองเสมือน (VBS) ใช้ Windows hypervisor สร้างสภาพแวดล้อมที่แยกและบรรจุฟีเจอร์ความปลอดภัยที่นั่น บน Windows 11 เปิดตามค่าเริ่มต้นเมื่อเข้าเงื่อนไข เช่น การติดตั้งใหม่บนฮาร์ดแวร์ที่รองรับ¹ รายละเอียดอยู่ในตอนที่ 2
WSL2 รันเคอร์เนล Linux จริงใน utility VM น้ำหนักเบา⁶
Windows Sandbox สภาพแวดล้อม Windows ใช้แล้วทิ้งที่แยกด้วย hypervisor⁷ ทั้งคู่ครอบคลุมในตอนที่ 3

flowchart TB
    accTitle: ฟีเจอร์ประจำวันที่นั่งบน hypervisor เดียวกัน
    accDescr: ไม่เพียง VM ของ Hyper-V แต่ยังมี VBS ซึ่งเปิดตามค่าเริ่มต้นบนอุปกรณ์ที่เข้าเงื่อนไข เช่น การติดตั้งใหม่ รวมถึง WSL2 และ Windows Sandbox ทั้งหมดสร้างบน Windows hypervisor เดียวกัน
    base["Windows hypervisor"] --> f1["VM ของ Hyper-V"]
    base --> f2["VBS （เปิดตามค่าเริ่มต้นตอนติดตั้งใหม่และคล้ายกัน）"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["เหตุที่รันแม้บนเครื่องที่ไม่เคยใช้ VM"]

ภาพ 12: มีรากฐานเดียว และแผนภาพนี้คือจุดที่สมมติฐาน “การจำลองเสมือนเป็นเรื่องของคนที่ใช้ VM” พัง

อีกเรื่องหนึ่งที่คนมักเหยียบในทางปฏิบัติคือ การอยู่ร่วมกับซอฟต์แวร์จำลองเสมือนของบุคคลที่สาม เพราะ hypervisor ใช้ส่วนขยายการจำลองเสมือนของ CPU แบบเฉพาะ ในสภาพแวดล้อมที่ Windows hypervisor กำลังรัน VirtualBox เป็นต้น รันแบบดั้งเดิมไม่ได้ (แบบที่ใช้ส่วนขยายการจำลองเสมือนของ CPU เอง) สำหรับเรื่องนี้ มี API สาธารณะชื่อ Windows Hypervisor Platform และสแต็กจำลองเสมือนของบุคคลที่สามสามารถรันโดยนั่งบน Windows hypervisor⁸ VirtualBox/VMware ปัจจุบันอยู่ร่วมกับ WSL2 ได้ด้วยกลไกนี้ แต่ความต่างด้านประสิทธิภาพและฟีเจอร์ที่มากับการสลับโหมดบางครั้งถูกสังเกตว่า “หลังเปิด Hyper-V (หรือ VBS) ซอฟต์แวร์จำลองเสมือนเริ่มทำงานต่างไป”

flowchart TB
    accTitle: ใครเป็นเจ้าของส่วนขยายการจำลองเสมือนของ CPU และเส้นทางของซอฟต์แวร์จำลองเสมือนบุคคลที่สาม
    accDescr: ขณะที่ Windows hypervisor กำลังรัน มันเป็นเจ้าของส่วนขยายการจำลองเสมือนของ CPU แบบเฉพาะ ซอฟต์แวร์จำลองเสมือนบุคคลที่สามที่รองรับ WHP รันบนนั้นผ่าน Windows Hypervisor Platform ส่วนการอิมพลีเมนต์ที่ไม่รองรับ WHP รันไม่ได้หรือถูกจำกัดฟีเจอร์
    vt["ส่วนขยายจำลองเสมือนของ CPU （VT-x/AMD-V）"] --> hvon{"Windows hypervisor กำลังรัน?"}
    hvon -->|ไม่| direct["ซอฟต์แวร์บุคคลที่สามใช้โดยตรงได้"]
    hvon -->|ใช่| own["hypervisor ใช้แบบเฉพาะ"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["ซอฟต์แวร์บุคคลที่สามที่รองรับ WHP รันบนนั้น"]
    third -.-> nowhp["การอิมพลีเมนต์ที่ไม่รองรับรันไม่ได้หรือถูกจำกัด"]

ภาพ 13: มีเจ้าของส่วนขยายการจำลองเสมือนเพียงหนึ่ง และซอฟต์แวร์บุคคลที่สามเดียวที่อยู่ร่วมได้ขณะที่ hypervisor กำลังรันคือซอฟต์แวร์ที่รองรับ API สาธารณะ (WHP)

7. ดูด้วยตนเอง

คุณยืนยันบนเครื่องของตนเองได้ว่า hypervisor กำลังรันหรือไม่

ก่อนอื่น การตรวจที่รันได้โดยไม่ต้องมีสิทธิ์ผู้ดูแลระบบ

# 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 คืนสถานะการรันของ VBS เป็นตัวเลข (2 คือ “Running”)⁹

ข้อควรระวังหนึ่ง HypervisorPresent บอกเพียง “เรากำลังรันบน hypervisor หรือไม่” ไม่แยกว่าเป็น root หรือ child หากคุณรันบน Windows ใน VM มันยังคืน True ในฐานะ child partition หากเป็น True บน Windows บนเครื่องจริง Windows นั้นอยู่ใน root partition — คุณอ่านร่วมกับสภาพแวดล้อมการรัน

ถัดไป ของคลาสสิกจาก Command Prompt

systeminfo

ดู “Hyper-V Requirements” ท้ายเอาต์พุต บนเครื่องที่ hypervisor ยังไม่รัน ข้อกำหนดแต่ละข้อ — การรองรับ SLAT ว่าส่วนขยายการจำลองเสมือนเปิดหรือไม่ เป็นต้น — ถูกแสดงรายการ บนเครื่องที่ hypervisor กำลังรันแล้ว แทนข้อกำหนดคุณได้บรรทัดเดียว: “A hypervisor has been detected. Features required for Hyper-V will not be displayed.”⁴ บรรทัดนั้นจึงเป็นข้อความว่า Windows ของคุณกำลังรันอยู่บน hypervisor บางตัว เช่นเดียวกับ HypervisorPresent คุณต้องอ่านว่า “ใน root partition” บนเครื่องจริง หรือ “ในฐานะ child partition” ใน VM

แม้ข้อกำหนดทุกข้อของ systeminfo เป็น “Yes” นั่นหมายความเพียงว่าฝั่งฮาร์ดแวร์พร้อม ฟีเจอร์ Hyper-V เองมีบนรุ่น Pro, Enterprise และ Education และไม่มีบน Home¹⁰

ใน GUI ให้ตรวจแถว “Virtualization-based security” ใต้ “System Summary” ใน msinfo32 โปรดทราบว่า “Virtualization: Enabled” ในแผง CPU ของ Task Manager แสดงเพียงว่าส่วนขยายการจำลองเสมือนเปิดในเฟิร์มแวร์หรือไม่ ซึ่งเป็นข้อมูลแยกจากว่า hypervisor กำลังรันหรือไม่

flowchart TB
    accTitle: วิธีตรวจว่า hypervisor กำลังรัน
    accDescr: หาก systeminfo บอกว่าตรวจพบ hypervisor คุณกำลังรันบน hypervisor （ใน root partition บนเครื่องจริง） หากรายการ Hyper-V Requirements ปรากฏ มันยังไม่รัน จึงตรวจทุกข้อกำหนด เช่น SLAT, VM Monitor Mode Extensions และ DEP แต่ Yes ทั้งหมดหมายถึงฝั่งฮาร์ดแวร์พร้อม และฟีเจอร์ Hyper-V ยังมีข้อกำหนดรุ่น
    start2["รัน systeminfo"] --> q1{"ช่องข้อกำหนด?"}
    q1 -->|Detected| running["Hypervisor กำลังรัน"]
    running -.-> runN["ใน root"]
    runN -.-> runN2["บนเครื่องจริง"]
    q1 -->|Listed| notyet["ยังไม่รัน"]
    notyet --> q2{"ข้อกำหนดทั้งหมด Yes?"}
    q2 -->|ทั้งหมด Yes| can["ฝั่งฮาร์ดแวร์พร้อม"]
    can -.-> ed["ต้องใช้ Pro / Ent / Edu"]
    q2 -->|บางข้อ No| uefi["ตรวจรายการ UEFI/BIOS"]

ภาพ 14: ช่อง “Hyper-V Requirements” ใน systeminfo ทำหน้าที่ทั้งตรวจสถานะการรันและตรวจข้อกำหนดเบื้องต้น

8. สามการอ่านผิดที่ควรเลี่ยงในทางปฏิบัติ

8.1. “เราไม่ได้เปิด Hyper-V ดังนั้นการจำลองเสมือนไม่เกี่ยวกับเครื่องของเรา”

แม้คุณไม่ได้เปิดฟีเจอร์ Hyper-V (เครื่องมือจัดการและสภาพแวดล้อมรัน VM) Windows hypervisor กำลังรันหาก VBS เปิด เมื่อคุณสอบสวนปัญหาความเข้ากันได้ของไดรเวอร์ การทดสอบประสิทธิภาพ หรือปัญหาซอฟต์แวร์จำลองเสมือนของบุคคลที่สาม ให้ตรวจ HypervisorPresent และสถานะการรันของ VBS — ไม่ใช่ว่าฟีเจอร์เปิดหรือไม่

8.2. “Task Manager บอก ‘Virtualization: Enabled’ ดังนั้น Hyper-V กำลังรัน”

การแสดงนั้นเกี่ยวกับการตั้งค่าเฟิร์มแวร์ (ว่า VT-x/AMD-V พร้อมใช้หรือไม่) ตัดสินสถานะการรันของ hypervisor จาก “A hypervisor has been detected” ใน systeminfo ในทางกลับกัน หาก Task Manager บอก “Disabled” คุณเปิด Hyper-V หรือ WSL2 ก็ไม่ได้เช่นกัน จึงตรวจการตั้งค่า UEFI/BIOS ก่อน

flowchart TB
    accTitle: สามการตรวจที่สับสนง่าย
    accDescr: ช่อง Virtualization ของ Task Manager แสดงการตั้งค่าเฟิร์มแวร์ รายการ Windows Features แสดงสถานะการติดตั้ง และ systeminfo หรือ HypervisorPresent แสดงสถานะการรัน แต่ละอันตอบคำถามคนละข้อ
    q3{"คำถามใด?"}
    q3 --> fw{"เฟิร์มแวร์หรือ Windows?"}
    q3 --> c3["hypervisor กำลังรัน?"]
    fw --> a3["ส่วนขยายเฟิร์มแวร์?"]
    fw --> b3["ฟีเจอร์ Hyper-V เปิด?"]
    a3 -.-> a3t["แผง CPU ของ Task Manager"]
    b3 -.-> b3t["UI ของ Windows Features"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

ภาพ 15: นี่คือสามคำถามอิสระ และการอนุมานอีกสองข้อจากการแสดงใดข้อหนึ่งคือการอ่านผิด

8.3. “หาก VM ช้า นั่นคือปัญหาของ OS เกสต์”

I/O ของอุปกรณ์สังเคราะห์ข้าม VMBus ไปยัง VSP ใน root partition และผ่านสแต็กอุปกรณ์/แบ็กเอนด์ฝั่ง root (ไดรเวอร์จริง บวกการประมวลผลสวิตช์เสมือนและดิสก์เสมือน) หากคุณดูเฉพาะตัวนับในเกสต์ คุณจะไม่พบคอขวดที่นั่งในสตอเรจฝั่งโฮสต์หรือ NIC หลักสำหรับปัญหาประสิทธิภาพของ VM คือสังเกตจากทั้งสองฝั่ง: เกสต์และโฮสต์ (root partition)

9. สรุป

เมื่อเปิด Hyper-V hypervisor รันตรงบนฮาร์ดแวร์ และ Windows ฝั่งโฮสต์รันเป็น root partition²
เคอร์เนล OS เกสต์ยังรันที่ริง 0 และเฉพาะงานที่ตั้งเป็น intercept บวกข้อยกเว้น ถูกส่งให้ hypervisor ผ่าน VM Exit การเข้าถึงหน่วยความจำปกติผ่านการแปล SLAT
มีเพียง root partition ที่ถือไดรเวอร์อุปกรณ์จริงและสแต็กจัดการการจำลองเสมือน และสร้าง child partition ผ่าน hypercall²
หน่วยความจำกลายเป็นการแปลสองระดับ GVA→GPA→SPA และระดับที่สองจัดการในฮาร์ดแวร์โดย SLAT (EPT/RVI) Hyper-V ปัจจุบันต้องการ SLAT⁴
I/O อุปกรณ์ถูกครอบด้วยเส้นทางอุปกรณ์สังเคราะห์ VSC→VMBus→VSP และประสิทธิภาพยังขึ้นกับสแต็ก I/O ฝั่งโฮสต์²
บน Windows 11 เพราะ VBS เปิดตามค่าเริ่มต้นบนอุปกรณ์ที่เข้าเงื่อนไข เช่น การติดตั้งใหม่ จึงไม่แปลกที่ hypervisor จะรันแม้บนเครื่องที่ไม่เคยใช้ VM¹ คุณยืนยันสถานะการรันด้วย HypervisorPresent และ systeminfo ได้

ภาพรวมของตอนที่ 1 ย่อลงในแผนภาพเดียวนี้

flowchart TB
    accTitle: ภาพรวมของตอนที่ 1
    accDescr: hypervisor นั่งใต้ root partition และ child partition CPU ถูกจัดสรรด้วยการจัดตารางโปรเซสเซอร์เสมือน （VM Exit เฉพาะตอน intercept และข้อยกเว้นที่ตั้ง） หน่วยความจำถูกเป็นตัวกลางด้วยการแปล SLAT สองระดับ I/O อุปกรณ์สังเคราะห์ถูกส่งต่อผ่าน VMBus และจัดการโดย VSP ของ root partition และอุปกรณ์จำลองกับ Discrete Device Assignment มีเส้นทางอื่น
    up["Root + child partition"] --> hvS["Hypervisor"]
    hvS --> cpuS["CPU: จัดตาราง VP"]
    hvS --> memS["หน่วยความจำ: SLAT"]
    cpuS -.-> cpuN["VM Exit ตอน intercept"]
    memS -.-> memN["การแปลสองระดับ"]
    memS ~~~ devS
    devS["อุปกรณ์: I/O ผ่าน VMBus"] --> vspS["VSP ฝั่ง root จัดการ"]
    devS -.-> devN["จำลอง / DDA: อื่น"]

ภาพ 16: การจัดตาราง CPU และการแปลหน่วยความจำจัดการโดย hypervisor โดยตรง (VM Exit เฉพาะตอนแทรก) และ I/O อุปกรณ์สังเคราะห์ถูกเป็นตัวกลางโดย root partition (VSP) ฝั่งไกลของ VMBus

ต่อในตอนที่ 2 “หน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็น — VBS, HVCI และ Credential Guard“

เราหยิบเส้นผ่านของบทความนี้ — ว่า hypervisor ถือตารางแปล SLAT — แล้วตามว่า Windows สร้าง “หน่วยความจำที่ทั้งผู้ดูแลระบบและเคอร์เนลอ่านไม่ได้” อย่างไร

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับออกแบบสภาพแวดล้อมตรวจสอบสำหรับแอปพลิเคชัน Windows การสอบสวนประสิทธิภาพในสภาพแวดล้อมจำลองเสมือน และการวิเคราะห์ปัญหาความเข้ากันได้ของไดรเวอร์และอุปกรณ์ต่อพ่วง

ลิงก์อ้างอิง

Microsoft Learn, Silicon assisted security. ว่าด้วย VBS ที่ใช้การจำลองเสมือนของฮาร์ดแวร์แยก Secure Kernel จาก OS ธรรมดา และว่า VBS กับ HVCI เปิดตามค่าเริ่มต้นบนอุปกรณ์ที่เข้าข้อกำหนดเบื้องต้นตอนติดตั้ง Windows 11 ใหม่ ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. ว่าด้วย hypervisor ที่จัดพาร์ติชันเป็นหน่วยของการแยก root partition ที่สร้าง child partition ผ่าน hypercall API พาร์ติชันที่รันในพื้นที่หน่วยความจำเสมือนส่วนตัวโดยไม่เข้าถึงโปรเซสเซอร์จริงโดยตรง บทบาทของ VMBus, VSP, VSC และ Enlightened I/O และส่วนขยายการจำลองเสมือนของฮาร์ดแวร์ (Intel VT/AMD-V) เป็นข้อกำหนด ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). ว่าด้วย Hyper-V เป็น hypervisor Type 1 root partition เป็นเจ้าของอุปกรณ์ I/O จริง และ VMBus ให้การสื่อสารระหว่างพาร์ติชันประสิทธิภาพสูงที่ใช้หน่วยความจำร่วม ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. ว่าด้วยโปรเซสเซอร์ 64 บิตที่รองรับ SLAT และ VM Monitor Mode Extensions เป็นข้อกำหนด ความสามารถยืนยันว่าเข้าข้อกำหนดในช่อง “Hyper-V Requirements” ของ systeminfo “A hypervisor has been detected” ถูกแสดงขณะที่ hypervisor กำลังรัน และ Discrete Device Assignment สามารถกำหนดอุปกรณ์เฉพาะให้ child partition โดยตรงได้ ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. ว่าด้วย VMMS (Virtual Machine Management Service) ที่จัดการสถานะของ VM ใน child partition และโปรเซสเวิร์กเกอร์ (VMWP) ที่เริ่มในยูสเซอร์โหมดใน root partition สำหรับแต่ละ VM ↩
Microsoft Learn, Comparing WSL Versions. ว่าด้วย WSL2 ที่รันเคอร์เนล Linux จริงใน utility VM น้ำหนักเบา และข้อควรระวังเรื่องการใช้ร่วมกับ VMware และ VirtualBox ปัจจุบัน ↩
Microsoft Learn, Windows Sandbox architecture. ว่าด้วย Windows Sandbox เป็นสภาพแวดล้อม Windows น้ำหนักเบาที่รวมเทคโนโลยีคอนเทนเนอร์กับการแยกโดย hypervisor ↩
Microsoft Learn, Windows Hypervisor Platform. ว่าด้วย API ยูสเซอร์โหมดที่จัดให้เพื่อให้สแต็กจำลองเสมือนของบุคคลที่สามสร้างและจัดการพาร์ติชันบน Windows hypervisor ได้ ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. ว่าด้วยการยืนยันสถานะการรันของ VBS (virtual secure mode) ผ่าน VirtualizationBasedSecurityStatus บนคลาส Win32_DeviceGuard ↩
Microsoft Learn, Install Hyper-V. ว่าด้วย Hyper-V เปิดได้บน Windows 10/11 Pro หรือ Enterprise เป็นต้น และติดตั้งบนรุ่น Home ไม่ได้ ↩

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 3) — เครื่องเสมือนที่บูตในไม่กี่วินาที: ทำไม WSL2, Windows Sandbox และคอนเทนเนอร์จึงเบา

ทำไม WSL2 และ Windows Sandbox จึงเริ่มในไม่กี่วินาทีและรู้สึกเบา? บทความนี้อธิบายกลไก ตั้งแต่ dynamic base image และ direct map ไปจนถึงกา...

อ่านบทความ

เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 2) — หน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็น: กลไกของ VBS, HVCI และ Credential Guard

เมื่อติดตั้งใหม่บนฮาร์ดแวร์ที่รองรับ VBS จะเปิดตามค่าเริ่มต้น และใช้ hypervisor กับ SLAT สร้างการแยกที่แข็งกว่าเคอร์เนล บทความนี้อธิบายโค...

อ่านบทความ

Win32 Thread Pool API — คอนเคอร์เรนซีโดยไม่สร้างเธรดเอง ด้วย CreateThreadpoolWork

โค้ดเนทีฟของคุณกระจายการเรียก CreateThread ไปทั่วหรือไม่ บทความนี้อธิบาย Win32 thread pool API ที่ออกแบบใหม่ใน Vista — ออบเจ็กต์สี่ชนิด w...

อ่านบทความ

Named Pipe ในทางปฏิบัติ — IPC มาตรฐานของ Windows ตั้งแต่การออกแบบถึงความปลอดภัย

คู่มือเชิงปฏิบัติเรื่อง named pipe ซึ่งเป็นการสื่อสารระหว่างโปรเซสมาตรฐานของ Windows บทความนี้จัดระเบียบจากแหล่งปฐมภูมิ ทั้งการเลือกระหว่...

อ่านบทความ

ทำให้เว็บไซต์ของคุณปรากฏในการค้นหาด้วยชื่อพื้นที่ — คู่มือ Local SEO ภาคปฏิบัติสำหรับ SME (หน้าเพจพื้นที่และ Google Business Profile)

สำหรับ SME ที่เว็บไซต์ไม่ปรากฏเมื่อมีคนค้นหา "ชื่อพื้นที่ + ประเภทธุรกิจ" บทความนี้เรียบเรียงลำดับขั้นตอนการปรับปรุง Local SEO ได้แก่ การ...

อ่านบทความ

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

หัวข้อเทคนิคของ Windows

ประตูสู่การพัฒนา Windows การตรวจสอบบั๊ก และการใช้ประโยชน์จากสินทรัพย์เดิม

ดูหัวข้อ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

พัฒนาแอป Windows

แอปธุรกิจ การเชื่อมต่ออุปกรณ์ และเครื่องมือสื่อสาร ตั้งแต่ความต้องการจนถึงการพัฒนา

ดูบริการ ติดต่อเรา

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

เมื่อเปิด Hyper-V แล้ว Windows ฝั่งโฮสต์รันอยู่ที่ไหนจริง ๆ: hypervisor ควบคุมโดยตรงว่า CPU จริงและหน่วยความจำถูกจัดสรรอย่างไร และ Windows ฝั่งโฮสต์รันในพาร์ติชันพิเศษที่เรียกว่า root partition การควบคุมอุปกรณ์จริงโดยปกติจัดการด้วยไดรเวอร์ฝั่ง root partition root partition ถือไดรเวอร์อุปกรณ์และสแต็กจัดการการจำลองเสมือน แต่ความเป็นเจ้าของ CPU จริงเป็นของ hypervisor
คำว่า "Virtualization: Enabled" ใน Task Manager หมายความว่า Hyper-V กำลังรันอยู่หรือไม่: ไม่ การแสดงนั้นบอกว่าส่วนขยายการจำลองเสมือนของ CPU (Intel VT-x/AMD-V) ถูกเปิดในเฟิร์มแวร์หรือไม่ หากจะดูว่า hypervisor กำลังรันจริงหรือไม่ ให้ดู "A hypervisor has been detected" ใน systeminfo หรือตรวจ Win32_ComputerSystem.HypervisorPresent
ทำไม hypervisor ถึงรันอยู่ทั้งที่ฉันไม่เคยสร้าง VM: บน Windows 11 ความปลอดภัยบนฐานการจำลองเสมือน (VBS) เปิดตามค่าเริ่มต้นบนอุปกรณ์ที่เข้าเงื่อนไข — เช่น การติดตั้งใหม่บนฮาร์ดแวร์ที่รองรับ — และ VBS สร้างบน Windows hypervisor เช่นเดียวกันหากคุณใช้ WSL2 หรือ Windows Sandbox จึงไม่แปลกที่ hypervisor จะรันโดยไม่เกี่ยวกับใครใช้ VM
SLAT คืออะไร และทำไม Hyper-V จึงต้องการ: SLAT (Second Level Address Translation) คือกลไกที่ CPU แปลที่อยู่จริงของเกสต์เป็นที่อยู่จริงแท้ Intel EPT และ AMD RVI คือการอิมพลีเมนต์ หากไม่มี hypervisor จะต้องรักษาตารางการแปลในซอฟต์แวร์ ซึ่งไม่สมจริงจากมุมมองประสิทธิภาพ ดังนั้น Hyper-V ปัจจุบันถือว่าเป็นข้อกำหนดแข็ง
หากเปิด Hyper-V แล้ว VirtualBox และ VMware จะหยุดทำงานหรือไม่: เพราะ hypervisor ใช้ส่วนขยายการจำลองเสมือนของ CPU แบบเฉพาะ hypervisor ของบุคคลที่สามจึงรันแบบดั้งเดิมไม่ได้ อย่างไรก็ตาม VirtualBox และ VMware ปัจจุบันมีโหมดที่รันบน Windows hypervisor (ผ่าน Windows Hypervisor Platform) ดังนั้นรุ่นล่าสุดของแต่ละตัวสามารถอยู่ร่วมกันได้

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก

ดูโปรไฟล์ ติดต่อเรา

ลิงก์สาธารณะ

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

กลับไปยังบล็อก

“เชิงลึกของการจำลองเสมือนบน Windows” — ทั้ง 3 ตอน

1. สรุปก่อนเลย

2. จากฝั่ง CPU — สิทธิ์อีกชั้นใต้ริง

2.1. ทบทวนการป้องกันแบบริง

2.2. ส่วนขยายการจำลองเสมือน — โหมดสงวนไว้ให้ hypervisor

2.3. Type 1 และ Type 2 — ความต่างอยู่ที่ตำแหน่งที่นั่ง

3. พาร์ติชัน — หน่วยของการแยก

3.1. บทบาทที่มีเฉพาะ root partition

3.2. โลกตามที่เห็นจาก child partition

4. จากฝั่งหน่วยความจำ — การแปลที่อยู่ได้ระดับอีกหนึ่งระดับ

4.1. ที่อยู่สามชนิด

4.2. SLAT — การแปลสองระดับในฮาร์ดแวร์

5. จากฝั่ง I/O อุปกรณ์ — VMBus และอุปกรณ์สองชนิด

5.1. ข้อจำกัดของอุปกรณ์จำลอง

5.2. VMBus และ VSP/VSC — เส้นทางเร็วที่ออกแบบเพื่อการจำลองเสมือน

6. ทำไมเรื่องนี้ไม่ใช่เรื่องของคนอื่น แม้คุณไม่เคยใช้ VM

7. ดูด้วยตนเอง

8. สามการอ่านผิดที่ควรเลี่ยงในทางปฏิบัติ

8.1. “เราไม่ได้เปิด Hyper-V ดังนั้นการจำลองเสมือนไม่เกี่ยวกับเครื่องของเรา”

8.2. “Task Manager บอก ‘Virtualization: Enabled’ ดังนั้น Hyper-V กำลังรัน”

8.3. “หาก VM ช้า นั่นคือปัญหาของ OS เกสต์”

9. สรุป

บทความที่เกี่ยวข้อง

ด้านให้คำปรึกษาที่เกี่ยวข้อง

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

เชิงลึกของการจำลองเสมือนบน Windows (ตอนที่ 2) — หน่วยความจำที่แม้เคอร์เนลก็มองไม่เห็น: กลไกของ VBS, HVCI และ Credential Guard

Win32 Thread Pool API — คอนเคอร์เรนซีโดยไม่สร้างเธรดเอง ด้วย CreateThreadpoolWork

Named Pipe ในทางปฏิบัติ — IPC มาตรฐานของ Windows ตั้งแต่การออกแบบถึงความปลอดภัย

หัวข้อที่เกี่ยวข้อง

หัวข้อเทคนิคของ Windows

บริการที่เกี่ยวข้องกับหัวข้อนี้

พัฒนาแอป Windows

คำถามที่พบบ่อย

โปรไฟล์ผู้เขียน

Go Komura