Но стоп, - скажет здесь читатель, - а что же будет, если мы запустим две операционные системы и одна из них решит отобрать для своих целей кусочек физического, а не виртуального пространства памяти другой операционной системы, отобразив его в своей таблице трансляции? В обычных условиях это фатальная ошибка, которая быстро приведет две совместно работающие операционки к краху. Но если у нас есть VMM, то ситуация в корне меняется, ибо мы теперь можем запущенную операционную систему «одурачить», перехватив соответствующее обращение и подсунув ей не настоящий CR3, а специально подготовленную «пустышку». ОС, наивно полагая, что она полностью контролирует виртуальную память компьютера, на самом деле будет всего лишь изменять никак не связанную с настоящей таблицей трансляции область оперативной памяти. А обращения к ней, используя стандартные же механизмы виртуальной памяти, будет перехватывать все тот же VMM и синхронизировать в соответствии с ними настоящую таблицу трансляции. Красиво придумано, не правда ли? Собственно виртуальной машины у нас нет, просто мы тщательно контролируем работу операционной системы и при необходимости ловко манипулируем ею.
Набор ситуаций, «прерывающих» выполнение обычных программ и приводящих к вызову VMM, довольно гибко настраивается - вовсе не обязательно, скажем, реагировать на все обращения операционных систем к компьютерным портам ввода-вывода: достаточно указать, какие порты для какой операционной системы будут «выбрасывать» ее к VMM, а какие - работать как если бы VMM не существовало в природе. Причем догадаться о том, что ОС запущена «под неусыпным контролем», практически невозможно: VMM может, например, точно таким же образом фальсифицировать обращения к CPUID (информация о процессоре и поддерживаемых им технологиях), после чего запущенная на Pentium D операционная система будет искренне полагать, что работает, скажем, на Pentium 3 и что никакой поддержки технологий виртуализации этот процессор не предоставляет.
Фальсифицируется все - даже время. Для «подделки» данных счетчика тактов TSC (Time Stamp Counter) в Vanderpool, например, предусмотрен даже не один, а целых два способа - автоматический (к значению TSC прибавляется заданная VMM константа) и «ручной» (перехватываются обращения к RDTSC); аналогично нетрудно перехватить и обращение ОС к системному таймеру с запросом текущего времени. Эдакое «1984» в рамках одного конкретно взятого процессора с VMM в роли Министерства Правды.
В качестве завершающего штриха в описании Vanderpool Technology (VT) приведем блок-схему, поясняющую функционирование технологии и назначение десяти (да-да, всего десяти!) входящих в нее инструкций (рис. 2). Заметим также, что все вышесказанное относилось к варианту VT-x для x86-совместимых процессоров. Кроме нее существует слегка отличающаяся VT-i для процессоров Itanium, но работает она по тем же самым принципам, так что останавливаться на ней я не буду.
Компьютерный мир помешался на совместимости: процессоры Intel и AMD сегодня поддерживают практически идентичные наборы инструкций, а «заклятые друзья» ревниво следят за тем, чтобы процессор конкурента никаких заметных преимуществ перед «родным» процессором не имел. Так, AMD скопировала у Intel набор инструкций SSE (1/2/3); Intel у AMD - 64-битную технологию AMD64 и входящий в ее состав NX-бит: называются они по-разному (SSE у AMD превратилась в 3Dnow! Professional; AMD64 у Intel - в EM64T), но большого значения для ПО это, по сути дела, не имеет. Просто есть некий софт (оптимизированный под SSE ли, под AMD64 - неважно), и производители процессоров стараются сделать все возможное, чтобы этот софт (независимо от того, для какого процессора он разрабатывался) мог запускаться и на их CPU. Из-за этих-то пресловутых требований совместимости до сих пор живет архитектура x86, создававшаяся скорее для микропроцессоров («ноги» i8086 растут из предназначавшегося для калькуляторов i8080) и крайне неудобная для любых современных процессоров (что Athlon, что Pentium вынуждены ее «на лету» преобразовывать в более подходящий для обработки формат). «Хоронили» ее по меньшей мере трижды - в связи с выходом процессоров «правильных» архитектур. Однако ж некогда процветавшие ветви RISC-машин сегодня зачахли, архитектура VLIW не получила должного распространения, а x86 и поныне «живее всех ее хоронивших» - колоссальный парк ПО, накопленного для этой архитектуры, сделал ее практически «непотопляемой». И в свете этого полная несовместимость технологий виртуализации от AMD и от Intel звучит как гром среди ясного неба.