VT-x и VT-d: что это такое в биосе и зачем нужно?
Всем приветандр 
Хочу вам рассказать о таком как VT-d и VT-x, что это такое и для чего нужно. В общем ничего особо сложного нет, да и не особо важно это вообще, ну то есть многим юзерам такие опции как VT-x и VT-d попросту не нужны и они могут быть спокойно отключены.
Значит что такое VT-x и VT-d? Это технологии виртуализации, которые нужны для виртуальных машин (может и для еще какого-то софта, но я не знаю). Технологии виртуализации есть как у Intel (VT-x, VT-d), так и у AMD (называется AMD-V) и позволяют виртуальной машине обращаться к процессору напрямую, а не, так бы сказать через программную прослойку. Благодаря этому, виртуальная машина работает почти также как и реальная система.
Обычным юзерам, которые играют в игры, смотрят фильмы на компе, слушают музыку, то им эти технологии не нужны вообще. Поэтому логично их будет отключить. А вот если вы пользуетесь виртуальными машинами, то конечно их нужно в таком случае включить, ибо без них, виртуальные машины хоть и будут работать, но страшно медленно.
Чтобы включить технологию виртуализации, то нужно в биосе найти такое как Virtualization Technology и выбрать значение Enabled, ну примерно как-то так. Просто названия могут отличаться. Вот пример настройки в биосе асусовской материнки:
В более старых биосах все аналогично:
Как VT-x, так и VT-d, все они включаются одинаково. Просто VT-x может просто называться Intel(R) Virtualization Technology, ибо это базовая виртуализация.
Но в чем разница между VT-x и VT-d, в чем отличия то? А вот это уже немного интересно. Как я уже написал, VT-x это базовая виртуализация, она позволяет напрямую слать команды процессору, чтобы виртуальная машина могла работать почти также быстро как и реальная система. А вот VT-d это уже другое, это для того, чтобы вы могли в виртуальную машину перекидывать целые устройства на шине PCI. То есть можно например в прямом смысле кинуть видеокарту в виртуалку и она там будет работать, только нужно будет поставить драйвера на видюху, ну как все обычно. Но VT-d нет в дешевых процессорах, как правило поддержка есть только у более дорогих моделях.
Вообще сама VT-x появилась достаточно давно, ну вот первый раз, если я не ошибаюсь, то она появилась в процессорах Pentium 4, модели 662 и 672. Это одноядерные процессоры, но очень топовые в прошлом, стояли кучу денег! Они одноядерные, но зато имели два потока, что только прибавляло им крутости по тем временам, эх, крутые процессоры были что не говори! 
Как узнать, есть ли поддержка VT-x, VT-d? Очень просто, самый лучший способ, самый быстрый, это просто скачать утилиту CPU-Z, там вы в поле Instructions сможете легко понять поддерживает ли ваш процессор эту технологию:
С процессорами AMD все аналогично, только тут нужно искать AMD-V:
Также в Windows 10 можно легко посмотреть, включена виртуализация или нет. Для этого нужно зайти в диспетчер задач и там на вкладке Производительность у вас будет написано, включена она или нет:
Немного напишу и о самих виртуальных машинах. Значит всего есть две, это самые популярные: VMware Workstation и VirtualBox. Принципиальных отличий у них можно сказать что нет, если не учитывать, что VirtualBox полностью бесплатная. Но лично я отдаю предпочтение VMware, так как она реально быстрее. Но это мое мнение, есть много тех, кто уверен в обратном, что VirtualBox быстрее. Так что я думаю тут будет лишним думать что лучше, ибо лучше просто взять и проверить, как сделал я и уже не один раз приходил к выводу, что VMware таки быстрее.. 
Кстати, у VMware также есть полностью бесплатная версия виртуальной машины, которой я пользуюсь уже не первый год, это VMware Player. Там нет многих функций, но на самом деле, теми многими функциями мало кто пользуется. Все что нужно, это все есть: можно создавать виртуальные машины, редактировать конфиг, запускать машины, все работает стабильно! Нет разве что фоновой работы машины, ну и еще чего-то, так бы сказать не особо существенного.
Кстати, был у меня как-то самый мощный одноядерный процессор, а это Pentium 4 670 (в отличии от модели 672, тут нет виртуализации), ну и я на нем тоже запускал виртуальную машину. Ну потому что это мне ну очень нужно было. Конечно работало все очень медленно. Но тот софт, который мне нужно было запустить в этой виртуальной машине, то он работал. Просто медленно, но все таки работал! Правда этот Pentium 4 670 нагревался просто дико.. Это ужас.. Зимой зато было реально в моей комнате теплее…
Ну в общем вот такие дела ребята, надеюсь что все вам тут было понятно. Удачи вам в жизни и хорошего настроенчика 
Ломаем BIOS: включение поддержки виртуализации VT-x на нетбуке Acer Aspire One
В данной статье мы расскажем вам пошагово о том, как допилить напильником свой нетбук или ноутбук, в котором по какому-то недоразумению выключен и залочен в таком состоянии бит 2 в MSR 0x3A — попросту говоря, у вас есть в процессоре поддержка виртуализации, но она заблокирована биосом.
ПРЕДУПРЕЖДЕНИЕ: всё, описанное в этой статье, рассчитано на то, что вы знаете, что делаете. Всё на свой страх и риск! Если не уверены — не пытайтесь повторить это дома.
Итак, в чем же проблема?
Вот такое сообщение вы можете видеть при попытке запуска виртуалки с числом процессоров, большим чем 1: 
Аналогичное сообщение об ошибке вы также получаете, если собираетесь запускать 64-битную виртуальную машину (например, Debian amd64) с 32-разнядной хост ОС, например WinXP.
Можно ли вылечить это?
На этот вопрос можно ответить, проверив некоторые биты в некоторых словах состояния процессора. Самый простой способ убедиться, что в вашем случае проблема лечится — это посмотреть на то, что показывает программа SecurAble. В моем случае это выглядело так: 
Итак, если у вас программа показывает такую же картинку, как показанная выше, то вы можете вылечить эту проблему. Однако нюанс заключается в том, что это установить нужный бит в регистре процессора можно только в БИОСе, поскольку вредный БИОС вашего ноутбука его выставляет в ноль, потом включает блокирующий бит и изменение этого бита более невозможно (до перезагрузки компа, где БИОС во время POST опять его сбросит и залочит).
Биос на нетбуке Acer Aspire производства Insyde, настройки его очень скудны и по F2 естественно мы не можем зайти в программу редактирования настроек БИОСа и включить виртуализацию там. Это было бы слишком просто.
Поэтому, мы будем дизассемблировать БИОС и менять его код, чтобы у нас бит был выставлен в 1. Если готовы, то читаем далее.
Что нужно знать до начала работы
Итак, некоторая техническая информация — чтобы понимать, что мы делаем и зачем.
Современные процессоры, по крайней мере многие из них, имеют поддержку виртуализации. За нее отвечает бит №5 в слове ECX при вызове команды CPUID с параметром EAX=01H. Именно этот способ проверки — единственно верный, поскольку, как показывает практика, сайт Intel врет, например, для моего процессора Intel Atom N570. По этой ссылке написано:
Однако мы-то знаем, что это неправда. Для тех, кто на «ты» с программированием на ассемблере, не составит труда выяснить это, написав нечто вроде
и проверив потом 5-й бит регистра ECX.
Мне же было лень этим заниматься, поэтому я скачал опенсорсовую программу CPUID Explorer, запустил ее и посмотрел результат. К слову, CPU-Z тут непригодна — она дает результат слишком «юзер френдли» — нам же нужно было узнать точное значение бита. Вот как это выглядело в моем случае: 
В кружочек обведен интересующий нас бит VMX. Он выставлен в 1, он есть, несмотря на то, что говорит нам сайт Intel.
Документация по командам процессора на стр. 215 говорит нам про команду CPUID, что
Bit #5 VMX Virtual Machine Extensions. A value of 1 indicates that the processor supports this technology
Но это еще не все. Чтобы гипервизоры второго типа смогли пользоваться командами поддержки виртуализации (VMX), необходимо явным образом разрешить эти инструкции в MSR (специальном регистре процессора) номер 0x3A. Вот что говорит нам документация по этому регистру на стр. 237:
регистр 3Ah: IA32_FEATURE_CONTROL
Бит 0: lock bit — если он выставлен, то дальнейшие модификации этого регистра не допускаются, до следующей перезагрузки.
Бит 1: VMX в SMX — safer mode extensions. Работа функций виртуализации в SMX допускается только тогда, когда процессор поддерживает SMX — это указывается в соседнем слева, 6-м бите в ECX при вызове команды CPUID.01H — на картинке выше этот бит равен нулю, наш процессор Atm N570 не поддерживает SMX — поэтому и в MSR 0x3A бит №1 должен быть нулевым.
Бит 2: VMX не в SMX — это, собственно, и есть бит, отвечающий за поддержку виртуализации. Он соответствует обведенному в кружочек биту в CPUID и именно он должен быть выставлен в 1.
Как проверить содержимое MSR 0x3A
Чтобы убедиться, что мы все про наш компьютер поняли верно, нужно посмотреть, что на самом деле у нас хранится в MSR 0x3A. Для этого я использовал пакет msr-tools в Debian (реальном, не виртуальном. В виртуальном результат неверный). Вот так вы сможете проверить значение этого бита:
— ребутаемся в Debian, потом:
Девять. Девять это 00001001. Как видим, наш BIOS использует недокументированный бит №3 в специальном слове регистра 0x3A — по документации, этот бит Reserved. Но это не суть. Суть в том, что у нас включен lock bit и выключен наш VMX бит №2 — так что все верно, программа SecurAble не врет и у нас действительно поддержка виртуализации отключена на уровне BIOS, хотя и поддерживается процессором.
Почему эту проблему нужно решать
Дело в том, что при отключенной поддержке виртуализации (VMX) в процессорном слове 0x3A ваши виртуальные машины в VirtualBox работают в режиме паравиртуализации. Они, не имея возможности перевести гипервизор в VMX Root и виртуальную машину в VMX Non-root operation, вынуждены делать трансляцию процессорных инструкций НА ЛЕТУ. Проблему представляют 17 инструкций процессора, которые не «VM-safe», т.е. они используют единственные на весь компьютер регистры или блоки данных (таблицы) в процессоре. Эти команды: SGDT, SIDT, SLDT, SMSW, PUSHF/POPF, LAR, LSL, VERR/VERW, CALL, JMP, INT n, INTO, RET, STR и даже банальная MOV! Все эти инструкции изменяются на лету, чтобы виртуальная машина выполнила их в безопасном для системы виде. Подробнее про эту проблему описано тут (англ.). Из-за этого страдает быстродействие виртуальной машины.
Что нам потребуется
Я проверил этот способ, залив таким образом стандартный биос с сайта производителя (другой версии, чем стоял у меня до этого) — действительно, работает, версия биоса обновилась.
Таким же способом я решил в итоге заливать в систему и прохаченный биос.
Итак, начинаем:
Распаковываем биос из SFX-архива, скачанного с сайта производителя. Сам иос будет иметь имя файла что-то вроде ZE6.fd и иметь размер 2 мегабайта ровно.
Далее нам необходимо распаковать БИОС, поскольку он сжат. Для этого используется программа PhoenixTool.exe. В первое поле в ее окошке мы указываем этот сжатый биос, и программа сама его декомпиляет на, в моем случае, целых 609 исходных файлов, имеющих имена в формате GUID.ext. Часть из этих файлов — конфигурационные, а часть — двоичные, но все с расширением ROM. Некоторые двоичные файлы содержат программы со стандартным виндовским PE заголовком.
Наша задача — среди этих 609 файлов найти файл, содержащий нужную нам инструкцию
оказалось, что искать команду MOV EAX, 3AH перед командой WRMSR бессмысленно — в моем биосе WRMSR оформлена как отдельная функция и принимает параметры через стек. Поэтому я делал это так (мне показалось то проще, чам в IDA): установил на Linux пакет nasm, который включает в себя ndisasm. Потом дизассемблировал все файлы *.ROM командой
И потом простым поиском нашел команду wrmsr в них — таких файлов оказалось 29. Потом пришлось каждый из ни загружать в IDA и искать там нужный код, который лочит регистр 3AH.
Такой код нашелся только в одном файле с именем 62D171CB-78CD-4480-8678-C6A2A797A8DE.MOD, и выглядел этот код так (после некоторой моей работы по переименованию функций в более понятные, и добавлении пары комментов):
По определению, код, который лочит регистр, делает это один раз. Потому это самое удачное место для того, чтобы сделать наш хак: меняем цифру 1 на цифру 5 в инструкции:
Это приведет к тому, что одновременно с выставлением lock bit мы выставляем бит VMX (бит #2). Заметим тут, что мы не имеем права выставлять бит #1, поскольку набор инструкций SMX у нас в процессоре не поддерживается (это говорит CPUID.1H:ECX bit 6.
Менять будем не совсем в файле *.ROM, а в оплетке *.MOD, которая содержит этот файл. Для этого нужно в программе PhoenixTool.exe, которая у нас уже открыта и биос в нее уже загружен, нажать на кнопку Structure, и инайти ветку с нашим именем файла: 
Нажимаем кнопку Extract, получаем файл *.MOD (который состоит из заголовка + тела файла *.ROM), и правим наш бит именно в этом файле MOD. Смотрим в IDA, какой двоичный код соответствует окрестности инструкции, которую мы меняем, и в HEX редакторе открываем файл, ищем это место в коде, и меняем всего 1 байт с 01 на 05. Сохраняем модифицированный файл *.MOD. Потом в PhoenixTool нажимаем Replace, выбираем модифицированный MOD, и нажимаем Exit. Всё. Программа сама пересобрала биос и упаковала его для нас, при этом назвала его тем же именем, что и было (старый файл сохранен с расширением OLD).
Всё. Теперь заливаем единственный файл с новым биосом на USB HDD (можно и на USB флешку), и выполняем описанную выше процедуру аварийного восстановления биоса. Она прошьет комп этом новым биосом и всё будет готово.
Вот как теперь выглядит вывод программы SecurAble: 
Теперь VirtualBox запускает виртуалки с 4 ядрами (а не с одним, как было раньше). Теперь я из-под своей основной 32-разряной операционной системы могу запускать 64-битные операционки в виртуалках.
И, что самое главное, теперь виртуалки на самом деле виртуализованные (гипервизор использует инструкции VMX), а не паравиртуализованные.
P.S. В биосах других производителей (не Insyde) есть возможность править не сам BIOS, а только его настройки, извлекаемые программой SYMCMOS.EXE. Там процесс такой же, за исключением того, что в дизассемблированном биосе находится номер настройки, которая используется для запрещения или разрешения VMX, и потом эта настройка правится непосредственно в CMOS биоса. В моем же биосе таких настроек нет, или программа symcmos их не находит, поэтому такой путь допиливания напильником не подходит в моем случае. Путь непосредственного хака биоса выглядит надежнее: мы таким образом просто игнорируем какие бы то ни было настройки биоса, просто выставляем бит VMX и лочим регистр 0x3A после этого.
Счастье есть 🙂 Спасибо, что дочитали до конца.
Виртуализация¹
В предыдущей части я рассказал о трёх режимах IA-32: защищённом, VM86 и SMM. Хотя их и не принято связывать с виртуализацией, они служат для создания изолированных окружений для программ, исполняемых на процессоре. В этой статье я опишу «настоящую» технологию виртуализации Intel VT-x. Я хочу показать, как теория эффективной виртуализации проявляется в каждом аспекте её практической реализации.
На КДПВ: Запущенная под управлением Ubuntu Linux программа Oracle VirtualBox, в которой запущена операционная система MS Windows XP, в которой исполняется симулятор Bochs, в котором запущена операционная система FreeDOS, в котором запущен симулятор MYZ80 для процессора Z80, в котором загружена операционная система CP/M (в полноэкранном режиме).
В 2006 году Intel представила VT-x — расширение для эффективной виртуализации архитектуры IA-32. Оно включает в себя набор инструкций VMX и два новых режима работы. Я не хочу повторять здесь всю документацию, это очень скучно как писать, так и читать. Однако я опишу некоторые особенности предложенных в ней интерфейсов.
Обойтись для виртуализации уже существующими режимами процессора было нельзя, т.к. некоторое количество существовавших к тому моменту инструкций IA-32 были служебными, но не привилегированными и, согласно теории, их невозможно было бы эффективно перехватывать и эмулировать. Новые режимы были названы root и non-root, и они, в общем-то, ортогональны всем классическим режимам (хотя тут есть особенности, см. дальше). Первый из них — для монитора виртуальных машин, второй — для гостевых окружений. По умолчанию после включения питания виртуализация недоступна. Вход в режим root происходит после исполнения новой инструкции VMXON, а последующие входы в non-root — с помощью VMLAUNCH/VMRESUME.
Ключевой процесс в любой системе аппаратной виртуализации — это сохранение текущего состояния процессора гостя и загрузка состояния монитора. В VT-x здесь всё сделано строго по упомянутой теории. Для хранения состояний как гостя, так и хозяина используется сущность под названием VMCS (англ. Virtual Machine Control Structure). Это структура должна быть своя для каждого активного гостя. На следующем рисунке, иллюстрирующем переходы между режимами root и non-root, внутри VMCS используются две области: состояние гостя (guest-state) и состояние хозяина (host-state).
На этом рисунке событие VM-Entry — это одна из двух инструкций: VMLAUNCH или VMRESUME, — а VM-Exit — одно из множества синхронных и асинхронных событий, объявленных привилегированными в контексте VT-x non-root и потому требующих перехвата монитором. Детали того, что и как загружать при переходе из root в non-root и обратно, также хранятся в VMCS в т.н. VM-entry и VM-exit controls, «параметры входа и выхода». Области сохранения разбиты на поля, каждое из которых хранит в себе регистр или другую архитектурную информацию процессора.
Работа с VMCS
Я хочу показать, как тщательно подошли создатели VT-x к обеспечению версионности и обратной совместимости с будущими реализациями. Ключевой элемент дизайна здесь — это удивительная (учитывая его низкоуровневость) абстрактность предлагаемого интерфейса. Вместо того, чтобы описать раскладку структуры VMCS в памяти и разрешить работать с ней с помощью обычных инструкций LOAD и STORE, были введены две новые инструкции: VMREAD и VMWRITE. И оперируют они не смещениями байт внутри структуры, а кодировками отдельных полей. Более того, не гарантируется даже, что все поля в памяти хранят актуальные значения. Процессор может кэшировать некоторые из них, ускоряя тем самым процесс переключения режимов — данные не приходится подгружать из медленной памяти. Он обязан выгрузить всё в память только при исполнении VMCLEAR.
В результате введения такого уровня косвенности создатели будущих вариантов VT-x не будут привязаны требованиями совместимости раскладки VMCS в памяти с существующими реализациями.
Для сравнения данного метода с альтернативами посмотрите на то, как описывается работа инструкций XSAVE и XRSTOR [1], используемых для сохранения и восстановления векторных регистров. Так как векторные регистры после сохранения хранятся в памяти, смещения для них можно использовать в обычных операциях с ней. А вот для раскладка полей в памяти описана в отдельном листе данных, возвращаемых инструкцией CPUID.
Индикация доступной функциональности
Продолжу рассказ об особенностях VT-x, который удивили меня своей продуманностью (не обо всех расширениях наборов инструкций можно такое сказать). Многие из них касаются идентификации поддержки существующих, а также будущих расширений этой технологии.
Вместо того, чтобы поместить информацию о VT-x в вывод инструкции CPUID, были добавлены новые регистры группы Model-specific register или MSR. Это вполне оправдано — MSRы можно читать только из привилегированного режима, пользовательским приложениям незачем знать об особенностях поддержки виртуализации текущего процессора. О том, что виртуализация поддерживается, сообщает единственный бит CPUID.1.ECX[5].
Версионность и индикация расширений
Описанию механизма индикации поддерживаемых расширений VT-x посвящено приложение A из Intel SDM [1]. Возможность эволюции проходит через все представленные в документации MSRы.
Так, регистр IA32_VMX_BASIC разбит на несколько полей. Одно из них содержит ревизию структуры VMCS. Равенство ревизий двух реализаций VMCS означает равенство размеров областей памяти для их хранения. Выставленный в этом регистре бит 55 означает, что ряд элементов конфигурации, которые в первой редакции VT-x имели жёстко зафиксированные значения (только вкл. или только выкл.), в этой реализации уже могут быть переключены в отличное от первоначального состояние.
Полный список MSRов, описывающих возможности, включает в себя регистры IA32_VMX_(TRUE_)PINBASED_CTLS, IA32_VMX_(TRUE_)PROCBASED_CTLS, IA32_VMX_PROCBSAED_CTLS2, IA32_VMX_(TRUE_)EXIT_CTLS, IA32_VMX_(TRUE_)ENTRY_CTLS. В сумме они определяют, какие архитектурные события могут вызвать VM-exit, что допустимо загружать при VM-entry. Изначально заведённого в первой ревизии VT-x набора регистров оказалось недостаточно, поэтому появились «TRUE»-варианты некоторых из них. По этой же причине PROCBASED_CTLS был расширен с помощью PROCBASED_CTLS2.
В отличие от традиционного подхода, когда под каждую новую фичу заводится один бит в регистре, который означает, поддерживается ли она или нет, в VT-x имеется по два бита на каждое расширение архитектуры. Первый бит означает возможность включения некоторой функциональности, а второй — её выключения. Влияет это на то, какие биты в составе управляющих полей VMCS монитор может модифицировать. Так, например, может оказаться так, что в некоторых процессорах будет нельзя выключить генерацию VT-exit по инструкции RDRAND, а в других, наоборот, нельзя такой выход включить.
Для тех полей, которые могут находиться в любом из двух состояний, программе-монитору разрешается настраивать их под свои возможности и использовать только те, которые были заложены в его логику, даже если монитор запущен на более современном процессоре, предлагающем более эффективные техники.
Данное решение создаёт простор для эволюции как процессоров, так и программ-мониторов виртуальных машин. Первые могут бросить поддержку старых фич, просто обозначив, что они не могут быть включены, а вторые могут детектировать и использовать только ту функциональность аппаратуры, на которую они запрограммированы. Тем самым сохраняется обратная совместимость и обеспечивается прямая совместимость.
Эволюция VT-x
Раз столько усилий было потрачено на поддержку расширений VT-x, таких расширений, наверное, должно быть много. Я расскажу о некоторых из них в этой статье, а остальные попридержу на потом, когда осмысленность их введения станет более понятной.
Но сперва хочется подумать об общем векторе развития VT-x — зачем все эти расширения существуют.
Виртуализация должна быть эффективной, т.е. вносить минимально возможные накладные расходы по сравнению с прямым исполнением гостя на аппаратуре. Это формулируется как «не мешать исполняться как можно большему числу операций». Общий принцип оптимизации — ускорять в первую очередь те подсистемы, что стоят на критическом пути производительности. После устранения главного узкого места нужно переходить к следующему по важности. Рассмотрим порядок важности для вычислительных систем.
Unrestricted Guest
Защищённый режим со включенными сегментацией и страничным механизмом поддерживается с самой первой редакции VT-x. Остальные режимы, в т.ч. 16-битный реальный, запускать напрямую в non-root режиме было невозможно — попытка загрузить такое гостевое состояние с помощью VMLAUNCH/VMRESUME вернулась бы с неуспехом. С одной стороны, это ограничение было разумным — большинство практически важных задач работают именно в защищённом режиме, и следовало виртуализовать его в первую очередь.
С другой стороны, при загрузке традиционной ОС процессор, прежде чем войти в защищённый режим, некоторое время всё же исполняется в других режимах. В мониторе для их поддержки приходилось иметь альтернативный механизм симуляции — интерпретатор, двоичный транслятор, возврат к VM86 или что-то подобное. Это не сказывалось положительно ни на объёме кода монитора, ни на скорости его работы. Поэтому в последующих поколениях VT-x был введён т.н. режим Unrestricted Guest — исполнение гостевых систем, не использующих защищённый режим.
Взаимодействие с SMM
Во время работы root и non-root режимов VT-x всё так же возможно возникновение прерываний #SMI, которые должны безусловным образом переводить процессор в SMM-режим. Процесс переходов в/из SMM-режима был модифицирован, чтобы учитывать специфику работы виртуализации.
К данному моменту я надеюсь, что мне удалось обрисовать мотивацию, основные идеи и направления развития Intel VTx. Здесь я мог бы закончить свой рассказ, но…
Продолжение следует
Если некоторая технология оказывается успешной, то довольно быстро её пользователи начинают придумывать совершенно неожиданные для создателей способы её использования, в т.ч. «неправильные». Не обошло это и виртуализацию. Виртуальные машины заменили физические во многих областях. Их стали объединять в облака, продавать/сдавать в аренду. А конечные пользователи стали запускать внутри выданных им систем свои виртуальные машины. И тут оказалось, что подобный сценарий вложенной (nested) виртуализации не был изначально предусмотрен создателями аппаратуры. Что было сделано для того, чтобы поддержать эффективную работу одних виртуальных машин внутри других на архитектуре Intel — об этом будет следующая часть статьи.
