Средство функциональной виртуализации для блокировки командной функции многофункциональной команды виртуального процесса

Средство функциональной виртуализации для блокировки командной функции многофункциональной команды виртуального процесса

Иллюстрации

Показать все

Реферат

ОБЛАСТЬ ИЗОБРЕТЕНИЯ

Настоящее изобретение относится к компьютерным системам и, более конкретно, к командной функциональности процессора компьютерной системы.

ПРЕДПОСЫЛКИ ИЗОБРЕТЕНИЯ

Торговые марки: IBM® является зарегистрированной торговой маркой корпорации International Business Machines, Армонк, штат Нью-Йорк, США. S/390, Z900, 7.990, z10 и другие названия изделий могут быть зарегистрированными торговыми марками или названиями изделий корпорации International Business Machines или других компаний.

IBM создала трудом многих высококвалифицированных инженеров, начиная с машин, известных как IBM® System 360 в 1960-х до настоящего времени, особую архитектуру, которая, из-за ее существенной природы для вычислительной системы, стала известна как "мейнфрейм", принципы работы которого устанавливают архитектуру машины описанием команд, которые могут выполняться на реализации команд "мейнфрейма", которые были изобретены изобретателями IBM и приняты, из-за их значительного вклада в улучшение состояния вычислительной машины, представленной "мейнфреймом", как значительные вклады по включению в Принципы работы IBM, как установлено за все эти годы. Восьмое издание IBM® z/Architecture® Principles of Operation (Принципы работы IBM® z/Architecture®), которое было опубликовано в феврале 2009, стало стандартным опубликованным справочником как SA22-7832-07 и включено в серверы-мейнфреймы IBM's z10®, включая серверы IBM System z10® Enterprise Class.

Согласно ФИГ.1А, изображены представительные компоненты системы Основного Компьютера 50 из уровня техники. Также в компьютерной системе могут применяться другие конфигурации компонентов, которые хорошо известны из уровня техники. Представительный основной компьютер 50 содержит одно или более ЦПУ 1 в связи с главным запоминающим устройством (компьютерная память 2), а также интерфейсы ввода-вывода к устройствам хранения 11 и сетям 10 для связи с другими компьютерами или SAN и тому подобным. ЦПУ 1 соответствует архитектуре, имеющей разработанный набор команд и разработанную функциональность. ЦПУ 1 может иметь динамическую трансляцию адресов (Dynamic Address Translation, DAT) 3 для преобразования программных адресов (виртуальных адресов) в реальный адрес в памяти. DAT обычно включает буфер динамической трансляции адресов (Translation Lookaside Buffer, TLB) 7 для кэширования трансляций, так что последующие обращения к блоку компьютерной памяти 2 не требуют задержки на трансляцию адреса. Обычно применяется кэш 9 между компьютерной памятью 2 и процессором 1. Кэш 9 может быть иерархическим, имеющим большой кэш, доступный для более чем одного ЦПУ, и меньшие, более быстрые кэши (низшего уровня) между большим кэшем и каждым ЦПУ. В некоторых реализациях кэши низшего уровня разделены, чтобы обеспечить отдельные низкоуровневые кэши для считывания команд и обращений к данным. В варианте реализации, команда считывается из памяти 2 устройством считывания команд 4 через кэш 9. Команда декодируется в устройстве декодирования команд 6 и передается (с другими командами в некоторых реализациях) устройствам выполнения команд 8. Обычно применяется несколько устройств выполнения 8, например, арифметическое устройство выполнения, устройство выполнения с плавающей точкой и устройство выполнения команд ветвления. Команда выполняется устройством выполнения, обращаясь к операндам из заданных командой регистров или памяти, по необходимости. Если следует обратиться (загрузить или сохранить) к операнду из памяти 2, устройство загрузки-сохранения 5 обычно обрабатывает обращение под управлением команды, которая выполняется. Команды могут выполняться в аппаратных схемах или во внутреннем микрокоде (микропрограмме), или сочетанием их обоих.

На ФИГ.1Б предоставлена эмулируемая основная компьютерная система 21 из уровня техники, которая эмулирует основную компьютерную систему 50 с основной архитектурой. В эмулируемой основной компьютерной системе 21, основной процессор (ЦПУ) 1 является эмулируемым основным процессором (или виртуальным основным процессором) и содержит эмуляционный процессор 27, имеющий иную архитектуру набора собственных команд, чем процессор 1 основного компьютера 50. Эмулируемая основная компьютерная система 21 имеет память 22, доступную эмуляционному процессору 27. В примере реализации, память 2 разделена на часть памяти основного компьютера 2 и часть подпрограмм эмуляции 23. Память основного компьютера 2 доступна программам эмулируемого основного компьютера 21 согласно архитектуре основного компьютера. Эмуляционный процессор 27 выполняет собственные команды разработанного набора команд архитектуры, отличной от архитектуры эмулируемого процессора 1, собственные команды получены из памяти подпрограмм эмуляции 23, и могут получить доступ к команде основной машины для выполнения из программы в памяти основного компьютера 2 с применением одной или более команд, полученных в последовательности, и подпрограммы доступа/декодирования, которая может декодировать команды основной машины, к которым получен доступ, чтобы определить подпрограмму выполнения собственной команды для эмулирования функции команды основной машины, к которой получен доступ. Другие средства, которые определены для архитектуры основной компьютерной системы 50, могут быть эмулированы подпрограммами разработанных средств, включая такие средства, как регистры общего назначения, управляющие регистры, динамическая трансляция адресов, и поддержка подсистемы ввода-вывода и кэш процессора, к примеру. Подпрограммы эмуляции также могут использовать преимущества функций, доступных в эмуляционном процессоре 27 (таких как регистры общего назначения и динамическая трансляция виртуальных адресов) для улучшения производительности подпрограмм эмуляции. Также могут предоставляться специальные аппаратные и разгрузочные устройства для содействия процессору 27 в эмулировании функций основного компьютера 50.

На мейнфрейме разработанные машинные команды используются программистами, сейчас обычно программистами на "С", часто с применением компилятора. Эти команды, хранящиеся в запоминающем устройстве, могут выполняться собственно на сервере z/Architecture IBM, или же на машинах, выполняющих другие архитектуры. Они могут эмулироваться на существующих или будущих серверах-мейнфреймах IBM и на других машинах IBM (напр. серверах pSeries® и серверах xSeries®). Они могут выполняться на машинах с запущенным Linux на множестве машин, использующих аппаратное обеспечение производства IBM®, Intel®, AMD™, Sun Microsystems и других. Кроме выполнения на этом аппаратном обеспечении под z/Architecture®, Linux может также использоваться на машинах, которые используют эмуляцию, как описано на http://www.turbohercules.com, http://www.hercules-390.org и http://www.funsoft.com. В режиме эмуляции, эмуляционное программное обеспечение выполняется собственным процессором для эмулирования архитектуры эмулируемого процессора.

Собственный процессор 27 обычно выполняет эмуляционное программное обеспечение 23. содержащее либо микропрограмму, либо собственную операционную систему для осуществления эмуляции эмулируемого процессора. Эмуляционное программное обеспечение 23 отвечает за считывание и выполнение команд эмулируемой архитектуры процессора. Эмуляционное программное обеспечение 23 поддерживает эмулируемый программный счетчик для отслеживания границ команды. Эмуляционное программное обеспечение 23 может считывать одну или более эмулируемых машинных команд за раз и преобразовывать одну или более эмулируемых машинных команд в соответствующую группу собственных машинных команд для выполнения собственным процессором 27. Эти преобразованные команды могут быть кэшированы, так что можно достичь более быстрого преобразования. Тем не менее, эмуляционное программное обеспечение должно поддерживать архитектурные правила эмулируемой архитектуры процессора для обеспечения корректной работы операционных систем и приложений, написанных для эмулируемого процессора. Более того, эмуляционное программное обеспечение должно предоставлять ресурсы, идентифицируемые архитектурой эмулируемого процессора 1, включая, но не ограничиваясь, управляющие регистры, регистры общего назначения, регистры с плавающей точкой, функцию динамической трансляции адресов, включающую, например, таблицы сегментов и таблицы страниц, механизмы прерывания, механизмы контекстного переключения, часы истинного времени (Time of Day, TOD) и разработанные интерфейсы к подсистемам ввода-вывода, так что операционная система или прикладная программа, предназначенная для запуска на эмулируемом процессоре, может запускаться на собственном процессоре, имеющем эмуляционное программное обеспечение.

Конкретная команда, которая выполняется, декодируется, и вызывается подпрограмма для осуществления функции отдельной команды. Функция эмуляционного программного обеспечения 23, эмулирующая функцию эмулируемого процессора 1, реализуется, например, в подпрограмме на "С" или драйвере, или другом способе предоставления драйвера для специфического аппаратного обеспечения, в пределах квалификации специалистов из уровня техники после понимания описания предпочтительного варианта реализации. Различные патенты касательно программной и аппаратной эмуляции включают, но не ограничиваются, патент США 5551013 "Мультипроцессор для аппаратной эмуляции" авторства Beausoleil и др., патент США S6009261 "Предварительная обработка сохраненных целевых подпрограмм для эмулирования несовместимых команд на целевом процессоре" авторства Scalzi и др;

патент США 5574873 "Декодирование гостевых команд для прямого доступа к подпрограммам эмуляции, которые эмулируют гостевые команды" авторства Davidian и др, патент США 6308255 "Симметричная многопроцессорная шина и набор микросхем, использующиеся для поддержки сопроцессора, позволяющей запуск несобственного кода на системе" авторства Gorishek и др., патент США 6463582 "Динамический оптимизирующий транслятор объектного кода для эмуляции архитектуры и метод динамической оптимизирующей трансляции объектного кода" авторства Lethin и др., и патент США 5790825 "Метод эмулирования гостевых команд на основном компьютере посредством динамической рекомпиляции команд основной машины" авторства Eric Traut. Эти ссылки иллюстрируют множество известных способов достижения эмуляции формата команд, разработанного для другой машины, на целевой машине, известных специалистам из уровня техники, а также промышленные программные методики, используемые вышеупомянутыми.

В публикации США № US 2009/0222814 A1, опубликованной 3 сентября 2009, Astrand, "Выборочное предоставление функциональности устройства USB виртуальной машине" приложение виртуальной машины (VM) может запускать гостевую операционную систему (OS) и разрешать гостевой OS соединяться с устройствами USB, подключенными к компьютеру. Программа VM может фильтровать функции, связанные с устройством USB, так что только некоторые из функций устройства USB предоставляются гостевой OS.

Опубликованная патентная заявка США US 2005/0188171 A1 описывает программный загрузчик внутри доверенной вычислительной базы, который переназначает коды операций в коде при помощи карты кодов операции перед загрузкой кодов операции в конвейер выполнения для процессора. Вредоносный код, который попытается выполниться напрямую на процессоре, а не посредством загрузчика, не получит переназначенные коды операций, и таким образом не выполнится корректно.

Опубликованная заявка РСТ WO 00/67115 A1 описывает микроконтроллер, в котором бит статуса проверяется механизмом блокировки/деблокировки для определения, блокирована команда или нет. Или же, деблокиратор сравнивает команды с предопределенным списком специальных команд, поддерживаемых деблокиратором.

Публикация Advanced Micro Devices: "Live Migration with AMD-V Extended Migration Technology", ("Динамическая миграция с помощью технологии расширенной миграции AMD-V"), 30 апреля 2008 (2008-04-30), страницы 1-17, излагает управление при помощи монитора виртуальной машины (Virtual Machine Monitor, VMM) информацией, возвращаемой гостевому программному обеспечению как результат команды CPUID. Такая виртуализация с аппаратной поддержкой при помощи VMM может использовать перехват CPUID, чтобы возвращать соответствующие биты каждый раз, когда гостевое программное обеспечение выполняет команду CPUID. Это реализуется при помощи модель-специфичных регистров (Model Specific Registers, MSR), предоставляющих функцию замены функции CPUID для определения подмножества информации, которую возвращает команда CPUID. Это показывает потребность в способе для выключения новых команд, пока во всех процессорах ресурсного пула процессоров не будут реализованы новые команды. Это предполагает, что AMD может поддерживать биты отключения особенностей для выключения некоторых команд или наборов команд.

КРАТКОЕ ИЗЛОЖЕНИЕ ИЗОБРЕТЕНИЯ

В соответствии с изобретением предусмотрено блокирование определенных команд от выполнения логическим процессором, выполняющим виртуальную машину, т.е. блокирование выполнения команд логическим процессором. Устанавливается значение блокировки команд, определенное для виртуальной машины, для блокировки выполнения команды. Команда считывается логическим процессором для выполнения процессором, команда содержит код операции и определяет код функции из множества кодов функций, код функции настроен на обозначение функции для выполнения командой, команда поддерживается одним или более процессоров. Определяется значение блокировки команд для считанной команды, имеющей код функции, посредством сопоставления значения блокировки команд, определенного для виртуальной машины, с кодом операции считанной команды. В зависимости от значения блокировки команд, разрешающего выполнение команды, имеющей код функции, считанная команда выполняется процессором. В зависимости от значения блокировки команд, не разрешающего выполнение команды, выполнение считанной команды блокируется и вызывается событие программного исключения (например, программное исключение).

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

В варианте реализации команда является разрешенной командой, если команда применяет разрешенный код функции, тогда как команда является неразрешенной командой, если команда применяет неразрешенный код функции.

В варианте реализации выполняется определение, является ли команда разрешенной командой, посредством сопоставления кода операции команды со значением блокировки команд.

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

На ФИГ.1а изображена схема примерной основной компьютерной системы;

На ФИГ.1Б изображена схема примерной эмуляционной основной компьютерной системы;

На ФИГ.1В изображена схема примерной компьютерной системы;

На ФИГ.2 изображена схема примерной компьютерной сети;

На ФИГ.3 изображена схема примерных элементов компьютерной системы;

На ФИГ.4А изображена схема примерного устройства выполнения;

На ФИГ.4Б изображена схема примерного устройства ветвления;

На ФИГ.4В изображена схема примерного устройства загрузки/сохранения;

На ФИГ.5 изображена схема примерного логического разбиения;

На ФИГ.6 изображена схема примерных элементов логического разбиения;

На ФИГ.7 изображена схема примерных элементов логического разбиения;

На ФИГ.8 изображена схема примерной таблицы кодов операции;

На ФИГ.9 изображена схема примерной методики блокировки;

На ФИГ.10 изображена схема примерной методики блокировки;

На ФИГ.11 изображена схема примерной методики блокировки; и

На ФИГ.12-15 изображены схемы методик блокировки команд.

ПОДРОБНОЕ ОПИСАНИЕ

Варианты реализации могут осуществляться программным обеспечением (иногда называющимся лицензионным внутренним кодом, микропрограммой, микрокодом, милликодом, пикокодом и тому подобным, каждое из которых будет соответствовать изложенному здесь). Согласно ФИГ.1А, программная реализация программного кода обычно считывается процессором, также известным как ЦПУ (центральное процессорное устройство) 1 системы 50 из постоянного запоминающего устройства 11, такого как привод CD-ROM, ленточный накопитель или жесткий диск. Программный код программы может быть реализован в одном из множества известных носителей для использования с системой обработки данных, таком как дискета, жесткий диск или CD-ROM. Код может распространяться на таких носителях, или может распространяться к пользователям из компьютерной памяти 2 или запоминающего устройства одной компьютерной системы через сеть 10 к другим компьютерным системам для использования пользователями таких других систем.

Или же, программный код может быть реализован в памяти 2, и считываться процессором 1 при помощи процессорной шины. Такой программный код включает операционную систему, которая управляет функционированием и взаимодействием различных компонентов компьютера, и одну или больше прикладных программ. Программный код обычно постранично считывается из жесткого запоминающего устройства 11 в высокоскоростную память 2, где он доступен для обработки процессором 1. Методики и способы реализации программного кода программы в памяти, на физическом носителе, и/или распространения программного кода через сети хорошо известны и далее не будут здесь обсуждаться. Программный код, будучи создан и сохранен на физическом носителе (включая, но не ограничиваясь, электронные модули памяти (RAM), флэш-память, компакт-диски (CD), DVD, магнитную ленту и тому подобное) часто называются «компьютерным программным продуктом». Носитель компьютерного программного продукта обычно считывается обрабатывающей схемой предпочтительно в компьютерной системе для выполнения обрабатывающей схемой.

На ФИГ.1В изображена представительная аппаратная система рабочей станции или сервера. Система 100 на ФИГ.1В содержит представительную компьютерную систему 101, такую как персональный компьютер, рабочая станция или сервер, включая опциональные периферийные устройства. Рабочая станция 101 включает один или более процессоров 106 и шину, использующуюся для соединения и обеспечения связи между процессор(ами) 106 и другими компонентами системы 101 в соответствии с известными методиками. Шина соединяет процессор 106 с памятью 105 и постоянным запоминающим устройством 107, которое может включать жесткий накопитель (включая любой из магнитных носителей, CD, DVD и флэш-память, к примеру) или ленточный накопитель, к примеру. Система 101 также может включать адаптер пользовательского интерфейса, который соединяет микропроцессор 106 через шину с одним или более интерфейсных устройств, таких как клавиатура 104, мышь 103, принтер/сканер 110 и/или другие интерфейсные устройства, которые могут быть любым устройством пользовательского интерфейса, таким как сенсорный экран, графический планшет и т.п. Шина также соединяет устройство отображения 102, такое как жидкокристаллический экран или монитор, с микропроцессором 106 через видеоадаптер.

Система 101 может связываться с другими компьютерами или сетями компьютеров посредством сетевого адаптера, способного связываться 108 с сетью 109. Примерами сетевых адаптеров являются каналы связи, token ring, Ethernet или модемы. Или же, рабочая станция 101 может связываться с помощью беспроводного интерфейса, такого как карта передачи цифровых пакетных данных по сотовой связи (CDPD, cellular digital packet data). Рабочая станция 101 может быть связана с другими такими компьютерами в локальной сети (Local Area Network, LAN) или глобальной сети (Wide Area Network, WAN), или рабочая станция 101 может быть клиентом в конфигурации клиент/сервер с другим компьютером и т.д. Все эти конфигурации, а также соответствующее аппаратное и программное обеспечение связи, известны из уровня техники.

На ФИГ.2 изображена сеть обработки данных 200, в которой варианты могут быть реализованы. Сеть обработки данных 200 может включать множество индивидуальных сетей, таких как беспроводная сеть и проводная сеть, каждая из которых может включать множество индивидуальных рабочих станций 101 201 202 203 204. Дополнительно, как будет понятно специалистам из уровня техники, может быть включена одна или более LAN, где LAN может включать множество интеллектуальных рабочих станций, соединенных с основным процессором.

Согласно той же ФИГ. 2, сети могут также включать компьютеры-мейнфреймы или серверы, такие как машина-шлюз (клиент-сервер 206) или сервер приложений (удаленный сервер 208, который может обращаться к репозиторию данных, и к которому также можно обращаться напрямую с рабочей станции 205). Машина-шлюз 206 служит точкой входа в каждую сеть 207. Шлюз необходим при соединении одного сетевого протокола с другим. Шлюз 206 предпочтительно может соединяться с другой сетью (Интернет 207, к примеру) при помощи линии связи. Шлюз 206 также может соединяться напрямую с одной или более рабочих станций 101 201 202 203 204 при помощи линии связи. Машина-шлюз может быть реализована с использованием сервера IBM eServer™ zSeries® z9®, доступного от корп. IBM.

Программный код программы обычно считывается процессором 106 системы 101 из постоянного запоминающего устройства 107, такого как привод CD-ROM или жесткий диск. Программный код программы может быть реализован в одном из множества известных носителей для использования с системой обработки данных, таком как дискета, жесткий диск или CD-ROM. Код может распространяться на таких носителях, или может распространяться к пользователям 210 211 из памяти или запоминающего устройства одной компьютерной системы через сеть к другим компьютерным системам для использования пользователями таких других систем.

Или же, программный код 111 может быть реализован в памяти 105, и считываться процессором 106 при помощи процессорной шины. Такой программный код включает операционную систему, которая управляет функционированием и взаимодействием различных компонентов компьютера, и одну или больше прикладных программ 112. Программный код обычно постранично считывается из жесткого запоминающего устройства 107 в высокоскоростную память 105, где он доступен для обработки процессором 106. Методики и способы реализации программного кода программы в памяти, на физическом носителе, и/или распространения программного кода через сети хорошо известны и далее не будут здесь обсуждаться. Программный код, будучи создан и сохранен на физическом носителе (включая, но не ограничиваясь, электронные модули памяти (RAM), флэш-память, компакт-диски (CD), DVD, магнитную ленту и тому подобное) часто называются «компьютерным программным продуктом». Носитель компьютерного программного продукта обычно считывается обрабатывающей схемой предпочтительно в компьютерной системе для выполнения обрабатывающей схемой.

Кэш, который наиболее легкодоступен процессору (обычно быстрее и меньше, чем другие кэши процессора) является наинизшим кэшем (уровня один или L1), a главное запоминающее устройство (главная память) является кэшем наивысшего уровня (L3, если есть 3 уровня). Кэш наинизшего уровня часто делится на кэш команд (I-Cache), хранящий машинные команды для выполнения, и кэш данных (D-Cache), хранящий операнды данных.

Согласно ФИГ.3, изображена примерная реализация процессора для процессора 106. Обычно один или более уровней кэша 303 задействуются для буферизации блоков памяти, чтобы улучшить производительность процессора. Кэш 303 является высокоскоростным буфером, хранящим строки кэша данных из памяти, которые, вероятно, будут использоваться. Обычные строки кэша содержат 64, 128 или 256 байт данных из памяти. Отдельные кэши чаще используются для кэширования команд, чем для кэширования данных. Согласованность кэша (синхронизация копий строк в памяти и кэшах) часто обеспечивается различными алгоритмами слежения, хорошо известными из уровня техники. Главная память 105 процессорной системы часто называется кэшем. В процессорной системе, имеющей 4 уровня кэша 303, главная память 105 иногда называется кэшем уровня 5 (L5), поскольку она обычно более быстрая и хранит только часть постоянного запоминающего устройства (DASD, лента и т.п.), которое доступно компьютерной системе. Главная память 105 «кэширует» страницы данных, перемещаемые в и из главной памяти 105 операционной системой.

Программный счетчик (счетчик команд) 311 отслеживает адрес текущей команды для выполнения. Программный счетчик в процессоре z/Architecture 64-битный и может быть усечен до 31 или 24 бит для поддержки предыдущих границ адресации. Программный счетчик обычно встроен в слово статуса программы (PSW, program status word) компьютера, так что он сохраняется во время контекстного переключения. Таким образом, работающая программа, имеющая значение программного счетчика, может быть прервана, например, операционной системой (контекстное переключение из среды программы в среду операционной системы). PSW программы сохраняет значение программного счетчика, пока программа неактивна, а программный счетчик (в PSW) операционной системы используется, пока операционная система выполняется. Обычно программный счетчик увеличивается на величину, равную числу байт текущей команды. Команды архитектуры с сокращенным набором команд (RISC, Reduced Instruction Set Computing) обычно имеют постоянную длину, тогда как команды архитектуры с полным набором команд (CISC, Complex Instruction Set Computing) обычно имеют переменную длину. Команды архитектуры IBM z/Architecture являются командами CISC, имеющими длину 2, 4 или 6 байт. Программный счетчик 311 модифицируется либо операцией контекстного переключения, либо операцией выбора ветви команды ветвления, к примеру. В операции контекстного переключения текущее значение программного счетчика сохраняется в слове статуса программы (PSW) вместе с другой информацией о состоянии программы, которая выполняется, (такой как коды состояния), и загружается новое значение программного счетчика, указывающее на команду нового программного модуля для выполнения. Операция выбора ветви производится для того, чтобы позволить программе принимать решения или замыкать цикл внутри программы, загружая результат команды ветвления в программный счетчик 311.

Обычно устройство считывания команд 305 задействуется для считывания команд для процессора 106. Устройство считывания либо считывает «следующие команды в последовательности», целевые команды команд выбора ветви, либо первые команды программы вслед за контекстным переключением. Современные устройства считывания команд часто задействуют методики предварительного считывания для предположительного предварительного считывания команд на основе вероятности того, что предварительно считанные команды могут использоваться. Например, устройство считывания может считать 16 байт команды, которая включает следующую команду в последовательности и дополнительные байты дальнейших команд в последовательности.

Затем считанные команды выполняются процессором 106. В варианте реализации считанные команд(ы) проходят через устройство передачи 306 устройства считывания. Устройство передачи декодирует команд(ы) и направляет информацию о декодированных команд(ах) соответствующим устройствам 307, 308, 310. Устройство выполнения 307 обычно получит информацию о декодированных арифметических командах из устройства считывания команд 305 и выполнит арифметические операции над операндами в соответствии с кодом операции команды. Операнды предоставляются устройству выполнения 307 предпочтительно либо из памяти 105, архитектурных регистров 309, либо из непосредственного поля команды, которая выполняется. Результаты выполнения, если сохраняются, сохраняются либо в памяти 105, регистрах 309, либо в другом аппаратном обеспечении машины (таком как управляющие регистры, регистры PSW и тому подобное).

Согласно ФИГ.5, изображена примерная среда виртуальной машины (VM). Программа-гипервизор (которая может сама быть операционной системой (OS), такой как zVM от IBM) может быть запущена на многопроцессорном «аппаратном обеспечении», содержащем множество физических процессоров, физическую главную память и физические адаптеры для связи с периферийными устройствами ввода-вывода, включая запоминающие устройства, сети, дисплеи и тому подобное. Гипервизор создает образы VM (VM1, VM2 и VM3, например), так что программное обеспечение, включая OS и прикладные программы, может запускаться внутри виртуальной машины, используя виртуальные ресурсы. Программное обеспечение, запущенное в VM, не знает, что запущено в VM, и работает, используя виртуальные ресурсы, как если бы это были физические ресурсы. Операционная система zVM от IBM может создавать «гостевые» образы, каждый гостевой образ фактически является виртуальной машиной. Более того, любой гость zVM может сам запускать zVM OS, создающую «гостей второго уровня». Таким образом, виртуальная машина (гостевой образ) может быть вложена в иерархии виртуальных машин, а каждая zVM играет роль гипервизора для ее гостевых образов. С другой стороны, многопроцессорная платформа может быть «физически распределена», и каждому физическому разделу могут быть назначены ресурсы (процессоры, память, ввод-вывод). Каждый физический раздел является VM, так как программное обеспечение, запущенное в разделе, не знает о ресурсах машины, не назначенных разделу. Таким образом, ресурсы машины «виртуализуются». В другом варианте реализации логические разделы являются VM.

Термины «Гости», «Виртуальные Машины» (VM) и «Логические разделы» могут использоваться в данном контексте взаимозаменяемо, так как есть много способов, известных из уровня техники, для виртуализации образа компьютерной системы.

Виртуализация описана, например, в официальной документации VMware®, озаглавленной «Virtualization Overview» («Обзор виртуализации») и «VMware VMotion and CPU Compatibility» («VMware VMotion и совместимость ЦПУ») VMware® инфраструктуры 3 от VMware®. Далее, в патентной заявке США, публикация №2009/0070760 «Миграция виртуальных машин (VM) между архитектурами процессора» авторства Khatri и др., поданной 6 сентября 2007, обсуждается эмуляция набора некоторых особенностей для обеспечения миграции VM между одинаковыми пулами машин посредством маскировки выбранных бит регистра CPUID.

Согласно ФИГ.6, каждая VM может иметь различную OS и различные приложения. Например, OS1 может быть z/OS от IBM, a OS2 может быть zLinux от IBM, или все OS могут быть одинаковыми OS, такими как z/OS.

Гипервизор создает Логические Особенности, ресурсы и средства для каждой VM на основе физических особенностей, ресурсов и средств. В примерной системе части Физической Памяти могут быть выделены каждой VM посредством Динамической Трансляции Адресов, физические процессоры могут быть разделены во времени между VM, как и средства ввода-вывода.

Согласно ФИГ.7, каждый логический процессор может иметь доступ к регистрам физических особенностей посредством управляемой Гипервизором Маски Логических Особенностей. Таким образом, программное обеспечение, запущенное на логических процессорах, может создать видимость работы на общем уровне Архитектуры процессора, даже если действительные процессоры находятся на различных уровнях архитектуры. В примере, регистр Физических Особенностей может быть регистром Intel CPUID, который указывает уровень архитектуры процессора Intel, а также специфические особенности, которые доступны программисту. Маска Логических особенностей программируется для предоставления CPUID всех или подмножества физических процессоров программному обеспечению в Виртуальной Машине (VM), когда VM запрашивает CPUID соответствующего Логического процессора.

Архитектура процессора х86 от Intel®, «Intel® Itanium® Architecture Software Developer's Manual» (Руководство разработчика программного обеспечения для архитектуры Intel® Itanium®), том 2, редакция 2.2, январь 2006, предоставляет регистры CPUID для идентификации особенностей, поддерживаемых процессором. Регистры CPUID непривилегированны и доступны при помощи косвенной команды перемещения (из). Все регистры за пределами номера регистра CPUID зарезервированы и выдают ошибку Зарезервированного Регистра/Поля, если к ним обращаются. Запись не разрешена и не существует команды для такой операции. Информация о поставщике располагается в регистрах CPUID 0 и 1 и указывает название поставщика в ASCII, для реализации процессора. Все байты после конца строки вплоть до 16-го байта равны нулю. Первые символы ASCII располагаются в регистрах с низшим номером и в разрядах с низшим номером. Регистр CPUID 4 предоставляет общие сведения уровня приложения об особенностях процессора. Он содержит набор бит флага, использующихся для обозначения того, что данная особенность поддерживается в модели процессора. Если бит равен единице, особенность поддерживается; если 0, особенность не поддерживается. Так как добавляются (или удаляются) новые особенности в будущих моделях процессоров, присутствие (или удаление) новых особенностей будет обозначаться новыми битами особенностей. Регистр CPUID 4 логически разбит на две половинки, каждая из которых содержит общие сведения об особенностях и возможностях, но каждая имеет различные модели использования и возможности доступа; эти сведения отображают статус любых включенных и выключенных особенностей. Как нижняя, так и верхняя половины регистра CPUID 4 доступны через команду перемещения косвенного регистра; в зависимости от реализации, латентность для такого доступа может быть большой, и этот способ доступа не подходит для низколатентного управления версиями кода с использованием самостоятельного выбора. Кроме того, верхняя половина регистра CPUID 4 также доступна при помощи команды проверки особенностей; латентность для этого доступа сравнима с таковой команды проверки бита, и этот способ доступа позволяет низколатентное управление версиями кода с использованием самостоятельного выбора.

z/Architecture Principles of Operation предоставляет команду расширенного сохранения списка средств (Store Facility List Extended, STFLE), которая, подобно регистру Intel CPUID, обеспечивает программное обеспечение сведениями об особенностях (или уровнях архитектуры) нижележащих центральных процессорных устройств (ЦПУ), или процессоров. Команда STFLE имеет формат, приведенный в Таблице 1 ниже.

Команда STFLE (Таблица 1) содержит биты поля Кода Операции (0-15), поле регистров B2 (16-19) и поле смещения (непосредственное) D2 (20-31). Выполнение команды STFLE машиной сохраняет список бит, предоставляющих информацию о средствах, в ячейку памяти программ, определенную прибавлением содержимого регистра, заданного полем В2 команды, к 12-битному непосредственному полю D2, ячейка памяти начинается с двойного слова (8 байт, слово равно 4 байтам), заданного адресом второго операнда ((B2)+D2). Адрес ячейки программной памяти в z/Architecture подвергается Динамической Трансляции Адресов (Dynamic Address Translation, DAT).

Зарезервированные биты являются битами, которые сейчас не предназначены для обозначения особенности. Для самых левых двойных слов, в которых назначены биты средства, зарезервированные биты сохраняются как нули. Двойные слова справа от двойного слова, в котором бит средств