Журнал «Компьютерра» №32 от 06 сентября 2005 года - Журнал Компьютерра (бесплатные онлайн книги читаем полные версии TXT) 📗
Что такое современный x86-совместимый компьютер? Если кто-то скажет вам, что это довольно простая штука, - не верьте: он просто не знает о чем говорит. Примерное представление о масштабах этой, хм, технологии дает разве что техническая документация - четыре многосотстраничных тома краткой документации по архитектуре IA-32 (The IA-32 Intel Architecture Software Developer’s manual: vol. 1, 2A, 2B amp; 3) и еще два - по ее 64-битным расширениям (The Intel Extended Memory 64 Technology Software Developer’s guide, vol. 1 amp; 2). Впрочем, о последних лучше почитать в первоисточнике - пятитомном издании AMD64 Architecture Programmer’s Manual. Реализовать по этим здоровенным талмудам даже простую имитацию современного x86-процессора - огромная работа; и еще труднее - сделать такую имитацию, которая бы умела более или менее эффективно задействовать для исполнения виртуального кода ресурсы центрального процессора. Даже куда более простая и специально оптимизированная виртуальная машина Java, как известно, работает довольно медленно; надеяться же на чистую эмуляцию средствами центрального процессора чего-либо принципиально более мощного, нежели какой-нибудь ZX Spectrum на процессоре Z80, и вовсе не приходится. Поэтому все современные виртуальные компьютеры идут другим путем - не эмулируя в прямом смысле слова несколько виртуальных ПК, а запуская на одном персональном компьютере несколько операционных систем и ловко «дурача» их, с помощью разных приемов защищая от взаимного «членовредительства» и заставляя «поверить» в то, что кроме них в системе никого нет (рис. 1). Беда в том, что каких-либо приспособлений для подобного рода «надувательства» у этих «виртуализаторов» нет - им приходится выкручиваться, используя для своих целей стандартные методы (IA-32 aka 32-разрядный x86 - весьма гибкая архитектура, и во многих отношениях сделать это оказывается возможным). Однако предусмотреть все ситуации и найти ответы на все возникающие при этом вопросы - практически нереально. Разные ухищрения, на которые приходится пускаться программистам, к сожалению, являются скорее латанием дыр в ветхом днище корабля: для того чтобы кое-как, с половинным ходом доплыть до дока, такого «ремонта» хватает, а вот для длительных морских походов или бурных морей - нет.
Рассмотрим суть возникающих неприятностей на примере так называемой проблемы нулевого кольца исполнения. Кольца (rings, они же уровни приоритета - PLs, Priority Levels) - это такая хитрая система, защищающая центральный процессор от выполнения «посторонними» программами «глубоко системных» инструкций и операций, эдакий «уровень доступа» запущенной программы к системным ресурсам. В IA-32 четыре кольца, от Ring 0 до Ring 3. Чем больше номер кольца - тем меньше приоритет и тем меньше доступно работающей программе. В нулевом кольце запущенный процесс может делать все, что заблагорассудится, - ему предоставлен карт-бланш на любые операции; так что именно в этом кольце «обитает» ядро операционной системы и непосредственно взаимодействующие с оборудованием драйверы. Третье кольцо - сильно упрощенный и ограниченный мирок, в котором запущенный процесс может свободно «жить», но изменить который он не в состоянии. Здесь «живут» всяческие прикладные программы. Кольца 1 и 2 ни Windows, ни *nix-системами принципиально не используются.
В чем же проблема? Оказывается, когда мы «дурачим» виртуальную операционную систему, то не совсем понятно, в какое из колец ее следует помещать. В Ring 0, очевидно, поместить ОС нельзя - проконтролировать ее действия в этом случае не сумеет ни одна живая душа, ибо «воля» исполняющегося в этом кольце кода обсуждению или критике со стороны процессора не подлежит. Поместить операционную систему в «непривилегированные» первое, второе или третье кольца тоже нельзя: любая ОС проектируется, исходя из расчета, что выполняться она будет в нулевом кольце привилегий, а значит, отсутствия необходимого минимума маленьких, но жизненно важных для работы ее ядра инструкций не простит. Вот и приходится программистам либо заблаговременно проверять код на предмет «неблагонадежных» инструкций, ставя на их место вызовы «правильных заменителей», либо отлавливать возникающие при исполнении «неправильных» инструкций ошибки и пытаться их на лету исправлять. Легко догадаться, что реализация и того и другого выливается в большую головную боль для программистов, причем на вроде бы совершенно пустом месте. К примеру, часто «гостевую» операционную систему размещают в неиспользуемом первом кольце… но в расширенном 64-битном режиме процессор не поддерживает кольца 1 и 2, так что все соответствующие наработки «виртуализатор», естественно, отправляет в корзину. Рано или поздно количество проблем переходит в качество - и виртуальные машины становятся не только крайне сложными с программной точки зрения, но и громоздкими, медленными и ненадежными.
Так что же делать? Отказаться от надежды на массовый виртуальный ПК? Конечно, нет! Как минимум, вместо того, чтобы заниматься замысловатой оптимизацией кода для хитроумного обмана операционной системы, можно просто внести некоторые изменения собственно в ОС, видоизменив «наиболее мешающиеся» части ядра. Подобный подход называется паравиртуализацией, он активно продвигается компанией Sun и поддержан движением OpenSource… но эту красивую картинку, к сожалению, успешно портит своими «незаменимыми продуктами» великая и ужасная Microsoft, ибо адаптировать сверхпопулярное ядро Windows NT к реалиям конкретной виртуальной машины может, естественно, только его автор; но так, как делать этого софтверный гигант не собирается (слишком уж многое нужно перелопачивать в ядре), то и сам подход получается если не тупиковым, то, по крайней мере, неполноценным. Поэтому куда интереснее второй, гораздо более простой и универсальный способ - аппаратная поддержка функционирования менеджеров виртуальных компьютеров со стороны процессора, то есть технологии виртуализации. Именно так и поступила Microsoft, разработав в тесном сотрудничестве со специалистами VMWare систему, снимающую основную «головную боль» с разработчиков соответствующего ПО.
Центральная идея Intel Virtualization Technology (ранее известной под названием Vanderpool) - введение в процессор аппаратной поддержки некой специализированной программы - менеджера виртуальной машины (VMM, Virtual Machine Manager) (рис. 1). В принципе, VMM - по всем статьям обычная программа, работающая на персональном компьютере. Однако «права» у этой «обычной» программы самые невероятные, поскольку она может вмешиваться во все мало-мальски значимые события, происходящие в процессоре. То есть, если, скажем, ядро операционной системы (работающее в обычном, ничем не ограничиваемом Ring 0) вызывает инструкцию CPUID, или читает-записывает важный системный регистр CR[Что, впрочем, неудивительно - AMD сегодня отвоевывает себе «место под рыночным солнцем», а для этого ей необходимо предлагать более совершенные и интересные решения], или произошло какое-то внешнее событие, вроде прерывания - то процессор сообщает об этом VMM и… больше ничего не делает, предоставляя VMM право реагировать на возникшее событие самостоятельно. Менеджер виртуального ПК «разбирается» в происходящем, решает, как поступить (например, может, необходимо после нажатия какой-то кнопки переключить CPU на другую запущенную операционную систему), и «программно» имитирует действия центрального процессора в подобной ситуации. Причем отслеживать разные события ему приходится довольно интенсивно: «вручную» маршрутизировать обращения операционных систем к периферийным устройствам, «вручную» загружать и переключать запущенные операционные системы, «вручную» следить за виртуальной памятью запущенных операционных систем, чтобы последние нечаянно не «покалечили» друг друга, считая себя единственными претендентами на имеющиеся физические ресурсы.
