AMD Pacifica, Intel VT

да.

То есть если в гостевой ОС можно исполнить код гипервизора и получить рекурсивно вложенную виртуализацию?

Неограниченно вложенную, лишь бы памяти хватило?

нельзя - гипервизор исполняется в ring -1, а самый высокий уровень привилегий, доступный виртуальной машине - ring 0

Значит виртуализация все-таки неполная и самым важным признаком работы в виртуализированной среде является невозможность запустить внутри нее виртуальный аппаратный виртуализатор?

по такому критерию любая виртуализация неполная

Что мешает виртуализировать механизм виртуализации?

здравый смысл - тратить площадь кристалла (=> увеличивать тепловыделение и энергопотребление) просто так никто не будет

> здравый смысл - тратить площадь кристалла (=> увеличивать тепловыделение и энергопотребление) просто так никто не будет

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

без аппаратной поддержки это будет работать ужасно медленно, примерно как виртуальная память без MMU

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

каждый раз, когда ты вводишь абстракцию потока исполнения, тебе надо думать о сохранении и перезагрузке контекста => чем больше уровней абстракции, тем больше уровней контекстов

>Процессору нужно только разрешить перехватывать команды для виртуализации, поступающие "снизу"

А это вроде уже есть.

этого нет, потому что быть не может - см. выше про контекст

Я имел в виду, что когда какая-нибудь гостевая система пытается выполнить инструкции типа VMRUN и других для виртуализации (и они ей могут быть разрешены), хост получает об этом уведомление (путём спецпрерывания, кажись) и может что-нибудь сделать.

предоставление гостям возможности выполнять эти инструкции не отменит того факта, что любая виртуализация есть запуск нескольких однородных сущностей на одном процессоре с одним потоком исполнения, это значит, что в один момент времени на одном процессоре (некоторые фишки вроде логических потоков, сделанные для загрузки конвееров полезной работой на время обработки непопадания в кэш или сглаживания косяков встроенного в проц out-of-order планировщика, не считаются) всегда будет исполняться только один гость, а внутри этого госта - один процесс ОС, иллюзия совместного исполнения достигается за счет постоянной смены контекста, что довольно таки дорогая вещь, особенно если контексты вложены один в другой много-много раз

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

О производительности речь, вроде, не идёт. Хотя, если дело в безопасности, то проще подменить гостю модель процессора, чтобы он думал, что виртуализация не поддерживается аппаратно, и не пытался её применить для проверки на виртуализированное окружение — ведь первые интеловские реализации AMD64 были без поддержки виртуализации, надо ими и прикинуться.

проще процессору кидать исключение "недопустимая инструкция" и все (так обычно и происходит, кстати)

Правильно, но речь шла о том, чтобы сделать абсолютно необнаружимой виртуализацию. Вдруг какая-нибудь следующая версия, например, МакОС не будет запускаться без поддержки инструкций виртуализации, исключительно в качестве примитивной защиты от использования не по назначению? (Понятно, что её «пропатчат», но это так, теоретическое предположение.) Или Майкрософт, выпустив специальную версию лицензии винды для использования в виртуальной машине, заставит все остальные проверять, не находятся ли они в виртуализированном окружении. И подмена модели процессора может не помочь, так как сравнительно мало существует процессоров x86-64 без виртуализации, и от их поддержки можно отказаться (ведь 32-х битный x86 уже Windows 7 не будет поддерживать вроде).

> Иначе говоря, можно ли используя их сделать 100% виртуализацию, в теории необнаружимым сам факт виртуализации?

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

Кстати AMD-V или Intel VT-x для достижения такой цели не обязательны. :)

> нельзя - гипервизор исполняется в ring -1, а самый высокий уровень привилегий, доступный виртуальной машине - ring 0

Анонимус жжот. :D

> Хотя, если дело в безопасности, то проще подменить гостю модель процессора, чтобы он думал, что виртуализация не поддерживается аппаратно, и не пытался её применить для проверки на виртуализированное окружение — ведь первые интеловские реализации AMD64 были без поддержки виртуализации, надо ими и прикинуться.

Узко мыслите. :) У процессоров есть features bits, которые он отдает по CPUID (при 1 или 0x80000001 в EAX). Вот ими и надо манипулировать, а модель процессора можно и нативную отдавать.

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

> иллюзия совместного исполнения достигается за счет постоянной смены контекста, что довольно таки дорогая вещь, особенно если контексты вложены один в другой много-много раз

Любопытная тема.

Но я тоже не понял как рекурсивная виртуализация усложнит проц или отожрёт чересчур много ресуросов?

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

Ресурсы она конечно стала бы потреблять, но не более чем ещё одна виртуальная машина внутри хоста. Здесь, конечно могут возникнуть дополнительные сложности с безопасностью, но в первом приближении я тоже не вижу лишнего усложнения или сильного падения производительности.

> Анонимус жжот. :D

Тема вообще видимо возникла из-за незнакомства с официальной документацией, я её тоже не знаю :) но думаю надо предварительно почитать прежде чем утверждать, что может или не может сабж.

> И подмена модели процессора может не помочь, так как сравнительно мало существует процессоров x86-64 без виртуализации, и от их поддержки можно отказаться

Процессоров без HVT много -- это Celeron, Pentium Exxxx, Core 2 E4xxxx, Sempron. Скажу вам по секрету: идеального виртуализатора нет. Так или иначе каждый можно отдетектить, даже если проц прикинется валенком. :) Могу рассказать как, если интересно.

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

> Ресурсы она конечно стала бы потреблять, но не более чем ещё одна виртуальная машина внутри хоста. Здесь, конечно могут возникнуть дополнительные сложности с безопасностью, но в первом приближении я тоже не вижу лишнего усложнения или сильного падения производительности.

Рассмотрим пример. Пусть у нас есть базовая система (хост). Все вложенные системы удем называть гость-1, гость-2 и т.д. Для определенности будем считать, что у нас Intel. Так вот, гость-2 записал в VMCS какое-то свое значение. Как мы (VMM, запущенный поверх каждого уровня систем) должны реагировать на это? Правильно, записать это значение в какую-то свою структуру, чтобы при исполнении гостем команды VMLAUNCH/VMRESUME загрузить в физический VMCS это самое значение, иначе нативное исполнение кода невозможно. И так со всеми полями! Т.е. мы будем вынуждены выходить в монитор базового уровня при каждом виртуализационном событии на любом уровне вложенности, плюс каждый уровень должен управлять виртуализацией всех других уровней, лежащих выше него. Круто, да? :)

> Тема вообще видимо возникла из-за незнакомства с официальной документацией, я её тоже не знаю :) но думаю надо предварительно почитать прежде чем утверждать, что может или не может сабж.

Я с ней знаком, работаю как раз в этой области. Не вижу каких-то принципиальных препятствий для сабжа, если укажете на них, буду признателен. :) Более того, Интел даже высказал нам пожелание, чтобы мы реализовали виртуализацию VT-x. Ввиду нецелесообразности мы этого делать не стали.

> Т.е. мы будем вынуждены выходить в монитор базового уровня при каждом виртуализационном событии на любом уровне вложенности, плюс каждый уровень должен управлять виртуализацией всех других уровней, лежащих выше него. Круто, да? :)

Никто и не говорил, что будет легко :) Речь зашла о самой возможности и потреблении ресурсов в смысле предполагаемых тормозов.

Касательно программирования гипервизора я тут не очень компетентен, мягко говоря, моё знакомство с ассемблером закончилось давно как раз на VMM 386-ого проца , и рассуждаю более из общих соображений, но неужто нельзя выдумать какой-нибудь трюк? Например, использовать тот же принцип, что и с хвостовой рекурсией?

> Более того, Интел даже высказал нам пожелание, чтобы мы реализовали виртуализацию VT-x. Ввиду нецелесообразности мы этого делать не стали.

То есть, написать рекурсивный гипервизор для VT-x всё же можно или у вас как раз сам VT-x и разрабатывали по заказу Intel?

> Никто и не говорил, что будет легко :) Речь зашла о самой возможности и потреблении ресурсов в смысле предполагаемых тормозов.

Тут есть еще такой момент -- по всем железячным прерываниям надо генерировать VM exit, иначе мы завесим хост. Прерывания от таймера валятся довольно часто и при n-ом уровне вложенности у вас неизбежно возникнет ситуация, когда процессор будет занят только обработкой прерываний, а гостевой код практически не будет исполняться. Прерывания начнут теряться, TSC сильно убежит вперед, начнут отваливаться девайсы и вся эта радость схлопнется.

> неужто нельзя выдумать какой-нибудь трюк? Например, использовать тот же принцип, что и с хвостовой рекурсией?

Можно в принципе отдавать обработку VM exit'ов не напрямую в исполняющийся виртуальный монитор, а по цепочке. Накладные расходы возрастут еще сильнее. Для справки: VM exit -- VM entry занимает примерно 4000 тактов на Core Duo 1.8GHz. Т.е. операция эта весьма не дешевая. :)

> То есть, написать рекурсивный гипервизор для VT-x всё же можно или у вас как раз сам VT-x и разрабатывали по заказу Intel?

Теоретически -- можно, практически -- очень сложно, да и не особо надо. Мы -- коммерческая контора, занимаемся виртуализацией еще со времен когда не было VT-x. VT-x разрабатывали инженеры Intel, но они прислушиваются к пожеланиям основных виртуализационных вендоров (которых в общем-то всего 4, считая нас), за что Интелу безусловный респект. Вот этим летом например наше начальство ездило к Интелу обсуждать следующий этап виртуализационных технологий -- VT-d -- для девайсов (в основном видеокарты и сетевухи, но в перспуктиве USB и пр.), сейчас мы уже работам над этой поддержкой. AMD тоже учитывали пожелания, но сейчас они виртуализационную технологию практически забросили и развивать не собираются. Не до этого им, а жаль. SVM удобнее, но существенно медленнее.