عندما تفعِّل Hyper-V، أين يعمل Windows المضيف فعليّاً؟

يتولّى الـ hypervisor التحكّم المباشر في كيفيّة تخصيص المعالجات الفيزيائيّة والذاكرة، ويعمل Windows المضيف داخل قسم خاصّ يُسمَّى القسم الجذر. يُعالَج التحكّم بالأجهزة الفيزيائيّة عادةً عبر برامج التشغيل في جانب القسم الجذر. يحتفظ القسم الجذر ببرامج تشغيل الأجهزة ومكدّس إدارة الافتراضيّة، لكن ملكيّة المعالجات الفيزيائيّة تعود إلى الـ hypervisor.

هل تعني «الافتراضيّة: ممكَّنة» في مدير المهام أنّ Hyper-V يعمل؟

لا. يعرض ذلك العرض ما إذا كانت امتدادات الافتراضيّة في المعالج (Intel VT-x/AMD-V) ممكَّنة في البرنامج الثابت. لمعرفة ما إذا كان hypervisor يعمل فعليّاً، ابحث عن «A hypervisor has been detected» في systeminfo، أو افحص Win32_ComputerSystem.HypervisorPresent.

لماذا يعمل الـ hypervisor رغم أنّني لم أُنشئ آلة افتراضيّة قطّ؟

على Windows 11، تُفعَّل الأمان المستند إلى الافتراضيّة (VBS) افتراضيّاً على الأجهزة التي تستوفي الشروط ── تثبيت نظيف على عتاد متوافق مثلاً ── وVBS مبنيّ على hypervisor Windows. الأمر نفسه إن استخدمت WSL2 أو Windows Sandbox. ليس غريباً أن يعمل الـ hypervisor دون أيّ صلة باستخدام أحد للآلات الافتراضيّة.

ما SLAT، ولماذا يُشترَط لـ Hyper-V؟

SLAT (Second Level Address Translation) هي الآليّة التي يترجم بها المعالج العناوين الفيزيائيّة للضيف إلى عناوين فيزيائيّة فعليّة؛ Intel EPT وAMD RVI هما التنفيذان. بدونها سيضطرّ الـ hypervisor إلى صيانة جداول الترجمة برمجيّاً، وهو أمر غير واقعيّ من منظور الأداء، لذا يعاملها Hyper-V الحاليّ متطلَّباً صارماً.

إذا فعَّلتُ Hyper-V، هل يتوقّف VirtualBox وVMware عن العمل؟

لأنّ الـ hypervisor يستخدم امتدادات الافتراضيّة في المعالج حصريّاً، لا يمكن لـ hypervisor طرف ثالث أن يعمل بالطريقة التقليديّة. لكن VirtualBox وVMware الحاليَّين يملكان وضعاً يعمل فوق hypervisor Windows (عبر Windows Hypervisor Platform)، لذا يمكن للإصدارات الحديثة من كلّ منهما التعايش.

أعماق الافتراضيّة في Windows（الجزء 1）── أين يعمل Windows فعليّاً؟ الـ hypervisor والأقسام

22 Aug، 2026 02:00 · غو كومورا · Windows, الافتراضيّة, Hyper-V, Hypervisor, SLAT, VMBus

افتح معلومات النظام (msinfo32) على Windows 11 وسترى غالباً «Running» في حقل «Virtualization-based security» ── حتّى على جهاز لم تُنشئ عليه آلة افتراضيّة قطّ.

ما يعنيه ذلك هو الحقيقة التالية. على ذلك الحاسوب، يعمل Windows المضيف نفسه فوق hypervisor أصلاً. «الافتراضيّة» لم تعد تقنيّة لمن يُنشئ آلات افتراضيّة في Hyper-V Manager فقط. على Windows 11، تُفعَّل الأمان المستند إلى الافتراضيّة (VBS) افتراضيّاً على التكوينات التي تستوفي الشروط ── تثبيت نظيف على عتاد متوافق مثلاً¹ ── وكلّ من WSL2 وWindows Sandbox مبنيّان على hypervisor Windows نفسه. تحت Windows الذي تستخدمه كلّ يوم، ثمّة طبقة برمجيّة إضافيّة أصلاً.

تتبّع هذه السلسلة، «أعماق الافتراضيّة في Windows»، ما يحدث في تلك الطبقة، بدءاً من الأسس.

«أعماق الافتراضيّة في Windows» ── الأجزاء الثلاثة كلّها

الجزء 1 (هذا المقال): الـ hypervisor والأقسام
نتتبّع أين ينتهي Windows المضيف إلى العمل عندما تفعِّل Hyper-V.
الجزء 2: ذاكرة لا تراها النواة ── VBS وHVCI وCredential Guard
نتتبّع أين يضع Windows أسراراً لا يستطيع مدير ولا النواة قراءتها.
الجزء 3: آلات افتراضيّة تقلع في ثوانٍ ── WSL2 وWindows Sandbox والحاويات
نتتبّع، من كيفيّة مشاركة الذاكرة والصور، لماذا WSL2 وSandbox خفيفان رغم ثقل آلة افتراضيّة كاملة.

السؤال الذي يجيب عنه الجزء 1 واحد فقط.

عندما تفعِّل Hyper-V، أين ينتهي Windows المضيف إلى العمل؟

القرّاء المستهدَفون مطوِّرون ومشغِّلون يستخدمون Hyper-V أو WSL2 أو Windows Sandbox ويريدون فهم ما يعمل تحتها من الآليّة صعوداً. المتطلّبات هي Windows 10/11 x64 أو Windows Server الحالي (نقاش الحلقات وVT-x/AMD-V وEPT/RVI في هذا المقال يفترض x64؛ يستخدم Arm64 آليّة مختلفة مثل مستويات الاستثناء). الخلفيّة المطلوبة هي تقريباً التمييز بين وضع النواة ووضع المستخدم؛ لا تحتاج خبرة تشغيل آلات افتراضيّة ولا معرفة تطوير hypervisor. الصعوبة متوسّطة. نغطّي مفهوم امتدادات افتراضيّة المعالج، لكن لا ندخل تفاصيل مجموعة التعليمات.

1. الخلاصة أوّلاً

عندما يسمع الناس Hyper-V، قد يتصوّرون «برمجيّة تشغيل آلات افتراضيّة تجلس فوق Windows». البنية الفعليّة معكوسة.

من لحظة تفعيل Hyper-V وإعادة التشغيل، الـ hypervisor هو من يتحكّم بالمعالجات الفيزيائيّة والذاكرة، ويعمل Windows المضيف فوقه بوصفه أوّل قسم ذي امتياز ── «القسم الجذر».

الـ hypervisor طبقة برمجيّة رقيقة تجلس بين العتاد ونظام التشغيل، وتنشئ بيئات تنفيذ معزولة تُسمَّى «أقساماً»، وتتوسّط الوصول إلى العتاد.² الذي يدخل إليه Windows المضيف هو القسم الجذر؛ والذي تدخل إليه الآلات الافتراضيّة هي الأقسام الأبناء. يُعامَل القسم الجذر معاملة خاصّة (له وصول مباشر إلى الأجهزة الفيزيائيّة ويحتفظ بمكدّس الإدارة)، لكن بمعنى أنّه لا يتحكّم بالمعالجات الفيزيائيّة مباشرةً، يقف في الموقع نفسه كقسم ابن.

flowchart TB
    accTitle: البنية الكلّيّة بعد تفعيل Hyper-V
    accDescr: يجلس الـ hypervisor مباشرةً على العتاد الفيزيائيّ، وفوقه يجلس القسم الجذر الذي يحوي Windows المضيف والأقسام الأبناء التي تحوي الآلات الافتراضيّة
    hw["العتاد الفيزيائيّ"] --> hv["الـ hypervisor"]
    hv --> root["القسم الجذر（Windows المضيف）"]
    hv --> child1["الأقسام الأبناء（الآلات الافتراضيّة）"]
    root -.-> stack["يحوي مكدّس إدارة الافتراضيّة وبرامج التشغيل"]

الشكل 1: Hyper-V ليس «برمجيّة آلات افتراضيّة فوق Windows» بل طبقة تذهب تحت Windows، ونظام التشغيل المضيف نفسه يعمل داخل القسم الجذر.

قد تفكِّر: «إن لم أشعر بفرق بعد التفعيل، هل حدث حقّاً هذا الانقلاب الكبير؟» نعم حدث. ولهذا بالضبط تمرّ هذه البنية عادةً دون أن تُلاحَظ. في هذا المقال نفكِّك هذا الرسم الواحد على ثلاثة محاور: المعالج، والذاكرة، وإدخال/إخراج الأجهزة.

2. من المعالج ── امتياز إضافيّ تحت الحلقات

2.1. تذكير بحماية الحلقات

لمعالجات x64 مستويات امتياز (حلقات)، ويعمل Windows وضع النواة عند الحلقة 0 ووضع المستخدم عند الحلقة 3. لا تستطيع التطبيقات لمس العتاد مباشرةً لأنّ التعليمات المميَّزة لا يمكن تنفيذها من الحلقة 3.

فكيف تؤوي بأمان عدّة نوى أنظمة تشغيل، كلّ منها يعمل عند الحلقة 0، على المعالج الفيزيائيّ نفسه؟ كلّ نواة مكتوبة على افتراض أنّ «أنا أتحكّم بالمعالج». أعطِ الحلقة 0 لكلّها فتتصادم؛ احجبها فلا تعمل.

flowchart TB
    accTitle: مشكلة نوى أنظمة تشغيل متعدّدة تطالب بالحلقة 0
    accDescr: نواتا المضيف والضيف مكتوبتان بافتراض سلطة كاملة عند الحلقة 0، لذا سلّم الحلقات التقليديّ وحده لا يستطيع إيواءهما بأمان على المعالج الفيزيائيّ نفسه
    k1["نواة المضيف（تفترض الحلقة 0）"] --> want["تطالب بالتحكّم بالمعالج الفيزيائيّ"]
    k2["نواة الضيف（تفترض الحلقة 0）"] --> want
    want --> conflict["الحلقات التقليديّة لا توفِّق"]
    conflict --> need["يلزم وسيط فوق الحلقة 0"]

الشكل 2: بُني سلّم الحلقات بافتراض نظام تشغيل واحد، فإيواء نوى متعدّدة يحتاج امتيازاً إضافيّاً فوقه.

2.2. امتدادات الافتراضيّة ── وضع محجوز للـ hypervisor

ما يحلّ هذه المشكلة هو امتدادات الافتراضيّة في المعالج (Intel VT-x/AMD-V). يشترط Hyper-V معالجاً يملك هذه الميزة.² تضيف امتدادات الافتراضيّة، على محور منفصل عن الحلقات التقليديّة، «وضع تنفيذ للـ hypervisor» و«وضع تنفيذ للضيوف». هو امتياز أقوى حتّى من الحلقة 0، يُلقَّب أحياناً «الحلقة −1».

تواصل نواة الضيف العمل عند الحلقة 0، كما كانت. لا يلزم إعادة كتابة.
لكن تلك الحلقة 0 هي «الحلقة 0 داخل وضع الضيف»، ولا تتحكّم بالمعالج الفيزيائيّ ككلّ.
عندما يصطدم الضيف بعمليّة معيّنة تحتاج تدخّل الـ hypervisor (تعليمة مضبوطة كاعتراض، أو استثناء أو انتهاك)، ينقل المعالج التحكّم تلقائيّاً إلى الـ hypervisor (VM Exit). عندما ينتهي الـ hypervisor من المعالجة، يعود إلى الضيف (VM Entry). تمرّ وصولات الذاكرة العاديّة دون VM Exit، ما دامت ترجمة SLAT تنجح.

تعمل المقاطعات بالطريقة نفسها. لا تلمس الأقسام المعالجات الفيزيائيّة مباشرةً؛ يستقبل الـ hypervisor المقاطعات ويوجِّهها إلى كلّ قسم.²

flowchart TB
    accTitle: تدفّق تنفيذ الضيف وVM Exit
    accDescr: تعمل نواة الضيف والتطبيقات عند الحلقة 0 والحلقة 3 في وضع الضيف؛ تمرّ وصولات الذاكرة العاديّة عبر ترجمة SLAT، بينما تتسبّب الاعتراضات والاستثناءات المضبوطة في VM Exit ينقل التحكّم إلى الـ hypervisor، الذي يعود بعد ذلك إلى الضيف عبر VM Entry
    guest["يعمل في وضع الضيف（بما فيه نواة الحلقة 0）"] --> op{"عمليّة تحتاج تدخّلاً؟（اعتراضات/استثناءات مضبوطة）"}
    op -->|لا| cont["واصل التنفيذ كما هو"]
    op -->|نعم| exitEv["VM Exit（المعالج ينقل التحكّم）"]
    exitEv --> hvp["الـ hypervisor يعالجها"]
    hvp --> entry["العودة إلى الضيف عبر VM Entry"]
    entry --> guest

الشكل 3: يواصل نظام تشغيل الضيف العمل عند الحلقة 0 دون إعادة كتابة، ويستدعي المعالج الـ hypervisor فقط عند الحاجة.

يشبه هذا الذهاب والإياب كثيراً التدفّق الذي تتبّعناه في سلسلة الذاكرة ── «ادخل النواة عند خطأ صفحة، ثمّ عُد إلى التعليمة نفسها». يعترض المعالج التحكّم عبر آليّة استثناء أو انتقال، ويدع مديراً أعلى يقرِّر، ثمّ يعود. في أعماق Windows، يظهر هذا الشكل مراراً.

2.3. النوع 1 والنوع 2 ── الفرق هو أين يجلس

تُقسَم برامج hypervisor عموماً إلى النوع 1 (على العتاد مباشرةً / bare-metal)، الذي يعمل مباشرةً على العتاد، والنوع 2 (مستضاف)، الذي يعمل فوق نظام تشغيل مضيف. Hyper-V من النوع 1.³ يُصنَّف VirtualBox وVMware Workstation (عند التشغيل مستقلَّين) نوعاً 2.

عند سماع النوع 1، يميل الناس إلى تخيّل «تكوين خادم فقط بلا نظام تشغيل مضيف»، لكن Hyper-V مختلف. لا يختفي Windows المضيف ── إنّه «ينتقل» إلى القسم الجذر. عندما تفعِّل Hyper-V وتعيد التشغيل، يبدأ الـ hypervisor أوّلاً أثناء الإقلاع، ثمّ يأتي Windows المضيف بوصفه القسم الجذر فوقه.

flowchart TB
    accTitle: الفرق بين hypervisor النوع 1 والنوع 2
    accDescr: في النوع 2 يجلس نظام التشغيل المضيف على العتاد ويجلس الـ hypervisor والآلات الافتراضيّة على نظام التشغيل المضيف، بينما في Hyper-V من النوع 1 يجلس الـ hypervisor مباشرةً على العتاد ويدخل نظام التشغيل المضيف نفسه إلى القسم الجذر فوقه
    subgraph t2 ["النوع 2（مستضاف）"]
        hw2["العتاد"] --> hostos["نظام التشغيل المضيف"]
        hostos --> hv2["الـ hypervisor"]
        hv2 --> vm2["آلة افتراضيّة"]
    end
    subgraph t1 ["النوع 1（Hyper-V）"]
        hw1["العتاد"] --> hv1["الـ hypervisor"]
        hv1 --> root1["القسم الجذر（نظام التشغيل المضيف）"]
        hv1 --> vm1["آلة افتراضيّة"]
    end
    vm2 ~~~ hw1

الشكل 4: في النوع 2 يجلس الـ hypervisor على نظام التشغيل المضيف، بينما في Hyper-V من النوع 1 يُعكَس الترتيب ويجلس نظام التشغيل المضيف نفسه على الطبقة الأدنى بدرجة.

منظوراً على خطّ زمنيّ للإقلاع، يبدو التغيير الذي يحدث عند التفعيل هكذا.

flowchart TB
    accTitle: ترتيب الإقلاع بعد تفعيل Hyper-V
    accDescr: بعد التشغيل، يبدأ الـ hypervisor أوّلاً أثناء الإقلاع، ثمّ يأتي Windows المضيف بوصفه القسم الجذر فوقه، وتبدأ الآلات الافتراضيّة وVBS وما شابه بعد ذلك
    poweron["التشغيل وبدء الإقلاع"] --> bhv["الـ hypervisor يبدأ أوّلاً"]
    bhv --> broot["Windows المضيف يبدأ قسماً جذراً"]
    broot --> blater["الآلات الافتراضيّة وVBS وWSL2 تبدأ فوق ذلك"]
    broot -.-> feel["تجربة المستخدم بلا تغيير"]

الشكل 5: انقلاب الترتيب يكون قد انتهى قبل ظهور شاشة تسجيل الدخول، ويأتي نظام التشغيل المضيف على الـ hypervisor من البداية.

3. الأقسام ── وحدة العزل

3.1. أدوار يملكها القسم الجذر وحده

القسم وحدة عزل منطقيّة يوفِّرها الـ hypervisor.² لكن ليست كلّ الأقسام متساوية. ثمّة أمور يملكها القسم الجذر وحده.

وصول مباشر إلى الأجهزة الفيزيائيّة. تعيش برامج تشغيل الأقراص وبطاقات الشبكة ووحدات GPU وما شابه في Windows داخل القسم الجذر، لا في الـ hypervisor. لـ Hyper-V على Windows Server تكوين يخصِّص جهازاً PCIe معيّناً مباشرةً لقسم ابن (Discrete Device Assignment)؛ في تلك الحالة يُفلِت الجذر ذلك الجهاز (هذا غير متاح على Windows العميل).⁴
مكدّس إدارة الافتراضيّة. يعمل VMMS (Virtual Machine Management Service)، الذي يحكم إنشاء الآلات الافتراضيّة وبدءها وإيقافها، وعملية العامل لكلّ آلة افتراضيّة (vmwp.exe) في وضع المستخدم في القسم الجذر.⁵ هذه جزء من ميزات إدارة الآلات الافتراضيّة في Hyper-V، لذا قد تغيب على مضيف يعمل فيه الـ hypervisor فقط من أجل VBS أو WSL2.
حقّ إنشاء أقسام أبناء. ينشئ القسم الجذر أقساماً أبناء عبر واجهة hypercall (واجهة الاستدعاء إلى الـ hypervisor).²

لهذا التصميم سبب. إن وضعت كلّ برنامج تشغيل جهاز في الـ hypervisor نفسه، يصبح الـ hypervisor ضخماً ويزداد عدد العلل ومداخل الهجوم. يحصر الـ hypervisor نفسه في العمل الأدنى لتوسّط المعالجات والذاكرة، ويترك رعاية الأجهزة لـ Windows في القسم الجذر. تقسيم الأدوار هذا هو ما يُبقي Hyper-V رقيقاً.

flowchart TB
    accTitle: تقسيم الأدوار بين القسم الجذر والأقسام الأبناء
    accDescr: يحتفظ القسم الجذر بمكدّس إدارة الافتراضيّة وبرامج تشغيل الأجهزة الفيزيائيّة وينشئ أقساماً أبناء عبر hypercalls؛ يرى القسم الابن عادةً أجهزة افتراضيّة فقط، وتحت Discrete Device Assignment على Windows Server يصل إلى الجهاز المخصَّص مباشرةً
    subgraph rootp ["القسم الجذر"]
        vmms["VMMS وعمليّات العامل"]
        drv["برامج تشغيل الأجهزة الفيزيائيّة"]
    end
    subgraph childp ["القسم الابن"]
        gos["نظام تشغيل الضيف"]
        vdev["في التكوين المعتاد، أجهزة افتراضيّة فقط"]
    end
    vmms -->|أنشئ وأدِر عبر hypercalls| childp
    hv2["الـ hypervisor（يحصر نفسه في توسّط المعالج والذاكرة）"] --- rootp
    hv2 --- childp

الشكل 6: وضع برامج تشغيل الأجهزة ومكدّس الإدارة في جانب القسم الجذر هو ما يُبقي الـ hypervisor نفسه رقيقاً.

3.2. العالم كما يُرى من قسم ابن

لا يستطيع نظام تشغيل الضيف في قسم ابن رؤية العتاد الفيزيائيّ مباشرةً في تكوين الأجهزة الافتراضيّة المعتاد (الاستثناء الوحيد جهاز مخصَّص عبر Discrete Device Assignment على Windows Server، كما في القسم السابق). ما يستطيع رؤيته هو معالجات افتراضيّة، وفضاء ذاكرة يبدو خاصّاً به، وأجهزة افتراضيّة. تُمرَّر الطلبات إلى الأجهزة الافتراضيّة إلى القسم الجذر عبر VMBus أو الـ hypervisor.² أمّا تخصيص وقت المعالج وترجمة الذاكرة عبر SLAT فيعالجهما الـ hypervisor مباشرةً دون المرور بالجذر. ما يتوسّطه الجذر هو إدخال/إخراج الأجهزة، لا كلّ مورد فيزيائيّ.

flowchart TB
    accTitle: العالم كما يُرى من قسم ابن
    accDescr: ما يراه نظام تشغيل الضيف هو معالجات افتراضيّة وفضاء ذاكرة خاصّ بالقسم وأجهزة افتراضيّة؛ تُمرَّر الطلبات إلى الأجهزة الافتراضيّة إلى القسم الجذر عبر VMBus وما شابه، ويعالج الـ hypervisor وقت المعالج وترجمة الذاكرة مباشرةً، وفي تكوين Discrete Device Assignment على Windows Server تُوصَل الأجهزة المخصَّصة فقط مباشرةً
    gos2["نظام تشغيل الضيف（ابن）"] --> vcpu["معالجات افتراضيّة"]
    gos2 --> rest{"ذاكرة أم أجهزة؟"}
    rest --> gpa2["فضاء ذاكرة خاصّ"]
    rest --> vdev2["أجهزة افتراضيّة"]
    vdev2 --> rootx["تُمرَّر إلى الجذر"]
    rootx -.-> vbus["عبر VMBus وما شابه"]
    gos2 -.-> phys2["معالج فيزيائيّ وRAM وأجهزة"]
    phys2 -.-> hid["غير مرئيّة مباشرةً"]
    phys2 -.-> dda2["DDA: أجهزة مخصَّصة"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

الشكل 7: في تكوين الأجهزة الافتراضيّة المعتاد كلّ ما يراه الضيف نافذة افتراضيّة والمسار إلى الفيزيائيّ يمرّ بوسيط؛ الجهاز المخصَّص عبر DDA على Windows Server وحده هو الاستثناء.

ما يهمّ هنا هو أنّ بالنسبة لتطبيق يعمل على Windows المضيف، هذه البنية شفّافة تقريباً. ما زالت استدعاءات Win32 API ومعالجة أخطاء الصفحات تُعالَج بواسطة نواة Windows داخل القسم الجذر، كما كانت. يتدخّل الـ hypervisor فقط عندما يُصطدَم باعتراض أو استثناء مضبوط.

4. من الذاكرة ── ترجمة العناوين تكتسب مستوى إضافيّاً

4.1. ثلاثة أنواع من العناوين

في الجزء 1 من سلسلة الذاكرة تتبّعنا التدفّق الذي تُترجَم به عنوان افتراضيّ عبر جدول الصفحات إلى عنوان فيزيائيّ («اللحظة التي يصبح فيها عنوان افتراضيّ ذاكرة RAM فيزيائيّة»). في بيئة مُفتَرَضة يُضاف مستوى إضافيّ تحت تلك الترجمة، وثمّة ثلاثة أنواع من العناوين.

العنوان	الاختصار	من يديره
عنوان افتراضيّ للضيف	GVA	جدول صفحات نظام تشغيل الضيف
عنوان فيزيائيّ للضيف	GPA	العنوان الذي يعتقد نظام تشغيل الضيف أنّه «فيزيائيّ»
عنوان فيزيائيّ للنظام	SPA	الـ hypervisor (الموقع الفعليّ في RAM)

يترجم نظام تشغيل الضيف GVA إلى GPA بجدول صفحاته. لكن GPA الذي يراه الضيف ليس عنواناً فيزيائيّاً حقيقيّاً؛ إنّه فضاء ذاكرة خاصّ مخصَّص لكلّ قسم.² إسقاط GPA على الموقع الفعليّ في RAM (SPA) مهمّة الـ hypervisor.

4.2. SLAT ── ترجمة ذات مستويين في العتاد

إن فعلت هذه الترجمة من المستوى الثاني برمجيّاً وحدها، سيضطرّ الـ hypervisor إلى تتبّع كلّ تحديث لجدول صفحات الضيف واحداً واحداً، وهو أمر غير واقعيّ من منظور الأداء. لذا يوفِّر المعالج آليّة تمشي جداول الترجمة من المستوى الثاني في العتاد. تلك هي SLAT (Second Level Address Translation)؛ Intel EPT (Extended Page Tables) وAMD RVI هما التنفيذان. يشترط Hyper-V الحاليّ معالج 64 بت قادراً على SLAT.⁴

flowchart TB
    accTitle: ترجمة عناوين ذات مستويين عبر SLAT
    accDescr: يُترجَم عنوان افتراضيّ للضيف إلى عنوان فيزيائيّ للضيف بجدول صفحات نظام تشغيل الضيف، ثمّ يُترجَم أيضاً إلى عنوان فيزيائيّ للنظام بـ SLAT الذي يديره الـ hypervisor، ويصل إلى RAM الفعليّ
    gva["عنوان افتراضيّ للضيف（GVA）"] -->|جدول صفحات نظام تشغيل الضيف| gpa["عنوان فيزيائيّ للضيف（GPA）"]
    gpa -->|"SLAT（جداول ترجمة EPT/RVI）"| spa["عنوان فيزيائيّ للنظام（SPA）"]
    spa --> ram["RAM فيزيائيّ"]
    gpa -.-> note["طبقة يعتقد الضيف أنّها فيزيائيّة فحسب"]

الشكل 8: جدول ترجمة آخر، يديره الـ hypervisor، يجلس تحت جدول صفحات الضيف، ويمشي المعالج كليهما في العتاد.

SLAT ليست ميزة توجد فقط لكفاءة تنفيذ الآلات الافتراضيّة. يستخدم VBS الذي سنراه في الجزء 2 خاصّيّة «يمكنك امتلاك جدول ترجمة SLAT مختلف لكلّ مستوى امتياز» مادّةً لحدّ أمنيّ. سبب إمكان إنشاء ذاكرة لا تراها النواة حتّى هو أنّ الـ hypervisor يحتفظ بهذه الترجمة من المستوى الثاني. يصبح هذا خيطاً عبر السلسلة كلّها، لذا تذكَّر نقطة واحدة: «مالك جداول الترجمة هو الـ hypervisor».

5. من إدخال/إخراج الأجهزة ── VMBus ونوعان من الأجهزة

5.1. حدود الأجهزة المُحاكاة

الطريقة الكلاسيكيّة لإظهار جهاز لقسم ابن هي محاكاة عتاد حقيقيّ بالكامل (متحكِّم IDE قديم مثلاً) برمجيّاً. التوافق مرتفع لأنّ برامج التشغيل المدمَجة في نظام تشغيل الضيف تعمل كما هي، لكن يحدث VM Exit في كلّ مرّة يصطدم فيها الضيف بمنفذ إدخال/إخراج، والأداء لا يتوسّع.

flowchart TB
    accTitle: لماذا إدخال/إخراج جهاز مُحاكى بطيء
    accDescr: في كلّ مرّة يشغِّل فيها الضيف منفذ إدخال/إخراج، ينتقل التحكّم إلى جانب الـ hypervisor عبر VM Exit، ويُحاكى الجهاز برمجيّاً، ويُعاد الضيف، فتتكرّر الدورة وتكون بطيئة
    gio["الضيف يشغِّل منفذ إدخال/إخراج"] --> vex["يحدث VM Exit"]
    vex --> emu2["يُحاكى الجهاز برمجيّاً"]
    emu2 --> back["العودة إلى الضيف عبر VM Entry"]
    back -->|تتكرّر عند تشغيل المنفذ التالي| gio

الشكل 9: تعمل هذه الدورة مرّات كثيرة خلف وصول قرص واحد، وثمن التوافق يُدفَع أداءً.

5.2. VMBus وVSP/VSC ── مسار سريع مصمَّم للافتراضيّة

لذا يملك Hyper-V آليّة «جهاز اصطناعيّ» مصمَّمة بافتراض الافتراضيّة. ثمّة ثلاث شخصيّات.²

VMBus: قناة اتّصال منطقيّة بين الأقسام. توفِّر اتّصالاً عالي السرعة بين الأقسام يستخدم ذاكرة مشتركة.³
VSP (Virtualization Service Provider): خدمة تقيم في جانب القسم الجذر، تستقبل طلبات الأجهزة من الابن، وتجسرها إلى مكدّس الجهاز/الخلف في جانب الجذر. قد يصل الطلب إلى جهاز فيزيائيّ، أو قد يعالجه خلف في جانب المضيف مثل قرص افتراضيّ أو مبدِّل افتراضيّ.
VSC (Virtualization Service Consumer): برنامج تشغيل جهاز اصطناعيّ يدخل نظام تشغيل الضيف في جانب القسم الابن. يرسل الطلبات إلى VSP عبر VMBus.

بأخذ طلب تخزين من نظام تشغيل الضيف مثالاً، يبدو التدفّق هكذا. يهبط WriteFile لتطبيق الضيف في مكدّس إدخال/إخراج نواة الضيف ويصل، في الأسفل، إلى VSC (بدلاً من عتاد حقيقيّ). يضع VSC الطلب على VMBus ويسلِّمه إلى VSP في القسم الجذر، ويُدخل VSP الطلب في مكدّس الإدخال/الإخراج في جانب الجذر. في تكوين قرص افتراضيّ (VHDX)، تُعالَج هذه الكتابة كتابةً إلى ملفّ VHDX على المضيف وتصل في النهاية إلى القرص الفيزيائيّ. يُسمَّى هذا النهج Enlightened I/O (إدخال/إخراج واعٍ بالافتراضيّة)، ويرفع الكفاءة بتجاوز طبقة محاكاة الجهاز.²

flowchart TB
    accTitle: مسار إدخال/إخراج لجهاز اصطناعيّ
    accDescr: يصل طلب إدخال/إخراج من تطبيق في القسم الابن إلى VSC عبر نواة الضيف، ويعبر VMBus إلى VSP في القسم الجذر، وعلى مكدّس الإدخال/الإخراج في جانب الجذر الذي يجسره VSP قد يصل إلى جهاز حقيقيّ عبر برنامج تشغيل جهاز فيزيائيّ، أو قد يعالجه خلف في جانب المضيف مثل قرص افتراضيّ أو مبدِّل افتراضيّ
    app["تطبيق في القسم الابن"] --> gk["مكدّس إدخال/إخراج نواة الضيف"]
    gk --> vsc["VSC（برنامج تشغيل جهاز اصطناعيّ）"]
    vsc -->|VMBus| vsp["VSP（جانب القسم الجذر）"]
    vsp --> rio["مكدّس إدخال/إخراج جانب الجذر"]
    rio --> pdrv["برنامج تشغيل جهاز فيزيائيّ"]
    rio --> hb["خلف جانب المضيف（قرص افتراضيّ، مبدِّل افتراضيّ، وغيرها）"]
    pdrv --> dev["جهاز فيزيائيّ"]

الشكل 10: مع جهاز اصطناعيّ، يعبر إدخال/إخراج الضيف إلى القسم الجذر عبر VMBus، وعبر مكدّس جانب الجذر يصل إلى جهاز حقيقيّ أو خلف في جانب المضيف.

بعبارة أخرى، ما إذا كان إدخال/إخراج قرص آلة افتراضيّة أو شبكتها سريعاً لا يعتمد على جانب الضيف فقط بل أيضاً على حالة مكدّس الإدخال/الإخراج وبرامج تشغيل الأجهزة في جانب القسم الجذر. سبب كون الملاحظة من جانب المضيف لا غنى عنها عند التحقيق في مشكلة أداء آلة افتراضيّة هو أنّ المسار يمرّ فعليّاً بالمضيف.

flowchart TB
    accTitle: الأجهزة المُحاكاة مقابل الأجهزة الاصطناعيّة
    accDescr: يحاكي جهاز مُحاكى عتاداً حقيقيّاً فتعمل برامج تشغيل الضيف المدمَجة لكنّه بطيء؛ الجهاز الاصطناعيّ برنامج تشغيل مصمَّم لغرضه يفترض VMBus وهو سريع
    dev2{"الجهاز المعروض على القسم الابن"} --> emu["جهاز مُحاكى"]
    dev2 --> syn["جهاز اصطناعيّ"]
    emu -.-> emuP["يحاكي عتاداً حقيقيّاً؛ التوافق أوّلاً"]
    emuP -.-> emuC["يحتاج تدخّلاً عند كلّ إدخال/إخراج؛ بطيء"]
    syn -.-> synP["مصمَّم حول VMBus؛ سريع"]
    synP -.-> synC["يتطلّب برنامج تشغيل مطابقاً في الضيف"]

الشكل 11: من نوعَي الجهاز الافتراضيّ، تحمل الأجهزة المُحاكاة التوافق بعد تثبيت نظام التشغيل مباشرةً، وتحمل الأجهزة الاصطناعيّة الأداء في الاستخدام اليوميّ.

6. لماذا هذا ليس شأن غيرك، حتّى إن لم تستخدم آلة افتراضيّة قطّ

قد تبدو البنية حتّى الآن «قصّة لمن يُقيم آلات افتراضيّة». لكن كما قال الافتتاح، على Windows الحاليّ الـ hypervisor جزء من الحياة اليوميّة.

الأمان المستند إلى الافتراضيّة (VBS). يستخدم hypervisor Windows لإنشاء بيئة معزولة ويؤوي فيها ميزات أمنيّة. على Windows 11 يُفعَّل افتراضيّاً عندما تُستوفى شروط مثل تثبيت نظيف على عتاد متوافق.¹ التفاصيل في الجزء 2.
WSL2. يشغِّل نواة Linux حقيقيّة داخل آلة افتراضيّة خدميّة خفيفة.⁶
Windows Sandbox. بيئة Windows قابلة للرمي معزولة بالـ hypervisor.⁷ كلاهما في الجزء 3.

flowchart TB
    accTitle: ميزات يوميّة تجلس على الـ hypervisor نفسه
    accDescr: ليس فقط آلات Hyper-V الافتراضيّة بل أيضاً VBS، الذي يُفعَّل افتراضيّاً على الأجهزة التي تستوفي شروطاً مثل التثبيت النظيف، زائد WSL2 وWindows Sandbox، كلّها مبنيّة على hypervisor Windows نفسه
    base["hypervisor Windows"] --> f1["آلات Hyper-V الافتراضيّة"]
    base --> f2["VBS（افتراضي عند التثبيت النظيف）"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["لماذا يعمل على حواسيب بلا VM"]

الشكل 12: الأساس واحد، وهذا الرسم هو حيث ينهار افتراض «الافتراضيّة قصّة لمن يستخدم آلات افتراضيّة».

أمر آخر يطأه الناس كثيراً في العمل هو التعايش مع برمجيّات افتراضيّة من طرف ثالث. لأنّ الـ hypervisor يستخدم امتدادات الافتراضيّة في المعالج حصريّاً، في بيئة يعمل فيها hypervisor Windows، لا يستطيع VirtualBox وما شابه العمل بالطريقة التقليديّة (الطريقة التي تستخدم امتدادات الافتراضيّة في المعالج نفسها). لهذا تُوفَّر واجهة عامّة تُسمَّى Windows Hypervisor Platform، ويمكن لمكدّس افتراضيّة من طرف ثالث أن يعمل بالجلوس فوق hypervisor Windows.⁸ يمكن لـ VirtualBox/VMware الحاليَّين التعايش مع WSL2 بفضل هذه الآليّة، لكن فروق أداء وميزات تأتي مع تبديل الأوضاع تُلاحَظ أحياناً بوصفها «بعد تفعيل Hyper-V (أو VBS)، بدأت برمجيّة الافتراضيّة تتصرّف بشكل مختلف».

flowchart TB
    accTitle: من يملك امتدادات افتراضيّة المعالج، ومسار برمجيّة افتراضيّة طرف ثالث
    accDescr: بينما يعمل hypervisor Windows يملك امتدادات افتراضيّة المعالج حصريّاً؛ برمجيّة افتراضيّة طرف ثالث تدعم WHP تعمل فوقه عبر Windows Hypervisor Platform، بينما التنفيذات التي لا تدعم WHP لا تستطيع العمل أو تكون محدودة الميزات
    vt["امتدادات افتراضيّة المعالج（VT-x/AMD-V）"] --> hvon{"هل يعمل hypervisor Windows؟"}
    hvon -->|لا| direct["برمجيّة طرف ثالث تستطيع استخدامه مباشرةً"]
    hvon -->|نعم| own["الـ hypervisor يستخدمه حصريّاً"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["برمجيّة طرف ثالث قادرة على WHP تعمل فوقه"]
    third -.-> nowhp["تنفيذات غير قادرة لا تعمل، أو محدودة"]

الشكل 13: لمالك امتدادات الافتراضيّة واحد، وبرمجيّة الطرف الثالث الوحيدة التي تستطيع التعايش بينما يعمل الـ hypervisor هي برمجيّة تدعم الواجهة العامّة (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»؛ ولا يميِّز الجذر عن الابن. إن شغَّلتَه على Windows داخل آلة افتراضيّة، ما زال يُرجع True، بوصفه قسماً ابناً. إن كان True على Windows على حاسوب فيزيائيّ، فذلك Windows داخل القسم الجذر ── تقرؤه مع بيئة التنفيذ.

ثانياً، الكلاسيكيّ من موجه أوامر.

systeminfo

انظر إلى «Hyper-V Requirements» في نهاية المخرجات. على جهاز لم يعمل فيه الـ hypervisor بعد، تُدرَج المتطلّبات الفرديّة ── دعم SLAT، وما إذا كانت امتدادات الافتراضيّة ممكَّنة، وغيرها. على جهاز يعمل فيه الـ hypervisor أصلاً، بدلاً من المتطلّبات تحصل على سطر واحد: «A hypervisor has been detected. Features required for Hyper-V will not be displayed.»⁴ ذلك السطر الواحد إذن بيان أنّ Windows لديك يعمل فوق hypervisor ما. كما مع HypervisorPresent، تحتاج إلى قراءته «داخل القسم الجذر» على حاسوب فيزيائيّ، أو «بوصفه قسماً ابناً» داخل آلة افتراضيّة.

حتّى إن كان كلّ متطلَّب في systeminfo «Yes»، فهذا يعني فقط أنّ جانب العتاد جاهز. ميزة Hyper-V نفسها متاحة على إصدارات Pro وEnterprise وEducation، وليست على Home.¹⁰

في الواجهة الرسوميّة، افحص صف «Virtualization-based security» تحت «System Summary» في msinfo32. لاحظ أنّ «Virtualization: Enabled» في لوحة المعالج في مدير المهام يعرض فقط ما إذا كانت امتدادات الافتراضيّة ممكَّنة في البرنامج الثابت، وهو معلومات منفصلة عن ما إذا كان hypervisor يعمل.

flowchart TB
    accTitle: كيفيّة فحص ما إذا كان الـ hypervisor يعمل
    accDescr: إذا قال systeminfo إنّ hypervisor قد اكتُشِف فأنت تعمل على hypervisor（داخل القسم الجذر على حاسوب فيزيائيّ）；إذا ظهرت قائمة Hyper-V Requirements فهو لا يعمل بعد لذا تفحص كلّ متطلَّب مثل SLAT وVM Monitor Mode Extensions وDEP، لكن كلّها Yes تعني فقط أنّ جانب العتاد جاهز ولميزة Hyper-V أيضاً متطلَّب إصدار
    start2["شغِّل systeminfo"] --> q1{"حقل المتطلّبات؟"}
    q1 -->|اكتُشِف| running["الـ hypervisor يعمل"]
    running -.-> runN["داخل الجذر"]
    runN -.-> runN2["على حاسوب فيزيائيّ"]
    q1 -->|مُدرَج| 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 (أدوات الإدارة وبيئة تنفيذ الآلات الافتراضيّة)، يعمل hypervisor Windows إن كان VBS مفعَّلاً. عندما تحقِّق في مشكلة توافق برنامج تشغيل، أو اختبار أداء، أو مشكلة مع برمجيّة افتراضيّة من طرف ثالث، افحص HypervisorPresent وحالة تشغيل VBS ── لا ما إذا كانت الميزة مفعَّلة.

8.2. «مدير المهام يقول «Virtualization: Enabled»، إذن Hyper-V يعمل»

ذلك العرض عن إعداد البرنامج الثابت (ما إذا كان VT-x/AMD-V متاحاً). احكم على حالة تشغيل الـ hypervisor من «A hypervisor has been detected» في systeminfo. بالمقابل، إذا قال مدير المهام «Disabled»، لا تستطيع تفعيل Hyper-V أو WSL2 أيضاً، فافحص إعدادات UEFI/BIOS أوّلاً.

flowchart TB
    accTitle: ثلاثة فحوصات يسهل الخلط بينها
    accDescr: حقل الافتراضيّة في مدير المهام يعرض إعداد البرنامج الثابت، وقائمة ميزات Windows تعرض حالة التثبيت، وsysteminfo أو HypervisorPresent يعرض حالة التشغيل؛ كلّ منها يجيب عن سؤال مختلف
    q3{"أيّ سؤال؟"}
    q3 --> fw{"برنامج ثابت أم Windows؟"}
    q3 --> c3["هل يعمل الـ hypervisor؟"]
    fw --> a3["امتدادات البرنامج الثابت؟"]
    fw --> b3["هل ميزة Hyper-V مفعَّلة؟"]
    a3 -.-> a3t["لوحة المعالج في مدير المهام"]
    b3 -.-> b3t["واجهة ميزات Windows"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["HypervisorPresent"]

الشكل 15: هذه ثلاثة أسئلة مستقلّة، واستنتاج الاثنين الآخرين من أيّ عرض واحد قراءة خاطئة.

8.3. «إذا كانت الآلة الافتراضيّة بطيئة، فهي مشكلة نظام تشغيل الضيف»

يعبر إدخال/إخراج الجهاز الاصطناعيّ VMBus إلى VSP في القسم الجذر ويمرّ بمكدّس الجهاز/الخلف في جانب الجذر (برامج تشغيل فيزيائيّة، زائد معالجة مبدِّل افتراضيّ وقرص افتراضيّ). إن راقبت العدّادات داخل الضيف فقط، لن تجد اختناقاً يجلس في تخزين جانب المضيف أو بطاقة شبكة. مبدأ مشكلات أداء الآلة الافتراضيّة هو الملاحظة من الجانبين: الضيف والمضيف (القسم الجذر).

9. الخلاصة

عندما تفعِّل Hyper-V، يعمل الـ hypervisor مباشرةً على العتاد ويعمل Windows المضيف بوصفه القسم الجذر.²
تواصل نواة نظام تشغيل الضيف العمل عند الحلقة 0، والعمليّات المضبوطة كاعتراضات زائد الاستثناءات وحدها تُسلَّم إلى الـ hypervisor عبر VM Exit. تمرّ وصولات الذاكرة العاديّة عبر ترجمة SLAT.
يحتفظ القسم الجذر وحده ببرامج تشغيل الأجهزة الفيزيائيّة ومكدّس إدارة الافتراضيّة، وينشئ أقساماً أبناء عبر hypercalls.²
تصبح الذاكرة ترجمة ذات مستويين GVA→GPA→SPA، ويُعالَج المستوى الثاني في العتاد بـSLAT (EPT/RVI). يشترط Hyper-V الحاليّ SLAT.⁴
يهيمن على إدخال/إخراج الأجهزة مسار الجهاز الاصطناعيّ VSC→VMBus→VSP، والأداء يعتمد أيضاً على مكدّس الإدخال/الإخراج في جانب المضيف.²
على Windows 11، لأنّ VBS يُفعَّل افتراضيّاً على الأجهزة التي تستوفي شروطاً مثل التثبيت النظيف، ليس غريباً أن يعمل الـ hypervisor حتّى على حاسوب لا يستخدم آلة افتراضيّة قطّ.¹ يمكنك تأكيد حالة التشغيل بـHypervisorPresent وsysteminfo.

تتكثّف الصورة الكبيرة للجزء 1 في هذا الرسم الواحد.

flowchart TB
    accTitle: الصورة الكبيرة للجزء 1
    accDescr: يجلس الـ hypervisor تحت القسم الجذر والأقسام الأبناء؛ تُخصَّص المعالجات بجدولة معالجات افتراضيّة（VM Exit فقط عند اعتراضات واستثناءات مضبوطة）、والذاكرة تتوسّطها ترجمة SLAT ذات مستويين، ويُمرَّر إدخال/إخراج الجهاز الاصطناعيّ عبر VMBus ويعالجه VSP في القسم الجذر، وللأجهزة المُحاكاة وDiscrete Device Assignment مسارات أخرى
    up["القسم الجذر + الأقسام الأبناء"] --> hvS["الـ hypervisor"]
    hvS --> cpuS["المعالج: جدولة VP"]
    hvS --> memS["الذاكرة: SLAT"]
    cpuS -.-> cpuN["VM Exit عند الاعتراض"]
    memS -.-> memN["ترجمة ذات مستويين"]
    memS ~~~ devS
    devS["الأجهزة: إدخال/إخراج VMBus"] --> vspS["VSP جانب الجذر يعالج"]
    devS -.-> devN["مُحاكى / DDA: أخرى"]

الشكل 16: جدولة المعالج وترجمة الذاكرة يعالجهما الـ hypervisor مباشرةً (VM Exit عند التدخّل فقط)، ويتوسّط القسم الجذر (VSP) إدخال/إخراج الجهاز الاصطناعيّ في الجانب الأبعد من VMBus.

يتواصل في الجزء 2، «ذاكرة لا تراها النواة ── VBS وHVCI وCredential Guard».

نلتقط خيط هذا المقال ── أنّ الـ hypervisor يحتفظ بجداول ترجمة SLAT ── ونتتبّع كيف ينشئ Windows «ذاكرة لا يستطيع مدير ولا النواة قراءتها».

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم بيئات التحقّق لتطبيقات Windows، وتحقيقات الأداء في البيئات الافتراضيّة، وتحليل مشكلات توافق برامج التشغيل والأجهزة الطرفيّة.

روابط مرجعيّة

Microsoft Learn, Silicon assisted security. حول استخدام VBS الافتراضيّة العتاديّة لعزل النواة الآمنة عن نظام التشغيل العاديّ، وحول تفعيل VBS وHVCI افتراضيّاً على الأجهزة التي تستوفي المتطلّبات عند تثبيت جديد لـ Windows 11. ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. حول توفير الـ hypervisor للأقسام بوصفها وحدة العزل؛ وإنشاء القسم الجذر أقساماً أبناء عبر واجهة hypercall؛ وعمل الأقسام في فضاء ذاكرة افتراضيّ خاصّ دون وصول مباشر إلى المعالجات الفيزيائيّة؛ وأدوار VMBus وVSP وVSC وEnlightened I/O؛ واشتراط امتدادات الافتراضيّة في العتاد (Intel VT/AMD-V). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). حول كون Hyper-V hypervisor من النوع 1، وملكيّة القسم الجذر لأجهزة الإدخال/الإخراج الفيزيائيّة، وتوفير 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 جهازاً معيّناً مباشرةً لقسم ابن. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. حول إدارة VMMS (Virtual Machine Management Service) لحالة الآلات الافتراضيّة في الأقسام الأبناء، وبدء عمليّة عامل (VMWP) في وضع المستخدم في القسم الجذر لكلّ آلة افتراضيّة. ↩
Microsoft Learn, Comparing WSL Versions. حول تشغيل WSL2 نواة Linux حقيقيّة داخل آلة افتراضيّة خدميّة خفيفة، وحول محاذير استخدامها مع VMware وVirtualBox الحاليَّين. ↩
Microsoft Learn, Windows Sandbox architecture. حول كون Windows Sandbox بيئة Windows خفيفة تجمع تقنيّة الحاويات مع عزل الـ hypervisor. ↩
Microsoft Learn, Windows Hypervisor Platform. حول توفير واجهة وضع مستخدم حتّى يستطيع مكدّس افتراضيّة من طرف ثالث إنشاء أقسام وإدارتها فوق hypervisor Windows. ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. حول إمكان تأكيد حالة تشغيل VBS (الوضع الآمن الافتراضيّ) عبر VirtualizationBasedSecurityStatus على صنف Win32_DeviceGuard. ↩
Microsoft Learn, Install Hyper-V. حول إمكان تفعيل Hyper-V على Windows 10/11 Pro أو Enterprise وما شابه، وعدم إمكان تثبيته على إصدار Home. ↩

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أعماق الافتراضيّة في Windows（الجزء 3）── آلات افتراضيّة تقلع في ثوانٍ: لماذا WSL2 وWindows Sandbox والحاويات خفيفة هكذا

لماذا يبدأ WSL2 وWindows Sandbox في ثوانٍ ويبدوان خفيفَين هكذا؟ يشرح هذا المقال الآليّات، من الصور الأساسيّة الديناميّة والـ direct map ع...

قراءة المقالة

أعماق الافتراضيّة في Windows（الجزء 2）── ذاكرة لا تراها النواة: كيف يعمل VBS وHVCI وCredential Guard

عند تثبيت نظيف على عتاد متوافق، يُفعَّل VBS افتراضيّاً ويستخدم الـ hypervisor وSLAT لإنشاء عزل أقوى من النواة. يشرح هذا المقال بنية VTL و...

قراءة المقالة

واجهة مجمع مؤشّرات الترابط Win32 ── تزامن دون إنشاء مؤشّرات ترابط، عبر CreateThreadpoolWork

هل تنثر استدعاءات CreateThread في شيفرتك الأصليّة؟ يشرح هذا المقال واجهة مجمع مؤشّرات الترابط Win32 التي أُعيد تصميمها في Vista ── كائنات...

قراءة المقالة

الأنابيب المسمّاة عمليّاً ── IPC القياسيّ في Windows من التصميم إلى الأمان

دليل عمليّ للأنابيب المسمّاة، وسيلة الاتّصال القياسيّة بين العمليّات في Windows. ينظّم المقال، من المصادر الأوّليّة، الاختيار بين وضع الب...

قراءة المقالة

معالجة الأخطاء وتصميم إعادة التنفيذ في PowerShell ── من فخّ عدم نجاعة try/catch إلى قواعد exit code وإعادة المحاولة

نرتّب من منظور عمليّ الفرق بين الأخطاء المُنهِية وغير المُنهِية في PowerShell، والفخّ الذي يجعل try/catch غير فعّال والقاعدة الثابتة لـ -...

قراءة المقالة

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

تطوير تطبيقات ويندوز

ندعم تطوير برامج ويندوز للأعمال، وتكامل الأجهزة، وأدوات التواصل.

عرض الخدمة تواصل معنا

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

عندما تفعِّل Hyper-V، أين يعمل Windows المضيف فعليّاً؟: يتولّى الـ hypervisor التحكّم المباشر في كيفيّة تخصيص المعالجات الفيزيائيّة والذاكرة، ويعمل Windows المضيف داخل قسم خاصّ يُسمَّى القسم الجذر. يُعالَج التحكّم بالأجهزة الفيزيائيّة عادةً عبر برامج التشغيل في جانب القسم الجذر. يحتفظ القسم الجذر ببرامج تشغيل الأجهزة ومكدّس إدارة الافتراضيّة، لكن ملكيّة المعالجات الفيزيائيّة تعود إلى الـ hypervisor.
هل تعني «الافتراضيّة: ممكَّنة» في مدير المهام أنّ Hyper-V يعمل؟: لا. يعرض ذلك العرض ما إذا كانت امتدادات الافتراضيّة في المعالج (Intel VT-x/AMD-V) ممكَّنة في البرنامج الثابت. لمعرفة ما إذا كان hypervisor يعمل فعليّاً، ابحث عن «A hypervisor has been detected» في systeminfo، أو افحص Win32_ComputerSystem.HypervisorPresent.
لماذا يعمل الـ hypervisor رغم أنّني لم أُنشئ آلة افتراضيّة قطّ؟: على Windows 11، تُفعَّل الأمان المستند إلى الافتراضيّة (VBS) افتراضيّاً على الأجهزة التي تستوفي الشروط ── تثبيت نظيف على عتاد متوافق مثلاً ── وVBS مبنيّ على hypervisor Windows. الأمر نفسه إن استخدمت WSL2 أو Windows Sandbox. ليس غريباً أن يعمل الـ hypervisor دون أيّ صلة باستخدام أحد للآلات الافتراضيّة.
ما SLAT، ولماذا يُشترَط لـ Hyper-V؟: SLAT (Second Level Address Translation) هي الآليّة التي يترجم بها المعالج العناوين الفيزيائيّة للضيف إلى عناوين فيزيائيّة فعليّة؛ Intel EPT وAMD RVI هما التنفيذان. بدونها سيضطرّ الـ hypervisor إلى صيانة جداول الترجمة برمجيّاً، وهو أمر غير واقعيّ من منظور الأداء، لذا يعاملها Hyper-V الحاليّ متطلَّباً صارماً.
إذا فعَّلتُ Hyper-V، هل يتوقّف VirtualBox وVMware عن العمل؟: لأنّ الـ hypervisor يستخدم امتدادات الافتراضيّة في المعالج حصريّاً، لا يمكن لـ hypervisor طرف ثالث أن يعمل بالطريقة التقليديّة. لكن VirtualBox وVMware الحاليَّين يملكان وضعاً يعمل فوق hypervisor Windows (عبر Windows Hypervisor Platform)، لذا يمكن للإصدارات الحديثة من كلّ منهما التعايش.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.

عرض الملف تواصل معنا

روابط عامة

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

العودة إلى المدونة

«أعماق الافتراضيّة في Windows» ── الأجزاء الثلاثة كلّها

1. الخلاصة أوّلاً

2. من المعالج ── امتياز إضافيّ تحت الحلقات

2.1. تذكير بحماية الحلقات

2.2. امتدادات الافتراضيّة ── وضع محجوز للـ hypervisor

2.3. النوع 1 والنوع 2 ── الفرق هو أين يجلس

3. الأقسام ── وحدة العزل

3.1. أدوار يملكها القسم الجذر وحده

3.2. العالم كما يُرى من قسم ابن

4. من الذاكرة ── ترجمة العناوين تكتسب مستوى إضافيّاً

4.1. ثلاثة أنواع من العناوين

4.2. SLAT ── ترجمة ذات مستويين في العتاد

5. من إدخال/إخراج الأجهزة ── VMBus ونوعان من الأجهزة

5.1. حدود الأجهزة المُحاكاة

5.2. VMBus وVSP/VSC ── مسار سريع مصمَّم للافتراضيّة

6. لماذا هذا ليس شأن غيرك، حتّى إن لم تستخدم آلة افتراضيّة قطّ

7. انظر بنفسك

8. ثلاثة قراءات خاطئة تجنَّبها في العمل

8.1. «لم نفعِّل Hyper-V، لذا الافتراضيّة لا شأن لها بحواسيبنا»

8.2. «مدير المهام يقول «Virtualization: Enabled»، إذن Hyper-V يعمل»

8.3. «إذا كانت الآلة الافتراضيّة بطيئة، فهي مشكلة نظام تشغيل الضيف»

9. الخلاصة

مقالات ذات صلة

مجالات الاستشارة ذات الصلة

روابط مرجعيّة

مقالات ذات صلة

أعماق الافتراضيّة في Windows（الجزء 3）── آلات افتراضيّة تقلع في ثوانٍ: لماذا WSL2 وWindows Sandbox والحاويات خفيفة هكذا

أعماق الافتراضيّة في Windows（الجزء 2）── ذاكرة لا تراها النواة: كيف يعمل VBS وHVCI وCredential Guard

واجهة مجمع مؤشّرات الترابط Win32 ── تزامن دون إنشاء مؤشّرات ترابط، عبر CreateThreadpoolWork

الأنابيب المسمّاة عمليّاً ── IPC القياسيّ في Windows من التصميم إلى الأمان

معالجة الأخطاء وتصميم إعادة التنفيذ في PowerShell ── من فخّ عدم نجاعة try/catch إلى قواعد exit code وإعادة المحاولة

أين يتصل هذا الموضوع

تطوير تطبيقات ويندوز

الأسئلة الشائعة

الملف الشخصي للمؤلف

غو كومورا