Intel virtualization technology

Содержание

Intel Virtualization Technology (аппаратная виртуализация) на Windows 8.1
VT-x, VT-d, Intel Virtualization Technology в BIOS: что это такое и зачем
Что это такое и зачем это нужно?
Intel и AMD
How to Enable Virtualization in Windows 10 — 2 Ways to Enable VT-x in Bios Settings Easily
Ativando a Virtualização de Processadores da família i da Intel.
Как включить виртуализацию в BIOS?
Intel® Virtualization Technology
Отличие VT-x от VT-d
Как посмотреть свою виртуализацию?
А включена ли виртуализация?
Видео по теме
Виртуализация¹
- VT-x
- VMCS

Я хочу показать, как тщательно подошли создатели VT-x к обеспечению версионности и обратной совместимости с будущими реализациями. Ключевой элемент дизайна здесь — это удивительная (учитывая его низкоуровневость) абстрактность предлагаемого интерфейса. Вместо того, чтобы описать раскладку структуры VMCS в памяти и разрешить работать с ней с помощью обычных инструкций LOAD и STORE, были введены две новые инструкции: VMREAD и VMWRITE. И оперируют они не смещениями байт внутри структуры, а кодировками отдельных полей. Более того, не гарантируется даже, что все поля в памяти хранят актуальные значения. Процессор может кэшировать некоторые из них, ускоряя тем самым процесс переключения режимов — данные не приходится подгружать из медленной памяти. Он обязан выгрузить всё в память только при исполнении VMCLEAR.
В результате введения такого уровня косвенности создатели будущих вариантов VT-x не будут привязаны требованиями совместимости раскладки VMCS в памяти с существующими реализациями.
Для сравнения данного метода с альтернативами посмотрите на то, как описывается работа инструкций XSAVE и XRSTOR [1], используемых для сохранения и восстановления векторных регистров. Так как векторные регистры после сохранения хранятся в памяти, смещения для них можно использовать в обычных операциях с ней. А вот для раскладка полей в памяти описана в отдельном листе данных, возвращаемых инструкцией CPUID.

Intel Virtualization Technology (аппаратная виртуализация) на Windows 8.1

Что делать, если аппаратная виртуализация работала, а на Windows 8Pro и выше перестала? История о том, как я вернул себе Intel VT-x…

Я, как разработчик на Windows и Android, решил себе сменить windows с семерки на восьмерку.
Конечно же решил взять самую последнюю версию (на момент установки — Windows 8.1)

На новой Windows 8.1 по умолчанию включена такая замечательная вещь — Hyper-V.
Кто не знает, что это, поясню: система аппаратной виртуализации для x-64-систем на основе гипервизора.

Но на момент установки я об этом не знал. И пришел к разочарованию, увидев, что моя система не поддерживает аппаратную виртуализацию, хотя мой BIOS и сайт компании Intel утверждали обратное.
На всякий случай проверить можно здесь: ark.intel.com/ru/products/virtualizationtechnology

В обоих случаях мне был дан ответ: NO

Я уж было расстроился, подумал, что надо менять компьютер, но вспомнил, что раньше ведь я мог запускать эмулятор на android с помощью Intel HAXM (кому интересно, данное ПО позволяет значительно ускорить запуск и работу эмулятора Android под Windows — опять же при помощи аппаратной виртуализации).
Поэтому решил разобраться в чем же все-таки дело.

Оказалось, что гипервизор все время работает под хостовой ОС, и только он может контролировать аппаратную виртуализацию, для стабильности.
Поэтому, для того, чтобы все стало на свои места, Вам понадобится запустить командную строку от имени администратора, ввести следующую команду: bcdedit /set hypervisorlaunchtype off
и перезагрузить компьютер. Вот и всё.

Если Вам потребуется все-таки включить Hyper-V, то можно произвести те же самые действия, только вместо off, написать on, то есть bcdedit /set hypervisorlaunchtype on.

Спасибо за внимание.

аппаратная виртуализация
windows 8.1
intel

Виртуализация
Разработка под Android

VT-x, VT-d, Intel Virtualization Technology в BIOS: что это такое и зачем

Приветствую вас на WiFiGid! В этой короткой статье мы обсудим технологии виртуализации, которые доступны почти через любую BIOS: VT-D, VT-X, Intel Virtualization Technology. Простой пользователь очень редко с этим сталкивается, поэтому попробуем сделать это столкновение более мягким, дабы все прошло гладко. Коротко и по делу.

Что это такое и зачем это нужно?

Технологии виртуализации прежде всего нужны для виртуальных машин (во всех их вариациях, может быть и еще для чего, но я встречал только такое применение). Главная проблема виртуализации – виртуальная операционная система обращается к процессору не напрямую, а через прослойку основной операционной системы. Такое «посредничество» не только влияет на производительность, но и вообще на исполнение некоторых инструкций. Итого, технологии виртуализации созданы для того, чтобы виртуальные операционные системы могли напрямую взаимодействовать с процессором без посредника.

Intel и AMD

Оба этих производителя поддерживают технологии виртуализации.

How to Enable Virtualization in Windows 10 — 2 Ways to Enable VT-x in Bios Settings Easily

Intel – VT-x, VT-d
AMD – AMD-V

Ativando a Virtualização de Processadores da família i da Intel.

Это чтобы пользователи не пугались, так как в зависимости от вашего процессора и материнской платы (читаем как BIOS) настройка включения виртуализации может быть названа по-разному.

Как включить виртуализацию в BIOS?

Главная проблема здесь – версий BIOS существует на текущий день уже много. Поэтому показываю что примерно искать, а там эту схему уже адаптируете под себя.

Intel® Virtualization Technology

Заходим в BIOS – классически с помощью клавиши Delete сразу после перезагрузки компьютера. Если не умеете, пользуемся нашей статьей.
Пробегаемся по всем разделам пункта BIOS и ищем пункт, связанный с виртуализацией. Так, например, в одном из вариантов старой версии можно было найти в разделе Advanced пункт «Intel(R) Virtualization Technology».

Отличие VT-x от VT-d

Обе эти технологии созданы для виртуализации – чтобы виртуальной машине было проще получать доступ к железу.

VT-x – базовая виртуализация, в общем случае пробрасывает в виртуальную машину только процессор.
VT-d – расширенный вариант виртуализации на новых процессорах, позволяет пробрасывать другие устройства на шине PCI (например, можно предоставить видеокарту напрямую виртуалке).

Как посмотреть свою виртуализацию?

Если не хочется искать в BIOS, можно посмотреть поддерживаемую виртуализацию процессора через CPU-Z (наверняка использовали уже такую программку, если что – она бесплатная, можете скачать).

На первом же экране сразу смотрим спецификацию процессора (но для новых процессоров вы здесь вряд ли увидите эти классические варианты виртуализации):

А включена ли виртуализация?

Чтобы не лезть в BIOS можно проверить, а включена ли она уже в системе.

Переходим в «Диспетчер задач» ( Ctrl + Shift + Esc ).
Открываем вкладку «Производительность».
Смотрим описание процессора («ЦП»):

Видео по теме

Виртуализация¹

В предыдущей части я рассказал о трёх режимах IA-32: защищённом, VM86 и SMM. Хотя их и не принято связывать с виртуализацией, они служат для создания изолированных окружений для программ, исполняемых на процессоре. В этой статье я опишу «настоящую» технологию виртуализации Intel VT-x. Я хочу показать, как теория эффективной виртуализации проявляется в каждом аспекте её практической реализации.

На КДПВ: Запущенная под управлением Ubuntu Linux программа Oracle VirtualBox, в которой запущена операционная система MS Windows XP, в которой исполняется симулятор Bochs, в котором запущена операционная система FreeDOS, в котором запущен симулятор MYZ80 для процессора Z80, в котором загружена операционная система CP/M (в полноэкранном режиме).

VT-x

В 2006 году Intel представила VT-x — расширение для эффективной виртуализации архитектуры IA-32. Оно включает в себя набор инструкций VMX и два новых режима работы. Я не хочу повторять здесь всю документацию, это очень скучно как писать, так и читать. Однако я опишу некоторые особенности предложенных в ней интерфейсов.

Обойтись для виртуализации уже существующими режимами процессора было нельзя, т.к. некоторое количество существовавших к тому моменту инструкций IA-32 были служебными, но не привилегированными и, согласно теории, их невозможно было бы эффективно перехватывать и эмулировать. Новые режимы были названы root и non-root, и они, в общем-то, ортогональны всем классическим режимам (хотя тут есть особенности, см. дальше). Первый из них — для монитора виртуальных машин, второй — для гостевых окружений. По умолчанию после включения питания виртуализация недоступна. Вход в режим root происходит после исполнения новой инструкции VMXON, а последующие входы в non-root — с помощью VMLAUNCH/VMRESUME.

VMCS

Ключевой процесс в любой системе аппаратной виртуализации — это сохранение текущего состояния процессора гостя и загрузка состояния монитора. В 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 — зачем все эти расширения существуют.
Виртуализация должна быть эффективной, т.е. вносить минимально возможные накладные расходы по сравнению с прямым исполнением гостя на аппаратуре. Это формулируется как «не мешать исполняться как можно большему числу операций». Общий принцип оптимизации — ускорять в первую очередь те подсистемы, что стоят на критическом пути производительности. После устранения главного узкого места нужно переходить к следующему по важности. Рассмотрим порядок важности для вычислительных систем.

Инструкции процессора. Самый важный ресурс — это ЦПУ, и именно на исполнение большинства инструкций без замедления была направлены самая первая версия VT-x. Последующие улучшения в этом направлении были направлены на то, чтобы ещё меньшее число инструкций вызывали VM-exit, а также чтобы все режимы процессора могли быть виртуализованы (см. секции про Unrestricted Guest и SMM далее в этой статье).
Работа с памятью. Здесь частая, но потенциально медленная операция — это трансляция линейных адресов в физические. Её детали и решение описаны в моей предыдущей статье, так что не буду повторяться. В IA-32 соответствующее расширение названо Intel EPT (англ. Extended Page Translation), и оно работает согласно теории. Такой ресурс, как TLB, также требовал виртуализации, и она была обеспечена с введением VPID — техники ассоциации его записей с отдельными гостями.
Виртуальный APIC (англ. Advanced Programmable Interrupt Controller). Контроллер прерываний может оказаться узким местом в производительности монитора, так как нагрузка на него с ростом числа одновременно работающих виртуальных машин (и интенсивности прерываний в системе) растёт. Поэтому было сделано несколько расширений VT-x для виртуализации функций APIC: виртуальная страница памяти для регистров APIC, TPR shadow, CR8 load exiting, virtualize x2APIC mode.
Периферийные устройства, требующие широкой полосы пропускания для своей работы, например, графические ускорители. Для этих устройств требуется эффективно преобразовывать адреса в памяти для DMA, а также обрабатывать прерывания, в обоих случаях делая это с минимальным участием монитора. За эту функциональность отвечает уже не спецификация Intel VT-x, а Intel VT-d [2].

Unrestricted Guest

Защищённый режим со включенными сегментацией и страничным механизмом поддерживается с самой первой редакции VT-x. Остальные режимы, в т.ч. 16-битный реальный, запускать напрямую в non-root режиме было невозможно — попытка загрузить такое гостевое состояние с помощью VMLAUNCH/VMRESUME вернулась бы с неуспехом. С одной стороны, это ограничение было разумным — большинство практически важных задач работают именно в защищённом режиме, и следовало виртуализовать его в первую очередь.
С другой стороны, при загрузке традиционной ОС процессор, прежде чем войти в защищённый режим, некоторое время всё же исполняется в других режимах. В мониторе для их поддержки приходилось иметь альтернативный механизм симуляции — интерпретатор, двоичный транслятор, возврат к VM86 или что-то подобное. Это не сказывалось положительно ни на объёме кода монитора, ни на скорости его работы. Поэтому в последующих поколениях VT-x был введён т.н. режим Unrestricted Guest — исполнение гостевых систем, не использующих защищённый режим.

Взаимодействие с SMM

Во время работы root и non-root режимов VT-x всё так же возможно возникновение прерываний #SMI, которые должны безусловным образом переводить процессор в SMM-режим. Процесс переходов в/из SMM-режима был модифицирован, чтобы учитывать специфику работы виртуализации.

За переход в SMM отвечает особенный вид VM-exit, названный SMM VM exit. Процессы, которые происходят при этом, имеют некоторые отличия от обычных событий VM-exit.
SMM VM exit — единственный вид выхода, который может случиться внутри root-режима, т.е. во время работы монитора виртуальных машин. Обычные VM-exit могут случится только при работе гостей.
Для хранения состояния и управления переходами SMM VM-exit выделяется отдельная VMCS.
Если в классическом случае для окончания работы в SMM-режиме использовалась инструкция RSM, то при включенной виртуализации для этого используется обычный VM-entry, которые возвращается или в монитор (если выход был из root-режима), или в гостевое окружение (в non-root).
Вход в SMM возможен явным образом из root-режима, с помощью инструкции VMCALL, а не только по прерыванию #SMI.

К данному моменту я надеюсь, что мне удалось обрисовать мотивацию, основные идеи и направления развития Intel VTx. Здесь я мог бы закончить свой рассказ, но…

Продолжение следует

Если некоторая технология оказывается успешной, то довольно быстро её пользователи начинают придумывать совершенно неожиданные для создателей способы её использования, в т.ч. «неправильные». Не обошло это и виртуализацию. Виртуальные машины заменили физические во многих областях. Их стали объединять в облака, продавать/сдавать в аренду. А конечные пользователи стали запускать внутри выданных им систем свои виртуальные машины. И тут оказалось, что подобный сценарий вложенной (nested) виртуализации не был изначально предусмотрен создателями аппаратуры. Что было сделано для того, чтобы поддержать эффективную работу одних виртуальных машин внутри других на архитектуре Intel — об этом будет следующая часть статьи.

Литература

Intel Corporation. Intel 64 and IA-32 Architectures Software Developer’s Manual. Volumes 1–3, 2014. www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
Intel Corporation. Intel Virtualization Technology for Directed I/O Architecture Specification. 2013. www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html