Ответ 1

Эмуляция и виртуализация связаны, но не совпадают.

Эмуляция использует программное обеспечение для обеспечения другой среды исполнения или архитектуры. Например, вы можете запустить эмулятор Android в окне Windows. Окно Windows не имеет того же процессора, что и устройство Android, поэтому эмулятор фактически выполняет приложение Android с помощью программного обеспечения.

Виртуализация больше связана с созданием виртуальных барьеров между несколькими виртуальными средами, работающими в одной и той же физической среде. Большая разница заключается в том, что виртуализованная среда является одной и той же архитектурой. Виртуализированное приложение может предоставлять виртуализированные устройства, которые затем переходят на физические устройства, а хост виртуализации имеет контроль над доступом к виртуальной машине для каждого устройства или части устройства. Фактическое выполнение чаще всего выполняется, но не через программное обеспечение. Поэтому производительность виртуализации обычно намного лучше, чем эмуляция.

Существует также отдельная концепция виртуальной машины, такая как те, которые запускают Java,.NET или Flash-код. Они могут варьироваться от одной реализации до следующей и могут включать аспекты эмуляции или виртуализации или и то, и другое. Например, JVM предоставляет механизм для выполнения байт-кодов Java. Однако спецификация JVM не требует, чтобы байт-коды выполнялись программным обеспечением или что они должны быть скомпилированы в собственный код. Каждая JVM может сделать это самостоятельно, и на самом деле большинство JVMs используют комбинацию как с использованием эмуляции, где это необходимо, так и с использованием JIT, где это уместно (Hotspot JIT, я думаю, это то, что он называл Sun/Oracle JVM).

Ответ 2

В полной эмуляции устройства ввода/вывода, процессор, основная память виртуализируются.

Нет, они эмулируются в программном обеспечении. Эмуляция означает, что их поведение полностью реплицируется в программном обеспечении.

Но что такое полная виртуализация?

С виртуализацией вы пытаетесь запустить как можно больше кода на аппаратном обеспечении для ускорения процесса. Это особенно проблема с кодом, который должен был запускаться в режиме в режиме ядра, поскольку это может потенциально изменить глобальное состояние хоста (машина Hypervisor или VMM работает и тем самым воздействует на другие виртуальные машины.

Ответ 3

Это попытка ответить на мой собственный вопрос.

Системная виртуализация: понимание виртуализации IO и роли гипервизора

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

Виртуализация как концепция позволяет нескольким/разнообразным приложениям сосуществовать на одном и том же базовом оборудовании, не осознавая друг друга.

В качестве примера, полномасштабные операционные системы, такие как Windows, Linux, Symbian и т.д. вместе с их приложениями, могут сосуществовать на одной платформе. Все вычислительные ресурсы виртуализированы.

Это означает, что ни одна из вышеупомянутых машин не имеет доступа к физическим ресурсам. Единственным объектом, имеющим доступ к физическим ресурсам, является программа, известная как "Монитор виртуальных машин" (также известный как Hypervisor).

Теперь это важно. Пожалуйста, внимательно прочитайте и перечитайте.

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

В качестве примера ядро ​​Windows может захотеть запустить физический таймер (системный ресурс). Предположим, что таймер таймера - IO памяти. Ядро Windows выдает ряд инструкций "Загрузить/Сохранить" на адресах таймера. В не виртуализированной среде эти Load/Store привели бы к программированию аппаратного таймера.

Однако в виртуализованной среде эти загрузки на основе Load/Store физических ресурсов приведут к ошибке trap/Fault. Ловушка обрабатывается гипервизором. Гипервизор знает, что окна пытались запрограммировать таймер. Гипервизор поддерживает структуры данных таймера для каждой из виртуальных машин. В этом случае гипервизор обновляет структуру данных таймера, созданную для Windows. Затем он запускает реальный таймер. Любое прерывание, генерируемое таймером, сначала обрабатывается гипервизором. Обновлены структуры данных виртуальных машин и вызываются последние процедуры обслуживания прерываний.

Чтобы сократить длинную историю, Windows сделала все, что она сделала бы в не виртуализированной среде. В этом случае его действия привели к тому, что НЕ обновлялся реальный системный ресурс, а обновлялись виртуальные ресурсы (структуры данных выше).

Таким образом, все виртуальные машины считают, что они обращаются к базовому оборудованию; В действительности неизвестный им, все обращения к физическому оборудованию опосредуются гипервизором.

Все, что описано выше, является полной/классической виртуализацией. Большинство современных процессоров непригодны для классической виртуализации. Ловушка/ошибка не распространяется на все инструкции. Таким образом, гипервизор легко обойти на современных устройствах.

Здесь паравиртуализация возникает. Чувствительные инструкции в исходном коде виртуальных машин заменяются вызовом Hypervisor. Фрагмент загрузки/хранения выше может быть заменен вызовом, например

Hypervisor_Service(Timer Start, Windows, 10ms); 

Эмуляция

Эмуляция - это тема, связанная с виртуализацией. Представьте себе сценарий, в котором программа, первоначально скомпилированная для ARM, запускается для работы на процессоре ATMEL. ЦП ATMEL запускает программу эмулятора, которая интерпретирует каждую инструкцию ARM и эмулирует необходимые действия на платформе ATMEL. Таким образом, эмулятор обеспечивает виртуализованную среду.

В этом случае виртуализация системных ресурсов НЕ выполняется с помощью модели trap и execute.

Ответ 4

Более поздний ответ:

Из моего исследования я могу сказать, что это лучший ответ, чтобы понять, как выглядит концепция:

Первая концепция эмуляции на самом деле восходит к первому компьютеру Colossus. Он использовался британским правительством в 1941 году, чтобы имитировать функции кодовой машины нацистской энтигмы. Теория эмуляции была разработана в 1962 году и была задумана тремя инженерами IBM, работающими с трех разных ракурсов.

Эмуляция означает mimic поведение целевого, которое может быть аппаратным, например эмулятор emu8086, или может быть программным обеспечением, например, эмуляцией услуги из некоторого сетевого порта.

Вы хотите изменить набор функций, предоставляемых целью, и, возможно, вас не интересует внутренний механизм.

Зачем вам это нужно? Для управления этими функциями. Зачем контролировать? По многим причинам, которые очень обсуждаются здесь. Но имейте в виду, что вы хотите быть за вещами.

Но такой процесс является дорогостоящим для производительности. У вас есть инструкция, для которой выполняется множество других инструкций. Возможно, вам интересно контролировать только некоторые из этих инструкций. Поэтому мы хотели бы разрешить выполнение некоторых инструкций native.

Итак, что происходит, когда все это выполнение инструкции стало родным? Тогда у вас есть идеальная виртуализация. Вы можете виртуализировать любое программное обеспечение, но сегодня тренд должен перейти от виртуализации операционных систем к виртуализации приложения. Также я считаю идеальным, потому что это программное обеспечение имеет различное исполнение на каждом аппаратном обеспечении, поэтому необходимо будет также подражать некоторым инструкциям. Важно понять, что большинство технологий виртуализации сегодня не только виртуализируются, но также и о эмуляции.

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

Ответ 5

Без эмуляции или виртуализации код запускается непосредственно на аппаратном обеспечении. Его инструкции выполняются изначально процессором, и его доступ к I/O напрямую обращается к аппаратным средствам.

Виртуализация - это когда гостевой код запускается изначально как минимум в течение некоторого времени, и только ловушки для хоста, выполняющегося за пределами виртуальной машины (например, hypervisor) для привилегированных операций или доступа к вводу/выводу.

Чтобы обрабатывать эти ловушки (например, выходы VM), виртуальная машина может фактически подражать тому, что пытался сделать гость. Например. у гостя может быть драйвер устройства для простой сетевой карты, но сетевой адаптер реализован исключительно в программном обеспечении на виртуальной машине. Если виртуальная машина использовала сквозной проход для отправки гостевого доступа ввода/вывода к реальной сетевой карте на хосте, это будет виртуализация этого оборудования. (Особенно, если он сделал это так, чтобы позволить нескольким гостем использовать его сразу, иначе он просто просто отдает его одному гостю, а не виртуализирует его.)

Аппаратная поддержка виртуализации (как отдельные расширения для виртуализации Intel и AMD) может позволить гостю делать то, что обычно влияет на всю машину, например, изменить сопоставления памяти в таблице страниц. Таким образом, вместо того, чтобы вызывать выход из VM и заставить виртуальную машину определять, что делает гость, а затем модифицировать вещи извне для достижения результата, у процессора просто есть дополнительный слой перевода, встроенный. (См. Связанную статью wiki для многого лучшее, но более длинное описание виртуализации на основе программного обеспечения и аппаратной виртуализации.)

Чистая эмуляция означает, что гостевой код никогда не запускается изначально и никогда не видит "реального" оборудования хоста. Эмулятор не нуждается в привилегированном доступе к хосту. (Некоторым может потребоваться привилегированный доступ к хосту для прохода устройства или для сырых сетевых сокетов, чтобы позволить гостю выглядеть так, будто он действительно подключен к той же сети, что и хост).

Эмулятор ARM, работающий на хосте x86, всегда должен работать таким образом, потому что аппаратное обеспечение хоста не может выполнять команды ARM в первую очередь.

Но вы все равно можете эмулировать гостя x86 на хосте x86, например. Тот факт, что соответствие гостевой и хост-архитектуры не означает, что эмулятор должен воспользоваться этим фактом.

Например, BOCHS - это эмулятор компьютера x86, написанный на портативном С++. Одно из его основных применений - отладка загрузчиков и операционных систем.

BOCHS не заботит, работает ли он на хосте x86 или нет. Это просто программа на С++, которая читает двоичные файлы (образы дисков) и рисует в окне (содержимое гостевой видеопамяти). Что касается хоста, это не особенно отличается от просмотра JPG или игры.

Некоторые эмуляторы используют двоичный перевод для JIT-компиляции гостевого кода в код хоста, но это все еще эмуляция, а не виртуализация. См. http://wiki.osdev.org/Emulator_Comparison.

BOCHS относительно медленный, поскольку он читает и декодирует гостевые инструкции напрямую, не выполняя двоичный перевод. Но он пытается сделать это максимально эффективно. См. Как работает Bochs Under Hood для некоторых трюков, которые он использует для эффективного отслеживания состояния гостя. Поскольку эмуляция является единственной опцией для использования программного обеспечения x86 на оборудовании, отличном от x86, полезно иметь высокопроизводительный эмулятор. В BOCHS работают очень умные и опытные разработчики эмуляторов, в частности Darek Mihocka, у которых есть интересные статьи об оптимизации эмуляции на его сайте.