Из того, с чем я сталкивался: зашел к знакомому в гараж, у него сидит разработчик и пилит CRM систему с помощью Cursor. Знакомый не айтишник, просто решил попробовать, что из этого выйдет, а вдруг. Коллеги на работе хотят внедрять модели для обработки микросервисов. Здесь https://github.com/github/spec-kit/blob/main/spec-driven.md заявляют о появлении исполняемых спецификаций (executable specifications), 54k звездочек. Встречал несколько статей, где кодогенерацию с помощью LLM приравнивают к метапрограммированию.
Общее впечатление: часто выдается желаемое за действительное, происходит замена инженерного решения сложных проблем на легкие пути. Все-таки, чтобы эффективно встраивать LLM/ИИ в процессы нужны уже имеющийся высокий уровень организации процессов и глубокое понимание возможностей LLM/ИИ.
virtualization is a series of technologies that allows dividing of physical computing resources into a series of virtual machines, operating systems, processes or containers
Full virtualization was not fully available on the x86 platform prior to 2005. Many platform hypervisors for the x86 platform came very close and claimed full virtualization
In 2005 and 2006, Intel and AMD (working independently) created new processor extensions to the x86 architecture called Intel VT-x and AMD-V, respectively
А насчет контейнеров могу сказать, что они не позволяют обеспечивать должный уровень изоляции и безопасности из-за того, что пользуются общими абстракциями виртуальной машины, предоставленными единым ядром ОС. Поэтому, появляются еще подобные гибриды
https://firecracker-microvm.github.io/ Firecracker enables you to deploy workloads in lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers.
Похоже, то, что Вы называете "настоящей виртуальной машиной" по-другому называется "полной виртуализацией" (full virtualization) или классической виртуализацией (classical virtualization).
Если изоляция -- не с помощью ручного перетыкания кабелей и перещёлкивания переключателей, то возможна, если я правильно понимаю, что такое "живая миграция".
Здесь в самом термине live migration уже подразумеваются именно операция с виртуальной машиной. А я имел ввиду, если, например, в LPAR1 работает ОС, можно ли её перенести в LPAR2, оставляя её на период переноса работающей со всеми процессами, и при этом не задействуя никакой виртуализации PR/SM, только конфигуратор оборудования.
Как я догадываюсь, ответ здесь да, и операция переноса заключается в подключении новых (из LPAR2) процессора, памяти и т.д. и освобождении старых, чтобы полностью отключить LPAR1.
Но тогда, похоже, виртуализация - это неотъемлимое свойство самой такой ОС, раз она позволяет подобные вещи.
Тогда можно переформулировать вопрос: если в LPAR1 будет работать другая ОС, которая сама не поддерживает такую миграцию, можно ли её перенести в LPAR2, не задействуя возможности виртуализации PR/SM?
Нет, но вместо него есть вполне приемлемая альтернатива. Вот, из похожего обсуждения
as long as the hypervisor is competently configured, respecting memory and IO adjacency (NUMA, AMP) and pinning threads to cores to eliminate sched overhead, as well as taking advantage of UEFI features like PCIe passthrough, performance of current hypervisors are easily 99+%
Уквжите где я утверждал что в х86 "все" (что "всё"?) не "выполняется на чистом железе".
Так эта мысль во всей Вашей статье. Вы зачем-то вводите лишние сущности "настоящая виртуальная машина" и "виртуальная система" (в случае x86). Когда я пытаюсь с помощью сравнений для обоих случаев проследить всю иерархию уровней абстракции вплоть до железа, чтобы таки понять, что именно Вы имеете ввиду, словно бы наталкиваюсь на стену, будто мы с Вами находимся в разных партициях.
Насколько я понял, в мейнфрейме функции гипервизора PR/SM относительно бесшовно (именно за счет преимуществ архитектуры IBM по сравнению с x86 такая бесшовность возможна) интегрированы с функциями конфигуратора оборудования (аналога переключения рубильников и кабелей). И тут, действительно, легко запутаться и перестать понимать, где кончается виртуализация и начинается изоляция железа исключительно с помощью конфигурации.
Чудесно, когда можно полностью избавиться от слоя виртуализации, организуя все только с помощью партиционинга. Но вот проблема: живая миграция, например, в этом случае будет невозможна.
Что будем делать?
Вернемся к основам. Попытаемся понять, что именно можно считать подлинной виртуализацией, а что - таковой не является. И нужна ли она вообще?
Хорошо, что Вы сказали об эпизодичной роли гипервизора PR/SM. Тогда мы можем признать, что на платформе x86 можно аналогично использовать низкоуровневый гипервизор только для разовой привязки систем к железу и для последующих миграций. И накладные расходы, связанные с виртуализацией x86, будут также разовыми, а не постоянными. Или этому мешает "ненастоящность" виртуализации x86?
Таким образом, остается сравнивать программные гипервизоры z/VM и их аналоги на x86. Об этом я уже неоднократно упоминал, не хочется повторяться. Преимущество платформы IBM по сравнению с x86 в эффективности. Но структурно эти 2 вида виртуализации эквивалентны между собой также, как вычислительный процесс на виртуальном оборудовании эквивалентен вычислительному процессу на физическом.
Какие-то абстракции, которые можно реализовать на МФ, невыгодны и практически невозможны на x86. И вместо них применяются другие, которые лучше соответствуют ограничениям. Но в обоих случаях применяются общие подходы. Основанные на теории процессов, если хотите.
Привидите пример такой программы.) , то даже тогда все это будет выполняться на "чистом железе". PR/SM в этом не участвует, это дело монитора z/VM.
Повторю мысль, что "Вы не поверите, но в x86 тоже все в конечном итоге выполняется на чистом железе". Дело в том, какими путями оно добирается до железа, какие при этом расходы и от чего приходиться отказаться. Пример очень простой: подбираются соответствующие инструкции 2 типа и в пару к ним инструкции, отменяющие предыдущую, чтобы соблюдалась идемпотентность. И все это гоняется в параллельных циклах, насыщая по максимуму пропускную способность программного гипервизора.
Попробую дополнить, исходя из своего понимания, не претендующего на какой-то высокий профессионализм. Сначала цитата:
...каждая из этих инструкций может быть выполнена в пользовательском режиме, не вызывая ловушку для операционной системы, но влияет на то, как операционная система (гостевая) управляет своими ресурсами...Чтобы обойти проблему эмуляции всех подряд инструкций, снижающую производительность, подход, реализованный в виртуальной машине VMWare [Sugerman et al., 2001], состоит в том, чтобы сканировать исполняемый файл и вставлять код в непривилегированные конфиденциальные инструкции, чтобы перенаправить управление на монитор виртуальной машины. Там будет происходить соответствующая эмуляция, например с учетом контекста, в котором должна была выполняться инструкция. В результате может произойти полная виртуализация, а это означает, что выполнение может происходить без изменения гостевой операционной системы или самого приложения.
Т.е. само по себе появление такой инструкции, как описываемая EPSW, не катастрофа. Поскольку разработчикам z/ системы достаточно применить компенсацию с помощью подхода, подобного описываемому выше или какого-то иного. Поскольку они полностью контролируют происходящее в их гипервизорах, то добавление такого обхода лишь в какой-то мере ухудшит производительность, сохранив при этом корректность виртуализации.
Это все лишь мои предположения относительно того, что на самом деле происходит в реализации системы, а не в её модели, описываемой "Принципами работы". Если компенсация реализована, то все инварианты сохранены и "Принципы работы" остаются справедливыми.
Без capping (бокс "Initial capping" не выбран) это также означает что если остальные партиции не выполняют ничего то 100% времени будет предоставленно этой партиции. Это все делается PR/SM.
Да, это хорошая демонстрация того, что я имею ввиду. Конфигурируемой партиции могут быть предоставлены как dedicated processors (выделенные физические CPU), так и виртуальные CPU, задаваемые, например, с помощью Absolute Capping -> Number of processors.
Системе, занимающей партицию, приходится пользоваться теми абстракциями, которые ей предоставили. Ей дали, например, либо один полноценный физический CPU, либо какую-то долю физического CPU, моделируемую логическими (виртуальными) CPU. И в некоторых ситуациях (например, связанных с высокопроизводительными вычислениями) это существенное отличие: одно дело владеть CPU монопольно, другое дело - иметь под капотом диспетчеризацию логических CPU.
Когда я говорю про сокрытие информации при абстрагировании оборудования для следующего уровня, я подразумеваю именно подобные ограничения. Вам приводили пример с сетевой картой и вы сослались на переписывание канальной программы https://habr.com/ru/articles/962262/comments/#comment_29051240 Это тоже 2 большие разницы: иметь монопольный полный доступ к устройству и иметь некоторую абстракцию (виртуальное устройство), реализуемую нижележащим уровнем, пусть хоть бы и с помощью канальной программы.
Сокрытие конфиденциальной информации при виртуализации отдельных инструкций CPU имеет похожие последствия с той разницей, что в отличии от случая физических/логических CPU, где допустимы оба варианта (гостю можно предоставлять как полный физический CPU, так и логические CPU с диспетчеризацией), скрывать некоторую информацию, касающуюся выполнения инструкций, от гостевой системы обязательно. Иначе может произойти утечка абстракции и нарушение безопасности. Мы с @SIISIIпытаемся донести эту мысль, но сталкиваемся с непониманием.
Точно не так. Ничего на МФ от ОС партиций не скрывается. Более того ОС партиций имеет доступ к "железу" через Base Control Program internal interface (BCPii)
Я понимаю, что Вы имеете ввиду. Для ОС партицией обязательно гарантировать, что вычислительный процесс при использовании виртуализации оборудования должен быть эквивалентен вычислительному процессу на чистом железе bare-metal. На этом все держится, иначе какой смысл. Но побочные эффекты, все же, возможны. Начиная от потерь производительности из-за диспетчеризации и заканчивая возможным раскрытием абстракции при чтении того, что знать не положено.
Напоследок приведу гипотетический пример, демонстрирующий намеренно неудачное стечение обстоятельств. Пусть z/VM работает поверх PR/SM, причем на логических CPU с диспетчеризацией от PR/SM. И пусть она также задействовала свою HiperDispatch для того, чтобы предоставлять своим гостевым системам свою абстракцию CPU.
Как известно, при виртуализации есть 2 типа инструкций CPU, 1 - те, которые можно запускать сразу на физическом оборудовании, минуя все уровни абстракции, и 2 - которые обязательно пропускать через монитор (virtual machine monitor) или, по другому, гипервизор.
Так вот, в этих гостевых системах на z/VM запускается следующий синтетический тест. Вся нагрузка, которую они генерируют (причем по максимуму, выжимая все из оборудования), состоит преимущественно из операцией 2-го типа. Что будет происходить? Сначала они все с необходимостью будут попадать в монитор z/VM, а затем, точно также, в монитор PR/SM. Появятся 2 таких бутылочных горлышка производительности и, ко всему прочему, эти же инструкции будут 2 раза маршрутизироваться по логическим CPU, сначала в z/VM, а потом в PR/SM.
Как Вы думаете, удастся ли такому вычислительному процессу делать вид, что он выполняется на чистом железе?
PR/SM решает задачу диспетчеризации (задачу планирования) логических CPU (виртуальных) по физическим. Физические процессоры имеют своё расположение на микросхеме, расстояния и соединения между чипами, значения объемов быстрых и медленных кешей и т.д. Если бы виртуальные процессоры не были бы абстракцией, а в точности отображали все детали устройства физических процессоров, то оптимизации были бы невозможны.
Грубо говоря, логические CPU имели бы даже те же номера, что и физические. И количество их совпадало бы 1:1. Т.е. пользы от такой виртуализации просто бы не было никакой. Как только мы скрываем какие-то детали устройства физических процессоров, становится возможным получать те или иные преимущества от абстракции. Например, иметь количество логических процессоров большее, чем физических.
Точно также работает абстракция на уровне z/VM, но там в силу вступают другие факторы и нужно скрывать другие детали.
Могу сказать, что нативный Linux (под процессор IBM) запускается в z/OS посредством commercial Linux kernel provided by IBM that runs inside a virtual appliance on z/OS. А x86 Linux запустить иначе чем как посредством гипервизора, вероятнее всего нельзя.
Не важно о каком МФ идет речь, с PR/SM или без, речь идет об абсолютно одинаковых принципах работы и наборе инструкций/команд процессора, организации памяти и вводе-выводе
Под этой удобной моделью скрывается реализация, в которой есть и абстрагирование, и виртуализация и все, что положено при общем подходе к конструированию систем. Я пытаюсь не мыслить в рамках модели, описываемой 1200+ страничным документом, а построить свою, достаточно простую.
Одинаковые наборы инструкций процессора в случае МФ возможны благодаря тому, что выполняется требование Гольдберга, приведу его еще раз:
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
А для x86 есть 17 инструкций, для которых это требование нарушается.
Следствием является то, что в случае МФ возможно построение таких абстракций, накладные расходы на виртуализацию в которых практически не заметны, что дает возможность строить модель "настоящей виртуальной машины".
А в случае x86 потери настолько велики, что приходится довольствоваться лишь "виртуальной ... системой".
Поправка. Вроде разобрался: дело в том, что в оригинальной типизации Гольдберга для 2-го типа используется не любая операционная система, а только так называемая conventional os. Поэтому, несмотря на то, что z/VM является операционной системой специального назначения, специализирующейся на функции гипервизора, она не является conventional os. Поэтому, её лучше записать в 1 тип в случае, если она работает на железе напрямую. Да и абстракция оборудования в этом случае выполняется один раз: операционной системой или гипервизором, не важно как назвать.
Если нет то тогда почему и под PR/SM она категоризируется зачастую как тип 2?
Не опечатка. Дело в уровнях абстракции. Гипервизор 1-го типа абстрагирует оборудование и предоставляет виртуализированную машину гостевым системам. Гипервизор 2-го типа использует абстракцию оборудования, созданную операционной системой. Когда z/VM под PR/SM называют типом 2, руководствуются чисто формальным критерием, что z/VM это операционная система, запускающая гипервизор. А здесь операционная система пользуется абстракцией, предоставленной PR/SM, а не сама абстрагирует оборудование.
Строго говоря z/VM не операционная система.
Она не операционная система общего назначения, но она операционная система специального назначения, расширяющая функционал гипервизора. Одного PR/SM недостаточно, чтобы реализовывать все необходимые задачи. Поэтому требуется полноценная операционная система. В семействе z/ есть несколько операционных систем и чтобы не встраивать функционал расширенного гипервизора в каждую из них, в которой он требуется, он вынесен в отдельную операционную систему, которой другие делегируют эту задачу.
Думаю, было так: в самых первых мейнфреймах LPAR могли быть реализованы через рубильники и коммутацию, совершенно без виртуализации. Как только техника развилась настолько, чтобы этим уже не приходилось заниматься на уровне ручных переключателей, тот же функционал LPAR был реализован уже через виртуализацию, и остается таковым по сей день.
Термин virtual machine может иметь два смысла: как гостевая система для гипервизора, и как абстракция физической машины, реализуемая в операционной системе (по-другому она еще называется extended machine). Эта же абстракция может быть реализована на уровне PR/SM, рассматривая LPAR как виртуализированный отдельный компьютер.
Про VM/370 и VM/SP к сожалению не могу сказать, это не моя сфера, меня хватило только на z/VM.
z/OS может представляться одной из трех ОС: MVS, USS (Unix), and zCX (Linux). Как Вам кажется есть в нем гипервизор или нет?
Не исключаю, что на каком то этапе своего существования, в z/OS мог быть встроен гипервизор непосредственно. Но в текущей конфигурации я уверен, что функционал гипервизора вынесен в отдельный модуль, который называется z/VM. Это следует из описания практически во всех доступных источниках и из инженерных соображений по компоновке модулей системы.
Поскольку модули z/ системы интегрированы между собой в достаточной степени, ничто не мешает z/OS "представляться" другими ОС. находясь при этом в окружении гипервизора z/VM и делегируя ему функционал гипервизора.
Про гипервизоры 3-го уровня (3-tier) у IBM ничего не известно.
Архитектура процессоров, используемых в IBM, позволяет реализовать виртуализацию с очень небольшими накладными расходами. А в x86 by design невозможно это сделать, не применяя эмуляцию, паравиртуализацию или что-то вроде. То есть, накладные расходы существенно выше и неустранимы. И зачем-то проблема сводится к отсутствию адекватного ПО в x86, чтобы заменить виртуализацию с потерями на что-то более лучшее. К чему адекватная система ввода-вывода, если накладные расходы на виртуализацию неустранимы? Какое ПО может игнорировать архитектуру x86, сохраняемую для обратной совместимости? Похоже, вся надежда на multikernel linux и контейнеры. )
z/VM способны работать без какой-либо специальной поддержки виртуализации -- им хватает самой что ни на есть обычной виртуальной памяти
Кажется, разобрался во всех вариантах. Можно рассматривать такие виды гипервизоров: manual, hardware, firmware, software. Если вручную коммутаторы рубильниками переключать, это manual hypervisor, но это больше шутка.
Аппаратная поддержка виртуализации может быть в процессорах и, возможно, в другом железе. Но самодостаточный hardware hypervisor, совсем без задействования firmware или software, вряд ли возможен.
Также, возможна поддержка виртуализации на уровне прошивки, firmware, если в ней, например, реализован гипервизор 1-го типа. Гипервизор 1-го типа может быть и в виде software, как это часто встречается в случае x86. Гипервизоры 1-го типа также задействуют аппаратную поддержку виртуализации при её наличии.
z/VM, как операционная система, является гипервизором 2-го типа, software, и может работать standalone, без какой-либо поддержки виртуализации, будь-то hardware или firmware.
Когда z/VM запущена поверх PR/SM, т.е. с поддержкой виртуализации на уровне firmware, то она уже строго говоря не относится ко 2-му типу. Тут лучше говорить про 2-tier гипервизор.
Классически, операционная система абстрагирует возможности железа, виртуализирует, создавая интерфейс, который можно назвать extended machine.
Могу предположить, что в случае мейнфреймов, применяется общая, более узкая абстракция физической машины, которую можно переиспользовать для разных операционных систем и другого системного ПО, такого как гипервизоры 1-го типа.
Эта абстракция и называется в статье настоящей виртуальной машиной.
It’s important to note that the lines between z/VM being categorized as type 1 and type 2 hypervisors are blurred; I’ve seen it labeled as Type 1 in some articles, but the reference I have provided lists it as Type 2. z/VM does not fall into the description of a Type 1 hypervisor because it operates on top of Type 1
Поэтому, лучше использовать 1-tier и 2-tier терминологию, а не 1, 2 тип, поскольку z/VM работает поверх PR/SM.
Когда на ранних периодах своего существования, z/VM запускалась без PR/SM, являясь при этом операционной системой, она относилась ко 2-му типу. Но когда её стали запускать только поверх PR/SM, такая типизация устарела. А для x86 она до сих пор актуальна.
Examples of hypervisors are the tier-1 hypervisor, Processor Resource/System Manager (PR/SM), that is built into the IBM Z hardware and creates and manages logical partition (LPAR) virtual machines, and the tier-2 hypervisor, IBM z/VM®, which can host many virtual machines. Like many IBM Z operating systems, z/VM itself runs in an LPAR.
То есть, z/OS не содержит в себе гипервизор, а переиспользует либо PR/SM, либо z/VM.
Именно, чтобы избегать подобных смысловых неточностей, и хотелось бы классифицировать программные компоненты.
Вы перепутали статью на 39 страниц и тезисы на 249 с похожим названием. Это оттуда
На мой взгляд наоборот: на математике вся компьютерная наука держится. Например, теория типов. Она применяется, как для определения свойств безопасности языков, например тех же инструкций x86 или другого набора. Так и для упрощения отладки и много чего еще. Без строгих математических оснований ничего бы столь сложного, как машины и операционные системы, не существовало бы.
В Википедии ссылаются на тезисы Гольдберга 1973 года "Architectural Principles for Virtual Computer Systems", где он впервые ввел эту типизацию.
Собственно, Таненбаум тоже ссылается на Гольдберга 1974 года, когда пишет про чувствительные инструкции. А архитектура x86 появилась в 1978 году только.
Из того, с чем я сталкивался: зашел к знакомому в гараж, у него сидит разработчик и пилит CRM систему с помощью Cursor. Знакомый не айтишник, просто решил попробовать, что из этого выйдет, а вдруг. Коллеги на работе хотят внедрять модели для обработки микросервисов. Здесь https://github.com/github/spec-kit/blob/main/spec-driven.md заявляют о появлении исполняемых спецификаций (executable specifications), 54k звездочек. Встречал несколько статей, где кодогенерацию с помощью LLM приравнивают к метапрограммированию.
Общее впечатление: часто выдается желаемое за действительное, происходит замена инженерного решения сложных проблем на легкие пути. Все-таки, чтобы эффективно встраивать LLM/ИИ в процессы нужны уже имеющийся высокий уровень организации процессов и глубокое понимание возможностей LLM/ИИ.
Что лучше: быть вайбкодером у манагеров или манагером у вайбкодеров?
Остается только цитировать википедию https://en.wikipedia.org/wiki/Virtualization
virtualization is a series of technologies that allows dividing of physical computing resources into a series of virtual machines, operating systems, processes or containers
The initial implementation x86 architecture did not meet the Popek and Goldberg virtualization requirements to achieve "classical virtualization"
Full virtualization was not fully available on the x86 platform prior to 2005. Many platform hypervisors for the x86 platform came very close and claimed full virtualization
In 2005 and 2006, Intel and AMD (working independently) created new processor extensions to the x86 architecture called Intel VT-x and AMD-V, respectively
А насчет контейнеров могу сказать, что они не позволяют обеспечивать должный уровень изоляции и безопасности из-за того, что пользуются общими абстракциями виртуальной машины, предоставленными единым ядром ОС.
Поэтому, появляются еще подобные гибриды
https://firecracker-microvm.github.io/
Firecracker enables you to deploy workloads in lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers.
Похоже, то, что Вы называете "настоящей виртуальной машиной" по-другому называется "полной виртуализацией" (full virtualization) или классической виртуализацией (classical virtualization).
Здесь в самом термине live migration уже подразумеваются именно операция с виртуальной машиной. А я имел ввиду, если, например, в LPAR1 работает ОС, можно ли её перенести в LPAR2, оставляя её на период переноса работающей со всеми процессами, и при этом не задействуя никакой виртуализации PR/SM, только конфигуратор оборудования.
Как я догадываюсь, ответ здесь да, и операция переноса заключается в подключении новых (из LPAR2) процессора, памяти и т.д. и освобождении старых, чтобы полностью отключить LPAR1.
Но тогда, похоже, виртуализация - это неотъемлимое свойство самой такой ОС, раз она позволяет подобные вещи.
Тогда можно переформулировать вопрос: если в LPAR1 будет работать другая ОС, которая сама не поддерживает такую миграцию, можно ли её перенести в LPAR2, не задействуя возможности виртуализации PR/SM?
Нет, но вместо него есть вполне приемлемая альтернатива. Вот, из похожего обсуждения
as long as the hypervisor is competently configured, respecting memory and IO adjacency (NUMA, AMP) and pinning threads to cores to eliminate sched overhead, as well as taking advantage of UEFI features like PCIe passthrough, performance of current hypervisors are easily 99+%
Так эта мысль во всей Вашей статье. Вы зачем-то вводите лишние сущности "настоящая виртуальная машина" и "виртуальная система" (в случае x86). Когда я пытаюсь с помощью сравнений для обоих случаев проследить всю иерархию уровней абстракции вплоть до железа, чтобы таки понять, что именно Вы имеете ввиду, словно бы наталкиваюсь на стену, будто мы с Вами находимся в разных партициях.
Насколько я понял, в мейнфрейме функции гипервизора PR/SM относительно бесшовно (именно за счет преимуществ архитектуры IBM по сравнению с x86 такая бесшовность возможна) интегрированы с функциями конфигуратора оборудования (аналога переключения рубильников и кабелей). И тут, действительно, легко запутаться и перестать понимать, где кончается виртуализация и начинается изоляция железа исключительно с помощью конфигурации.
Чудесно, когда можно полностью избавиться от слоя виртуализации, организуя все только с помощью партиционинга. Но вот проблема: живая миграция, например, в этом случае будет невозможна.
Вернемся к основам. Попытаемся понять, что именно можно считать подлинной виртуализацией, а что - таковой не является. И нужна ли она вообще?
Хорошо, что Вы сказали об эпизодичной роли гипервизора PR/SM. Тогда мы можем признать, что на платформе x86 можно аналогично использовать низкоуровневый гипервизор только для разовой привязки систем к железу и для последующих миграций. И накладные расходы, связанные с виртуализацией x86, будут также разовыми, а не постоянными. Или этому мешает "ненастоящность" виртуализации x86?
Таким образом, остается сравнивать программные гипервизоры z/VM и их аналоги на x86. Об этом я уже неоднократно упоминал, не хочется повторяться. Преимущество платформы IBM по сравнению с x86 в эффективности. Но структурно эти 2 вида виртуализации эквивалентны между собой также, как вычислительный процесс на виртуальном оборудовании эквивалентен вычислительному процессу на физическом.
Какие-то абстракции, которые можно реализовать на МФ, невыгодны и практически невозможны на x86. И вместо них применяются другие, которые лучше соответствуют ограничениям. Но в обоих случаях применяются общие подходы. Основанные на теории процессов, если хотите.
Повторю мысль, что "Вы не поверите, но в x86 тоже все в конечном итоге выполняется на чистом железе". Дело в том, какими путями оно добирается до железа, какие при этом расходы и от чего приходиться отказаться. Пример очень простой: подбираются соответствующие инструкции 2 типа и в пару к ним инструкции, отменяющие предыдущую, чтобы соблюдалась идемпотентность.
И все это гоняется в параллельных циклах, насыщая по максимуму пропускную способность программного гипервизора.
Попробую дополнить, исходя из своего понимания, не претендующего на какой-то высокий профессионализм. Сначала цитата:
...каждая из этих инструкций может быть выполнена в пользовательском режиме, не вызывая ловушку для операционной системы, но влияет на то, как операционная система (гостевая) управляет своими ресурсами...Чтобы обойти проблему эмуляции всех подряд инструкций, снижающую производительность, подход, реализованный в виртуальной машине VMWare [Sugerman et al., 2001], состоит в том, чтобы сканировать исполняемый файл и вставлять код в непривилегированные конфиденциальные инструкции, чтобы перенаправить управление на монитор виртуальной машины. Там будет происходить соответствующая эмуляция,
например с учетом контекста, в котором должна была выполняться инструкция. В результате может произойти полная виртуализация, а это означает, что выполнение может происходить без изменения гостевой операционной системы или самого приложения.
Т.е. само по себе появление такой инструкции, как описываемая EPSW, не катастрофа. Поскольку разработчикам z/ системы достаточно применить компенсацию с помощью подхода, подобного описываемому выше или какого-то иного. Поскольку они полностью контролируют происходящее в их гипервизорах, то добавление такого обхода лишь в какой-то мере ухудшит производительность, сохранив при этом корректность виртуализации.
Это все лишь мои предположения относительно того, что на самом деле происходит в реализации системы, а не в её модели, описываемой "Принципами работы". Если компенсация реализована, то все инварианты сохранены и "Принципы работы" остаются справедливыми.
Да, это хорошая демонстрация того, что я имею ввиду. Конфигурируемой партиции могут быть предоставлены как dedicated processors (выделенные физические CPU), так и виртуальные CPU, задаваемые, например, с помощью Absolute Capping -> Number of processors.
Системе, занимающей партицию, приходится пользоваться теми абстракциями, которые ей предоставили. Ей дали, например, либо один полноценный физический CPU, либо какую-то долю физического CPU, моделируемую логическими (виртуальными) CPU. И в некоторых ситуациях (например, связанных с высокопроизводительными вычислениями) это существенное отличие: одно дело владеть CPU монопольно, другое дело - иметь под капотом диспетчеризацию логических CPU.
Когда я говорю про сокрытие информации при абстрагировании оборудования для следующего уровня, я подразумеваю именно подобные ограничения. Вам приводили пример с сетевой картой и вы сослались на переписывание канальной программы https://habr.com/ru/articles/962262/comments/#comment_29051240 Это тоже 2 большие разницы: иметь монопольный полный доступ к устройству и иметь некоторую абстракцию (виртуальное устройство), реализуемую нижележащим уровнем, пусть хоть бы и с помощью канальной программы.
Сокрытие конфиденциальной информации при виртуализации отдельных инструкций CPU имеет похожие последствия с той разницей, что в отличии от случая физических/логических CPU, где допустимы оба варианта (гостю можно предоставлять как полный физический CPU, так и логические CPU с диспетчеризацией), скрывать некоторую информацию, касающуюся выполнения инструкций, от гостевой системы обязательно. Иначе может произойти утечка абстракции и нарушение безопасности. Мы с @SIISIIпытаемся донести эту мысль, но сталкиваемся с непониманием.
Я понимаю, что Вы имеете ввиду. Для ОС партицией обязательно гарантировать, что вычислительный процесс при использовании виртуализации оборудования должен быть эквивалентен вычислительному процессу на чистом железе bare-metal. На этом все держится, иначе какой смысл. Но побочные эффекты, все же, возможны.
Начиная от потерь производительности из-за диспетчеризации и заканчивая возможным раскрытием абстракции при чтении того, что знать не положено.
Напоследок приведу гипотетический пример, демонстрирующий намеренно неудачное стечение обстоятельств. Пусть z/VM работает поверх PR/SM, причем на логических CPU с диспетчеризацией от PR/SM. И пусть она также задействовала свою HiperDispatch для того, чтобы предоставлять своим гостевым системам свою абстракцию CPU.
Как известно, при виртуализации есть 2 типа инструкций CPU, 1 - те, которые можно запускать сразу на физическом оборудовании, минуя все уровни абстракции, и 2 - которые обязательно пропускать через монитор (virtual machine monitor) или, по другому, гипервизор.
Так вот, в этих гостевых системах на z/VM запускается следующий синтетический тест. Вся нагрузка, которую они генерируют (причем по максимуму, выжимая все из оборудования), состоит преимущественно из операцией 2-го типа. Что будет происходить? Сначала они все с необходимостью будут попадать в монитор z/VM, а затем, точно также, в монитор PR/SM. Появятся 2 таких бутылочных горлышка производительности и, ко всему прочему, эти же инструкции будут 2 раза маршрутизироваться по логическим CPU, сначала в z/VM, а потом в PR/SM.
Как Вы думаете, удастся ли такому вычислительному процессу делать вид, что он выполняется на чистом железе?
PR/SM решает задачу диспетчеризации (задачу планирования) логических CPU (виртуальных) по физическим. Физические процессоры имеют своё расположение на микросхеме, расстояния и соединения между чипами, значения объемов быстрых и медленных кешей и т.д. Если бы виртуальные процессоры не были бы абстракцией, а в точности отображали все детали устройства физических процессоров, то оптимизации были бы невозможны.
Грубо говоря, логические CPU имели бы даже те же номера, что и физические. И количество их совпадало бы 1:1. Т.е. пользы от такой виртуализации просто бы не было никакой. Как только мы скрываем какие-то детали устройства физических процессоров, становится возможным получать те или иные преимущества от абстракции. Например, иметь количество логических процессоров большее, чем физических.
Точно также работает абстракция на уровне z/VM, но там в силу вступают другие факторы и нужно скрывать другие детали.
Вам тоже спасибо за статью.
Могу сказать, что нативный Linux (под процессор IBM) запускается в z/OS посредством commercial Linux kernel provided by IBM that runs inside a virtual appliance on z/OS. А x86 Linux запустить иначе чем как посредством гипервизора, вероятнее всего нельзя.
Под этой удобной моделью скрывается реализация, в которой есть и абстрагирование, и виртуализация и все, что положено при общем подходе к конструированию систем. Я пытаюсь не мыслить в рамках модели, описываемой 1200+ страничным документом, а построить свою, достаточно простую.
Одинаковые наборы инструкций процессора в случае МФ возможны благодаря тому, что выполняется требование Гольдберга, приведу его еще раз:
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
А для x86 есть 17 инструкций, для которых это требование нарушается.
Следствием является то, что в случае МФ возможно построение таких абстракций, накладные расходы на виртуализацию в которых практически не заметны, что дает возможность строить модель "настоящей виртуальной машины".
А в случае x86 потери настолько велики, что приходится довольствоваться лишь "виртуальной ... системой".
Поправка. Вроде разобрался: дело в том, что в оригинальной типизации Гольдберга для 2-го типа используется не любая операционная система, а только так называемая conventional os. Поэтому, несмотря на то, что z/VM является операционной системой специального назначения, специализирующейся на функции гипервизора, она не является conventional os. Поэтому, её лучше записать в 1 тип в случае, если она работает на железе напрямую. Да и абстракция оборудования в этом случае выполняется один раз: операционной системой или гипервизором, не важно как назвать.
Не опечатка. Дело в уровнях абстракции. Гипервизор 1-го типа абстрагирует оборудование и предоставляет виртуализированную машину гостевым системам. Гипервизор 2-го типа использует абстракцию оборудования, созданную операционной системой. Когда z/VM под PR/SM называют типом 2, руководствуются чисто формальным критерием, что z/VM это операционная система, запускающая гипервизор. А здесь операционная система пользуется абстракцией, предоставленной PR/SM, а не сама абстрагирует оборудование.
Она не операционная система общего назначения, но она операционная система специального назначения, расширяющая функционал гипервизора. Одного PR/SM недостаточно, чтобы реализовывать все необходимые задачи. Поэтому требуется полноценная операционная система. В семействе z/ есть несколько операционных систем и чтобы не встраивать функционал расширенного гипервизора в каждую из них, в которой он требуется, он вынесен в отдельную операционную систему, которой другие делегируют эту задачу.
Думаю, было так: в самых первых мейнфреймах LPAR могли быть реализованы через рубильники и коммутацию, совершенно без виртуализации. Как только техника развилась настолько, чтобы этим уже не приходилось заниматься на уровне ручных переключателей, тот же функционал LPAR был реализован уже через виртуализацию, и остается таковым по сей день.
Термин virtual machine может иметь два смысла: как гостевая система для гипервизора, и как абстракция физической машины, реализуемая в операционной системе (по-другому она еще называется extended machine). Эта же абстракция может быть реализована на уровне PR/SM, рассматривая LPAR как виртуализированный отдельный компьютер.
Про VM/370 и VM/SP к сожалению не могу сказать, это не моя сфера, меня хватило только на z/VM.
Не исключаю, что на каком то этапе своего существования, в z/OS мог быть встроен гипервизор непосредственно. Но в текущей конфигурации я уверен, что функционал гипервизора вынесен в отдельный модуль, который называется z/VM. Это следует из описания практически во всех доступных источниках и из инженерных соображений по компоновке модулей системы.
Поскольку модули z/ системы интегрированы между собой в достаточной степени, ничто не мешает z/OS "представляться" другими ОС. находясь при этом в окружении гипервизора z/VM и делегируя ему функционал гипервизора.
Про гипервизоры 3-го уровня (3-tier) у IBM ничего не известно.
Архитектура процессоров, используемых в IBM, позволяет реализовать виртуализацию с очень небольшими накладными расходами. А в x86 by design невозможно это сделать, не применяя эмуляцию, паравиртуализацию или что-то вроде. То есть, накладные расходы существенно выше и неустранимы. И зачем-то проблема сводится к отсутствию адекватного ПО в x86, чтобы заменить виртуализацию с потерями на что-то более лучшее. К чему адекватная система ввода-вывода, если накладные расходы на виртуализацию неустранимы? Какое ПО может игнорировать архитектуру x86, сохраняемую для обратной совместимости? Похоже, вся надежда на multikernel linux и контейнеры. )
Кажется, разобрался во всех вариантах. Можно рассматривать такие виды гипервизоров: manual, hardware, firmware, software. Если вручную коммутаторы рубильниками переключать, это manual hypervisor, но это больше шутка.
Аппаратная поддержка виртуализации может быть в процессорах и, возможно, в другом железе. Но самодостаточный hardware hypervisor, совсем без задействования firmware или software, вряд ли возможен.
Также, возможна поддержка виртуализации на уровне прошивки, firmware, если в ней, например, реализован гипервизор 1-го типа. Гипервизор 1-го типа может быть и в виде software, как это часто встречается в случае x86. Гипервизоры 1-го типа также задействуют аппаратную поддержку виртуализации при её наличии.
z/VM, как операционная система, является гипервизором 2-го типа, software, и может работать standalone, без какой-либо поддержки виртуализации, будь-то hardware или firmware.
Когда z/VM запущена поверх PR/SM, т.е. с поддержкой виртуализации на уровне firmware, то она уже строго говоря не относится ко 2-му типу. Тут лучше говорить про 2-tier гипервизор.
Классически, операционная система абстрагирует возможности железа, виртуализирует, создавая интерфейс, который можно назвать extended machine.
Могу предположить, что в случае мейнфреймов, применяется общая, более узкая абстракция физической машины, которую можно переиспользовать для разных операционных систем и другого системного ПО, такого как гипервизоры 1-го типа.
Эта абстракция и называется в статье настоящей виртуальной машиной.
Нашел неплохое объяснение https://shorturl.at/jNlSU
It’s important to note that the lines between z/VM being categorized as type 1 and type 2 hypervisors are blurred; I’ve seen it labeled as Type 1 in some articles, but the reference I have provided lists it as Type 2. z/VM does not fall into the description of a Type 1 hypervisor because it operates on top of Type 1
Поэтому, лучше использовать 1-tier и 2-tier терминологию, а не 1, 2 тип, поскольку z/VM работает поверх PR/SM.
Когда на ранних периодах своего существования, z/VM запускалась без PR/SM, являясь при этом операционной системой, она относилась ко 2-му типу. Но когда её стали запускать только поверх PR/SM, такая типизация устарела. А для x86 она до сих пор актуальна.
Здесь https://www.ibm.com/docs/en/zos/2.5.0?topic=environment-hardware-environments-that-zos-supports говорится, что z/OS может запускаться в следующих окружениях:
- LPAR under PR/SM
- Virtual machine under IBM z/VM
Examples of hypervisors are the tier-1 hypervisor, Processor Resource/System Manager (PR/SM), that is built into the IBM Z hardware and creates and manages logical partition (LPAR) virtual machines, and the tier-2 hypervisor, IBM z/VM®, which can host many virtual machines. Like many IBM Z operating systems, z/VM itself runs in an LPAR.
То есть, z/OS не содержит в себе гипервизор, а переиспользует либо PR/SM, либо z/VM.
Именно, чтобы избегать подобных смысловых неточностей, и хотелось бы классифицировать программные компоненты.
Вы перепутали статью на 39 страниц и тезисы на 249 с похожим названием. Это оттуда
На мой взгляд наоборот: на математике вся компьютерная наука держится. Например, теория типов. Она применяется, как для определения свойств безопасности языков, например тех же инструкций x86 или другого набора. Так и для упрощения отладки и много чего еще. Без строгих математических оснований ничего бы столь сложного, как машины и операционные системы, не существовало бы.
В Википедии ссылаются на тезисы Гольдберга 1973 года "Architectural Principles for Virtual Computer Systems", где он впервые ввел эту типизацию.
Собственно, Таненбаум тоже ссылается на Гольдберга 1974 года, когда пишет про чувствительные инструкции.
А архитектура x86 появилась в 1978 году только.