Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
Чувствительная к управлению инструкция (control sensitive instruction) – это инструкция, которая может повлиять на конфигурацию машины... Инструкция, чувствительная к поведению (behavior sensitive instruction) – это команда, действие которой частично определяется контекстом, в котором она выполняется...
...не все наборы инструкций имеют конфиденциальные (т.е. чувствительные?) инструкции только для привилегированных пользователей, в том числе, пожалуй, самый популярный – набор инструкций Intel x86. Как оказалось, в этом наборе 17 конфиденциальных инструкций, которые не являются привилегированными.
...пока конфиденциальные инструкции перехватываются при выполнении в пользовательском режиме, мы можем безопасно выполнять все нечувствительные инструкции непосредственно на базовом оборудовании.
Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.
В случае нашего HPC вообще просто: гостевому Линуксу одному отдаются все доступные ресурсы. Т.е. аппаратные средства (или по-другому Power PHYP native bare-metal hypervisor in firmware) запускают одну ОС в одной партиции и больше ничего особенного не делают. Все дублирующие элементы машины с несколькими процессорами https://shorturl.at/3OfVx используются только для эффективности вычислений.
Могу предположить, что в случае z/VM одного функционала bare-metal hypervisor недостаточно, и требуется поддержка на уровне самой специализированной ОС z/VM (программного гипервизора в вашей терминологии), чтобы запускать тысячи гостевых машин на каком-то меньшем числе партиций LPAR мейнфрейма.
С моей точки зрения, оба они программные гипервизоры, просто один из них находится в firmware, а другой - в ОС z/VM. И этому гипервизору в ОС z/VM требуется поддержка микропрограмм процессоров, упомянутая в статье, чтобы эффективнее осуществлять свою виртуализирующую деятельность.
Освежил свои представления и оказалось, что в PowerPC Linux используется POWER Hypervisor, аналогичный мейнфреймовским. Приведу здесь немного информации об архитектуре из https://en.wikipedia.org/wiki/Hypervisor для удобства:
IBM provides virtualization partition technology known as logical partitioning (LPAR) on System/390, zSeries, pSeries and IBM AS/400 systems. For IBM's Power Systems, the POWER Hypervisor (PHYP) is a native (bare-metal) hypervisor in firmware and provides isolation between LPARs...For real-mode addressing by operating systems (AIX, Linux, IBM i), the Power processors (POWER4 onwards) have designed virtualization capabilities where a hardware address-offset is evaluated with the OS address-offset to arrive at the physical memory address.
Похоже, что для LPAR технологии не обязательны мейнфреймовские процессоры, она в таком же виде существует и для RISC POWER процессоров. Linux после petitboot просто грузится как гостевая ОС. А гипервизор реализован на уровне firmware, не требуя особой поддержки от микропрограмм процессоров .
Я имел дело с серверами IBM на архитектуре Power и под ОС Linux, но не с мейнфреймами. И на HPC кластере, без виртуализации. Больше всего запомнилось отличие petitboot загрузчика (PowerPC на Linux) от загрузчика x86. https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petitboot/
Если я правильно понимаю, разработчик мейнфрейма IBM (я не имею ввиду прикладного разработчика под ОС z/VM) может заниматься как разработкой прошивки процессора (firmware), так и разработкой самой ОС z/VM. В силу того, что компания занимается и железом и софтом. Не знаю, как у процессоров мейнфрейма, но для разных устройств прошивка (например, firmware for IBM Power System) - это обычное ПО, которое также разрабатывается, легко меняется и обновляется.
Мне представляется, что аналогично тому, как в firmware маршрутизатора можно реализовать функционал, например, брандмауэра, так и в firmware мейнфрейма (в т.ч. его процессоров) можно реализовать функционал гипервизора. И он будет 1-го типа, поскольку близок к железу и узкоспециализированный.
Это не zVM, это реальная машина МФ с партициями реализованными PR/SM (Processor Resource/Systems Manager), ошибочно считающимся Type-1 Hypervisor. Почему ошибочно? Потому что каждая партиция это реальный МФ. PR/SM это микропроцессор МФ и микрокод на котором написаны все те же "Принципы работы МФ".
Микрокод - это ведь software с точки зрения разработчиков МФ? Тогда слой этого микрокода реализует гипервизор 1-го типа. Если zVM хоть немного считать ОС общего назначения, то она реализует уже гипервизор 2-го типа. Особенно, если при этом она как-то расширяет функционал гипервизора за счет возможностей ОС, недоступных в слое микрокода. Если же функционал гипервизора и zVM полностью независимы (настолько я не знаком с zVM, чтобы определить это), то такая типизация теряет смысл, поскольку zVM переиспользует гипервизор 1-го типа, находясь рядом с ним, но не являясь гипервизором 2-го типа.
Процедура — блок кода, выполняющий определенную логику, не возвращающий значение. Предлагаю считать это понятие подмножеством функции и убрать из обихода, добавив определение процедурного стиля.
Чтобы лучше понять разницу между функциями и процедурами, можно рассмотреть понятия переменных (variables) и "присваеваемых" (assignables). Не знаю, как лучше перевести, можно думать о них, как о ячейках памяти. Часто в литературе их также называют переменными, что скрывает различие между variable и assignable. Переменные вводятся с помощью функциональной абстракции, а смысл им придается с помощью подстановок. Например, 1-арная лямбда-функция связывает переменную-аргумент с выражением: lambda(x){x+3}(2); -> 5 "Присваевыемые" вводятся с помощью объявления, а смысл им придается с помощью присваивания и возвращения содержимого. Например, 0-арная лямбда-функция может использовать значение ранее объявленной "присваеваемой": declare x=2; lambda(){x+3}(); -> 5
Далее, у нас есть функции, в которые подставляются значения переменных для получения возвращаемого значения. Также, у нас есть команды, которые выполняются ради побочных эффектов над "присваиваемыми".
Процедура — это функция, которая возвращает невыполненную команду в качестве значения. Вызов процедуры — это композиция применения функции (возвращающей команду) и вызова этой команды.
Кажется, пришло время цитировать Таненбаума:
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
Чувствительная к управлению инструкция (control sensitive instruction) – это инструкция, которая может повлиять на конфигурацию машины...
Инструкция, чувствительная к поведению (behavior sensitive instruction) – это команда, действие которой частично определяется контекстом, в котором она выполняется...
...не все наборы инструкций имеют конфиденциальные (т.е. чувствительные?) инструкции только для привилегированных пользователей, в том числе, пожалуй, самый популярный – набор инструкций Intel x86. Как оказалось, в этом наборе 17 конфиденциальных инструкций, которые не являются привилегированными.
...пока конфиденциальные инструкции перехватываются при выполнении в пользовательском режиме, мы можем безопасно выполнять все нечувствительные инструкции непосредственно на базовом оборудовании.
Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.
В случае нашего HPC вообще просто: гостевому Линуксу одному отдаются все доступные ресурсы. Т.е. аппаратные средства (или по-другому Power PHYP native bare-metal hypervisor in firmware) запускают одну ОС в одной партиции и больше ничего особенного не делают. Все дублирующие элементы машины с несколькими процессорами https://shorturl.at/3OfVx используются только для эффективности вычислений.
Могу предположить, что в случае z/VM одного функционала bare-metal hypervisor недостаточно, и требуется поддержка на уровне самой специализированной ОС z/VM (программного гипервизора в вашей терминологии), чтобы запускать тысячи гостевых машин на каком-то меньшем числе партиций LPAR мейнфрейма.
С моей точки зрения, оба они программные гипервизоры, просто один из них находится в firmware, а другой - в ОС z/VM. И этому гипервизору в ОС z/VM требуется поддержка микропрограмм процессоров, упомянутая в статье, чтобы эффективнее осуществлять свою виртуализирующую деятельность.
Освежил свои представления и оказалось, что в PowerPC Linux используется POWER Hypervisor, аналогичный мейнфреймовским. Приведу здесь немного информации об архитектуре из https://en.wikipedia.org/wiki/Hypervisor для удобства:
IBM provides virtualization partition technology known as logical partitioning (LPAR) on System/390, zSeries, pSeries and IBM AS/400 systems. For IBM's Power Systems, the POWER Hypervisor (PHYP) is a native (bare-metal) hypervisor in firmware and provides isolation between LPARs...For real-mode addressing by operating systems (AIX, Linux, IBM i), the Power processors (POWER4 onwards) have designed virtualization capabilities where a hardware address-offset is evaluated with the OS address-offset to arrive at the physical memory address.
Похоже, что для LPAR технологии не обязательны мейнфреймовские процессоры, она в таком же виде существует и для RISC POWER процессоров. Linux после petitboot просто грузится как гостевая ОС. А гипервизор реализован на уровне firmware, не требуя особой поддержки от микропрограмм процессоров .
Я имел дело с серверами IBM на архитектуре Power и под ОС Linux, но не с мейнфреймами. И на HPC кластере, без виртуализации. Больше всего запомнилось отличие petitboot загрузчика (PowerPC на Linux) от загрузчика x86. https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petitboot/
Если я правильно понимаю, разработчик мейнфрейма IBM (я не имею ввиду прикладного разработчика под ОС z/VM) может заниматься как разработкой прошивки процессора (firmware), так и разработкой самой ОС z/VM. В силу того, что компания занимается и железом и софтом. Не знаю, как у процессоров мейнфрейма, но для разных устройств прошивка (например, firmware for IBM Power System) - это обычное ПО, которое также разрабатывается, легко меняется и обновляется.
Мне представляется, что аналогично тому, как в firmware маршрутизатора можно реализовать функционал, например, брандмауэра, так и в firmware мейнфрейма (в т.ч. его процессоров) можно реализовать функционал гипервизора. И он будет 1-го типа, поскольку близок к железу и узкоспециализированный.
Микрокод - это ведь software с точки зрения разработчиков МФ? Тогда слой этого микрокода реализует гипервизор 1-го типа. Если zVM хоть немного считать ОС общего назначения, то она реализует уже гипервизор 2-го типа. Особенно, если при этом она как-то расширяет функционал гипервизора за счет возможностей ОС, недоступных в слое микрокода. Если же функционал гипервизора и zVM полностью независимы (настолько я не знаком с zVM, чтобы определить это), то такая типизация теряет смысл, поскольку zVM переиспользует гипервизор 1-го типа, находясь рядом с ним, но не являясь гипервизором 2-го типа.
Каждая архитектура на основе микрослужб содержит наполовину сломанную реимплементацию Erlang
Чтобы лучше понять разницу между функциями и процедурами, можно рассмотреть понятия переменных (variables) и "присваеваемых" (assignables). Не знаю, как лучше перевести, можно думать о них, как о ячейках памяти. Часто в литературе их также называют переменными, что скрывает различие между variable и assignable. Переменные вводятся с помощью функциональной абстракции, а смысл им придается с помощью подстановок. Например, 1-арная лямбда-функция связывает переменную-аргумент с выражением:
lambda(x){x+3}(2); -> 5"Присваевыемые" вводятся с помощью объявления, а смысл им придается с помощью присваивания и возвращения содержимого. Например, 0-арная лямбда-функция может использовать значение ранее объявленной "присваеваемой":declare x=2; lambda(){x+3}(); -> 5Далее, у нас есть функции, в которые подставляются значения переменных для получения возвращаемого значения. Также, у нас есть команды, которые выполняются ради побочных эффектов над "присваиваемыми".
Процедура — это функция, которая возвращает невыполненную команду в качестве значения. Вызов процедуры — это композиция применения функции (возвращающей команду) и вызова этой команды.
Подробнее об этом, например, в Harper: Practical Foundations for Programming Languages