Вторая принципиальная «фича» AMD’шной виртуализации - это Tagged TLB, тегированный кэш трансляции виртуальных адресов. TLB представляет собой буфер, позволяющий процессору не заниматься каждый раз чрезвычайно трудоемкой и медленной процедурой преобразования виртуального адреса в физический, а сделать это единожды и впоследствии быстро обращаться к уже вычисленным парам соответствия «виртуальная память - память реальная». Понятно, что при каждом переключении от одной программы к другой (не говоря уже о переключении от одной операционной системы к VMM и обратно), когда процессору приходится переключаться между разными виртуальными пространствами памяти, этот буфер со всей ранее накопленной информацией приходится сбрасывать - в новом виртуальном пространстве старым виртуальным адресам будут соответствовать совсем другие «физические». А значит, каждое переключение к VMM и обратно - это вопиющее расточительство процессорных ресурсов, десятки и сотни тысяч потраченных на восстановление потерянной информации тактов. В реализации AMD буфер TLB запоминает, какой из виртуальных операционных систем какой адрес принадлежит. В обычной ситуации запоминать эту информацию бессмысленно - при переключении задач TLB все равно быстро заполнится новыми адресами, вытесняющими старые; а вот для быстрого переключения от OS к VMM и обратно (когда, возможно, работа VMM не займет и сотни тактов процессорного времени) подобная оптимизация приходится как нельзя более кстати.

Следующий приятный «пунктик» в программе AMD - аппаратная защита контроллера DMA. В обычных условиях этот контроллер позволяет периферийным устройствам работать с оперативной памятью, не привлекая центральный процессор. Например, CPU может не заниматься рутинной и монотонной задачей передачи данных неторопливому винчестеру, а скинуть всю необходимую для сохранения информацию в оперативную память, сообщить жесткому диску, что, откуда и куда сохранять из памяти на диск - и, не дожидаясь окончания этой операции, заняться каким-либо другим делом. Это удобно, это быстро, но в то же время это грандиозная дыра в безопасности в тех случаях, когда две операционные системы, запущенные на одном компьютере, требуется изолировать друг от друга. Ведь никаких проверок на то, что периферийное устройство может запросить совершенно «левый» адрес физической оперативной памяти (если, допустим, по некоей договоренности между драйвером и устройством, по во-о-он тому физическому адресу вроде бы ничего не должно располагаться и его можно использовать как вспомогательный буфер при работе), DMA обычно не производит. Специалисты AMD это упущение исправили - теперь все устройства могут быть разбиты на несколько виртуальных доменов (изначально - по четыре домена на каждый процессор), а DMA-контроллер может проверять, разрешено ли устройству из такого-то домена чтение данных из такой-то области памяти.

Наконец, AMD уже сегодня предоставляет основную часть возможностей еще даже неопубликованной технологии защиты данных Intel LaGrande, а именно - «безопасный» запуск виртуальной операционной системы. Не зря же Intel называет свою технологию VT, а AMD свою - SVM (Security amp; Virtual Machine). Если быть более точным, то специальная инструкция SKINIT позволяет процессору запускать гарантированно безопасный загрузчик - крошечный (64 Кбайт) кусочек подписанного цифровой подписью кода, который затем может проверить и загрузить «безопасный» VMM или «безопасное» ядро обычной операционной системы. Сам загрузчик проверяется специальным аппаратным модулем TPM (которые уже активно устанавливаются в серийные материнские платы), ну а дальнейшая проверка надежности загружаемого этим загрузчиком кода - целиком и полностью лежит на собственно загрузчике. В результате появляется возможность настроить компьютер так, чтобы загружающийся при старте компьютера VMM и (или) запускаемые им операционные системы соответствовали некоторому заданному и аппаратно прошитому «стандарту» (это, например, может гарантировать, что обладающий широчайшими возможностями VMM не станет «шпионить» за клиентским ПО, а на «брэндовом» компьютере запустится только подписанная лицензионная копия MS Windows).

AMD Pacifica пока не в полной мере поддерживает виртуализацию устройств ввода-вывода (как распределить между виртуальными операционными системами реальную периферию - головная боль VMM), как и не в полной мере обеспечивает безопасность каналов ввода-вывода (проще говоря, от подцепленного к периферийному кабелю «жучка» такая защита не спасает), однако все равно можно утверждать, что все принципиально важные вопросы защиты операционных систем и эффективной виртуализации она решает. У корпорации Intel в последнее время и без того хватает неудач, так что я бы очень хотел написать, что черная полоса для нее уже закончилась и анонсированная гораздо раньше конкурента технология виртуализации позволяет ей наконец-то вырваться вперед, но… Да, Vanderpool - замечательная технология, однако Pacifica обходит ее по всем основным показателям.

Не будем сейчас затевать споры о том, чье решение лучше и перспективнее. Со своей главной задачей - запуском произвольного количества виртуальных операционных систем и обеспечением их эффективной одновременной работы - справляются обе технологии, а за Intel стоит все-таки больший сегмент рынка. Вариант AMD смотрится гораздо интереснее, однако для поддержки всех своих возможностей он требует специально заточенных «под AMD» менеджеров виртуальных операционных систем, принципиально несовместимых с Intel Virtualization Technology. Чтобы совсем уж явно не проводить «водораздел» между VMM «для Intel» и «для AMD» (все-таки VMM - очень сложное и трудоемкое программное обеспечение), в Pacifica предусмотрен специальный, скажем так, «режим совместимости» SPT, в котором двойная трансляция адресов виртуальной памяти отключена и VMM «для Intel» можно с небольшими переделками превратить в «урезанный» VMM «для AMD»[Который, правда, даже в таком варианте получается более совершенным и «интересным», нежели Vanderpool. Инженеры AMD, как обычно, сделали все, чтобы обойти коллег из Intel]. Клиентское ПО и операционные системы переделывать не придется и подавно: с «потребительской» точки зрения VMM в компьютере вроде бы как и не существует.

Первые процессоры Intel с поддержкой VT-x должны появиться уже в этом году: по крайней мере, в начале года обещания о поголовной «виртуализации» Pentium 4 прозвучали, а новые семейства чипсетов i945-i955 эту технологию поддерживают уже сейчас. Правда, судя по срокам анонса VT-x для процессоров Xeon (первый квартал 2006 года), возможно, мы увидим эту технологию только в 65-нм процессорах Intel. Зато как в десктопных, так и в мобильных: будущий двухъядерный Pentium M «Yonah» будет поддерживать Vanderpool. Технология VT-i тоже должна появиться в новых процессорах Itanium 2 в конце этого года.

AMD обещает поддержку Pacifica в своих новых процессорах начиная с первого квартала следующего года - а именно в Athlon 64, предназначенных для Socket M2 и рассчитанных на использование оперативной памяти DDR2. Тогда же Pacifica появится и в серверных процессорах Opteron.

С менеджерами VMM, которые фактически должны стать обязательным дополнением к операционной системе для ПК, все куда туманнее - своих решений пока не представил ни один из вендоров. Хотя, без сомнения, VMM наверняка выпустят компании Microsoft, VMWare и кто-нибудь из сообщества OpenSource. Кстати, последнему, вероятно, будет светить самое радужное будущее - даже если Microsoft, как обычно, сделает свой продукт бесплатным.

Давний главный редактор «Компьютерры» Георгий Борисович Кузнецов попал однажды в довольно замысловатую ситуацию, которую, разрешив, и описал. Крутой по тем временам американский модем Георгия Борисовича (Courrier, сколько помнится) стал вдруг, ни с того ни с сего, рвать связь. Чего только Кузнецов ни проверил тогда, чего ни перепробовал, пока ему не пришло в голову взять в руки вольтметр и померить напряжение в электрической сети. Оно оказалось где-то в районе 205 вольт, и заморский модем принял это за свинство, в условиях которого ни один порядочный прибор работать не станет. Хотя бы по чисто принципиальным соображениям.