ДИСПЕТЧЕРИЗАЦИЯ МНОЖЕСТВЕННЫХ ПОТОКОВ В КОМПЬЮТЕРЕ Российский патент 2018 года по МПК G06F9/455 

Уровень техники

Настоящее изобретение относится, в общем, к многопоточности (МТ) и, прежде всего, к реализации машины для диспетчеризации множественных потоков в компьютере.

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

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

Сущность изобретения

Варианты осуществления включают в себя систему, способ и компьютерный программный продукт для диспетчеризации многопоточной гостевой виртуальной машины (VM). Согласно одному аспекту компьютерная система включает в себя конфигурацию с машиной, активированной для эксплуатации в режиме единственного потока (ST) и в многопоточном (МТ) режиме. Кроме того, машина включает в себя физические потоки. Машина сконфигурирована для выполнения способа, включающего в себя выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевого логического объекта, включающего в себя множественные логические потоки на ядре. Гостевой логический объект включает в себя, полностью или частично, гостевую VM, а выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST. Выполнение команды запуска VE машиной включает в себя построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков, инициализацию каждого из приведенных к соответствию физических потоков с состоянием соответствующего ему логического потока, и запуск выполнения гостевого логического объекта на ядре в режиме МТ.

Согласно другому аспекту предоставляется компьютерно-реализуемый способ диспетчеризации многопоточной гостевой виртуальной машины (VM) в конфигурации. Конфигурация включает в себя машину, имеющую единственное ядро, активированное для функционирования в режиме единственного потока (ST) и в многопоточном (МТ) режиме. Ядро включает в себя физические потоки. Способ включает в себя выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевого логического объекта, включающего в себя множественные логические потоки на ядре. Гостевой логический объект включает в себя, полностью или частично, гостевую VM, а выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST. Выполнение команды запуска VE машиной включает в себя построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков, инициализацию каждого из приведенных к соответствию физических потоков с состоянием соответствующего ему логического потока, и запуск выполнения гостевого логического объекта на ядре в режиме МТ.

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

Краткое описание нескольких видов чертежей

Рассматриваемый в качестве вариантов осуществления объект изобретения, прежде всего, указан и недвусмысленно заявлен в пунктах формулы изобретения в конце технического описания. Упомянутые ранее и другие признаки и преимущества вариантов осуществления являются очевидными из последующего подробного описания, рассматриваемого совместно с сопровождающими чертежами, на которых:

Фиг. 1 изображает вычислительное окружение, которое может быть реализовано согласно варианту осуществления,

Фиг. 2 изображает физический процессор, который может быть реализован согласно варианту осуществления,

Фиг. 3 изображает вычислительное окружение, которое может быть реализовано согласно варианту осуществления,

Фиг. 4 изображает описание состояния многопоточного (МТ) логического потока согласно варианту осуществления,

Фиг. 5 изображает блок-диаграмму маски (TVM) допустимости потока согласно варианту осуществления,

Фиг. 6 изображает группу описаний состояния фиксированного смещения согласно варианту осуществления,

Фиг. 7 изображает группу описаний состояния, задаваемую в виде списка адресов, согласно варианту осуществления,

Фиг. 8 изображает группу описаний состояния, задаваемую в виде связанного списка, согласно варианту осуществления,

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

Фиг. 10 изображает процесс диспетчеризации ядра согласно варианту осуществления,

Фиг. 11 изображает скоординированный выход из виртуального выполнения согласно варианту осуществления,

Фиг. 12 изображает блок-диаграмму области управления системы согласно варианту осуществления,

Фиг. 13 изображает последовательность операций для координирования между многопоточными ядрами согласно варианту осуществления, и

Фиг. 14, которая включает в себя фиг. 14А и 14Б, изображает машинную реализацию диспетчеризации ядра согласно варианту осуществления,

Фиг. 15, которая включает в себя фиг. 15А и 15Б, изображает машинную реализацию скоординированного выхода из виртуального выполнения согласно варианту осуществления, и

Фиг. 16 изображает машиночитаемый носитель согласно варианту осуществления.

Подробное описание

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

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

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

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

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

Когда гостевое логическое ядро включает в себя множественные потоки, один из логических потоков назначают первичным потоком, а остальные назначают вторичными потоками. Термин «первичный» относится к логическому потоку. Физический поток не является с аппаратной перспективы ни первичным, ни вторичным потоком, он становится первичным потоком, как только на нем выпускается команда запуска VE с заданной МТ. Причина этого временного различия на физическом уровне состоит в том, что при возвращении управление обратно к хосту, это обычно делается на первичном потоке, то есть, управление возвращается обратно к гипервизору на том же самом физическом потоке, на котором был выпущена команда на запуск VE.

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

Дополнительные варианты осуществления направлены к машинной реализации скоординированного выхода из диспетчеризированного МТ гостевого логического ядра обратно к ST хосту (например, гипервизору). В варианте осуществления милликод используется для синхронизации системы, что включает в себя координацию всех отдельных потоков путем учета каждого из их текущих состояний. Вариант осуществления может также включать в себя обработку высокоприоритетных прерываний при удержании низкоприоритетных прерываний, которые могут задержать выход. Закрытие вторичных потоков может быть осуществлено способом, обеспечивающим наиболее эффективное использование ресурсов ядра после завершения выхода. Например, милликод может деактивировать конкретные прерывания для воспрепятствования использованию ресурсов ядра для диспетчеризации обработчика прерываний милликода, когда это не является необходимым. Милликод может также использоваться для указания на то, что конкретные физические регистры более не используются, и являются свободными для их использования посредством работающего ST.

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

При рассмотрении в настоящем документе, термин «физическое ядро» относится к аппаратному процессору, выполняющему один или несколько независимых потоков команд или потоков исполнения, но совместно использующему несколько базовых ресурсов, таких как устройства выполнения и кэши низкого уровня. Такое совместное использование может быть осуществлено многими способами, включая сюда использование каждым потоком тех же аппаратных ресурсов в независимые моменты времени или логическое совместное использование ресурсов каждым физическим входом, тегированным идентификатором потока. Надлежащий синергетический эффект взаимодействия между потоками, например одним потоком, который часто нуждается в ресурсе А, но только изредка в ресурсе В, и другим потоком, который обычно использует ресурс В, но не ресурс А, может повысить эффективность такого совместного использования. При рассмотрении в настоящем документе, термин «машина» относится к аппаратным средствам, входящим в состав физического ядра, а также к милликоду и другому встроенному программному обеспечению, используемому для поддержки физического ядра.

При рассмотрении в настоящем документе, термины «гостевая VM» и «гость» используются попеременно для обращения к единственной гостевой конфигурации, которая может включать в себя единственный ЦП или множественные ЦП. При рассмотрении в настоящем документе, термин «логическое ядро» относится к группе логических гостевых потоков или ЦП, заданных для совместной диспетчеризации в качестве части команды запуска VE, где задается МТ. Гостевая VM может быть образована из единственного логического ядра (либо ST, либо МТ) или из множественных логических ядер (каждое из которых также может быть представлено ST или МТ).

При рассмотрении в настоящем документе, термин «программное обеспечение» относится или к программе гипервизора (например, PR/SM или zVM) или к гостевой операционной системе или к прикладной программе, которая диспетчеризируется в результате команды запуска VE.

При рассмотрении в настоящем документе, термины «гипервизор» и «хост» относятся к программе, администрирующей системные ресурсы и диспетчеризирующей гостевой логический процессор (процессоры) для выполнения на физическом оборудовании.

Операнд команды запуска VE, используемый для диспетчеризации гостя, указывает на описание состояния или на группу описаний состояния, которая задает состояние данного гостевого процессора или ядра. Описание состояния как таковое имеет указатели на «вспомогательные блоки», которые могут быть рассмотрены как расширение описания состояния, и включают в себя дополнительную информацию, которая, кроме того, задает состояние данного гостевого ядра или процессора. При рассмотрении в настоящем документе, термин «описание состояния» относится не только к самому описанию состояния, но также и к соответствующим вспомогательным блокам. Ориентированная на ядро область (COSCA) управления системы, один из таких вспомогательных блоков изображен на фиг. 12.

Обращаясь теперь к фиг. 1, в общем, показано вычислительное окружение 100, которое может быть реализовано посредством образцового варианта осуществления. Вычислительное окружение 100 может базироваться, например, на z/Архитектуре, предлагаемой International Business Machines Corporation, Армонк, Нью-Йорк, z/Архитектура описана в публикации IBM® под названием «z/Архитектура, принципы работы» (z/Architecture, Principles of Operation), публикация № SA22-7932-09, август 2012, включенной в настоящий документ путем отсылки в полном объеме. В одном примере, вычислительное окружение на основании z/Архитектуры включает в себя eServer zSeries, предлагаемый International Business Machines Corporation, Армонк, Нью-Йорк.

В качестве примера, вычислительное окружение 100 может включать в себя процессорный комплекс 102, присоединенный к контроллеру 120 системы. Процессорный комплекс 102 может включать в себя, например, один или несколько разделов 104 (например, логических разделов LP1-LPn), одно или несколько физических ядер 106 (например, Core 1, Core m), а также гипервизор 108 уровня 0 (например, администратор логического раздела), каждый из которых элементов описан ниже.

Каждый логический раздел 104 может быть способным к функционированию в качестве отдельной системы. Это означает, что каждый логический раздел 104 может быть при желании независимо сброшен, первоначально загружен операционной системой 110, и может работать с различными программами. Операционная система 110 или прикладная программа, работающая в логическом разделе 104, представляется как имеющая доступ к полной системе, но в действительности, только ее часть является доступной. Комбинация аппаратных средств и лицензированного внутреннего кода (обычно называемого микрокодом или милликодом или встроенным программным обеспечением) предохраняет программу в одном логическом разделе 104 от вмешательства со стороны программы в другом логическом разделе 104. Это позволяет нескольким различным логическим разделам 104 действовать на единственном или множественных физических ядрах 106 способом с квантованием времени. В варианте осуществления каждое физическое ядро включает в себя один или несколько центральных процессоров (также называемых в настоящем документе «физическими потоками»). В показанном на фиг. 1 примере каждый логический раздел 104 имеет резидентную операционную систему 110, которая может отличаться для одного или нескольких логических разделов 104. Операционная система 110, выполняющаяся в каждом логическом разделе 104, является примером гостевой конфигурации или виртуальной машины. В одном варианте осуществления операционная система 110 является операционной системой z/OS®, предлагаемой International Business Machines Corporation, Армонк, Нью-Йорк.

Физические ядра 106 включают в себя ресурсы физического процессора, выделяемые логическим разделам 104. Логический раздел 104 может включать в себя один или несколько логических процессоров, каждый из которых представляет, полностью или частично, выделенные разделу 104 физические процессорные ресурсы. Физические ядра 106 могут быть либо выделены разделу таким образом, что физические процессорные ресурсы лежащего в основе ядра (ядер) 106 резервируются для данного раздела 104, либо быть используемыми совместно с логическими ядрами другого раздела 104 таким образом, что физические процессорные ресурсы лежащего в основе ядра (ядер) 106 являются потенциально доступными другому разделу.

В варианте осуществления, показанном на фиг. 1, логическими разделами 104 управляет гипервизор 108 уровня 0, который реализован посредством встроенного программного обеспечения, работающего на физических ядрах 106. Каждый из числа логических разделов 104 и гипервизора 108 содержит одну или несколько программ, находящихся в соответствующих, связанных с физическими ядрами 106 участках центрального запоминающего устройства (памяти). Один пример гипервизора 108 представлен администратором ресурсов процессора/системы Processor Resource/Systems Manager (PR/SM™), предлагаемым International Business Machines Corporation, Армонк, Нью-Йорк.

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

Обращаясь теперь к фиг. 2, в общем, показана согласно варианту осуществления блок-диаграмма устройства 200 обработки данных для реализации машины или физического ядра, такого как физическое ядро 106 на фиг. 1. Устройство обработки данных 200 может включать в себя одно физическое ядро из числа нескольких физических ядер в многопроцессорном окружении. Показанное на фиг. 2 устройство 200 обработки данных включает в себя интерфейсное устройство 202 контроллера системы, которое может соединять устройство 200 обработки данных с другими ядрами и периферийными устройствами. Интерфейсное устройство 202 контроллера системы может также соединять Dcache 204, который считывает и сохраняет значения данных, Icache 208, который считывает программные команды, а также интерфейсное устройство 206 кэша с внешней памятью, процессорами и другими периферийными устройствами.

Icache 208 может предоставлять загрузку потоков команд совместно с устройством 210 выборки команд (IFU), которое выбирает команды с упреждением и может включать в себя инструменты упреждающей загрузки и предсказания ветвлений. Выбранные команды могут быть предоставлены устройству 212 декодирования команд (IDU) для декодирования в данные для обработки команд.

IDU 212 может предоставлять команды выпускающему устройству 214, которое может управлять выпуском команд к различным устройствам выполнения, таким как одно или несколько арифметических устройств 216 для выполнения операций с фиксированной точкой (FXU) для выполнения общих операций, а также одному или нескольким устройствам 218 для операций с плавающей точкой (FPU) для выполнения операций с плавающей точкой. Устройства FPU 218 могут включать в себя двоичное устройство 220 для операций с плавающей точкой (BFU), десятичное устройство 222 для операций с плавающей точкой (DFU) или любое другое устройство для операций с плавающей точкой. Выпускающее устройство 214 может также быть соединено с одним или несколькими устройствами 228 загрузки и хранения (LSU) через один или несколько конвейеров LSU. Множественные конвейеры LSU обрабатываются как устройства выполнения для выполнения загрузок и сохранений и генерации адресов для ответвлений. Как LSU 228, так и IFU 210 могут использовать ассоциативный буфер 230 трансляции (TLB) для предоставления буферизованных трансляций для адресов операндов и команд.

FXU 216 и FPU 218 соединены с различными ресурсами, такими как регистры 224 общего назначения (GPR) и регистры 226 с плавающей точкой (FPR). GPR 224 и FPR 226 предоставляют память значений данных для значений данных, загруженных и сохраненных от Dcache 204 LSU 228.

Обращаясь теперь к фиг. 3, в общем, показано вычислительное окружение 300, которое может быть реализовано посредством варианта осуществления. Показанное на фиг. 3 вычислительное окружение 300 является подобным вычислительному окружению 100, показанному на фиг. 1, с добавлением гипервизора 302 уровня 1, который осуществляет выполнение в логическом разделе 104, промаркированном LP2. Как показано на фиг. 3, гипервизор 302 уровня 1 может предоставлять те же функции гипервизора, как описанные ранее относительно гипервизора 108 (также называемого в настоящем документе «гипервизором уровня 0»), такие как прозрачное временное квантование ресурсов между множественными операционными системами (например, OS1 314, OS2 312 и OS3 310, работающими в виртуальных машинах VM1 304, VM2 306 и VM3 308), а также изоляция таких операционных систем друг от друга в пределах логического раздела 104, промаркированного LP2. Показанный на фиг. 3 вариант осуществления включает в себя, в качестве примера, три виртуальные машины, а другие варианты осуществления могут включать в себя большее или меньшее число виртуальных машин, в зависимости от требований к приложению.

Как показано на фиг. 3, промаркированный LP1 логический раздел 104 имеет резидентную операционную систему 110, а промаркированный LP2 логический раздел 104 выполняет гипервизор 302 уровня 1, который, в свою очередь, создает виртуальные машины 304, 306, 308, каждая из которых выполняет свои собственные резидентные операционные системы 314, 312, 310. Любой из числа логических разделов 104 может выполнять гипервизор 302 уровня 1. В варианте осуществления гипервизор 302 уровня 1 является z/VM гипервизором, предлагаемым International Business Machines Corporation, Армонк, Нью-Йорк. Резидентные операционные системы, работающие в различных логических разделах, могут отличаться друг от друга и, при выполнении под гипервизором 302 уровня 1, резидентные операционные системы (например, операционные системы 314, 312, 310) в пределах единственного раздела 104 (например, LP2) также могут отличаться. В варианте осуществления операционная система 110 в промаркированном LP1 логическом разделе 104 является операционной системой z/OS, предлагаемой International Business Machines Corporation, Армонк, Нью-Йорк. В варианте осуществления операционные системы 310 и 312 представлены Linux, а операционная система 314 представлена z/OS.

Когда гипервизор 302 уровня 1 работает в логическом разделе 104, он может предоставлять ту же виртуализацию ресурсов, которую предоставляет гипервизор уровня 0, такой как гипервизор 108, к логическим разделам 104 к операционным системам 310, 312, 314, работающим в виртуальных машинах 308, 306, 304. Как и на первом уровне, каждая виртуальная машина может включать в себя множественные виртуальные процессоры.

Физические ядра 106 включают в себя ресурсы физического процессора, которые могут быть выделены или совместно использованы, как описано для фиг. 1, логическими разделами 104 LP1, LP2, LP3 и LP4. Когда логический раздел LP2 диспетчеризируется на одно или несколько физических ядер, гипервизор 302 уровня 1 может в этом случае прозрачно разделить эти ресурсы между его виртуальными машинами VM1 304, VM2 306 и VM3 308. В одном варианте осуществления гипервизор 108 уровня 0 использует команду запуска VE с заданной МТ для диспетчеризации многопоточного гипервизора 302 уровня 1, который в этом случае использует команду запуска VE с заданной ST для диспетчеризации однопоточных виртуальных машин VM1 304, VM2 306 и VM3 308. В другом варианте осуществления гипервизор 108 уровня 0 использует команду запуска VE с заданной ST для диспетчеризации однопоточного гипервизора 302 уровня 1, который в этом случае использует команду запуска VE с заданной МТ для диспетчеризации многопоточных виртуальных машин VM1 304, VM2 306 и VM3 308. В другом варианте осуществления как гипервизор 302 уровня 1, так и все его гостевые VM 304, 306, 308 являются однопоточными.

В гостевом многопроцессорном (MP) окружении гипервизор может поддерживать управляющую структуру, известную как область управления системы (SCA), использующуюся как гипервизором, так и машиной для администрирования определенных функций, которые могут затрагивать множественные логические процессоры в гостевой конфигурации. Для всех гостевых процессоров в конфигурации или виртуальной машины в описании состояния задают одинаковый адрес (SCAO) начала SCA. В варианте осуществления эта область может включать в себя общую область (используемую, в целом, для координирования гостевых функции по всей конфигурации) и отдельные, специфичные для процессора записи. Общая область, например, содержит информацию относительно того, какие виртуальные процессоры в пределах гостевой конфигурации являются допустимыми. Отдельная, специфичная для процессора область в пределах SCA может, например, использоваться для интерпретирования или эмулирования межпроцессорных гостевых функций, таких как межпроцессорное прерывание, или для предоставления легкодоступных указателей на соответствующее описание состояния каждого логического процессора. В варианте осуществления используемая для ST SCA расширяется для использования МТ путем добавления дополнительных, специфичных для потока записей для каждого потенциального гостевого потока.

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

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

Гостевая OS может использовать многопоточность путем простого выпуска команды задания МТ, обеспечивающей многопоточность в госте. Это позволяет гостевой OS обрабатывать эти новые потоки как дополнительные независимые ЦП и администрировать ими как в отсутствие многопоточности. Кроме того, гостевая OS может использовать эти потоки способом, усиливающим то обстоятельство, что они совместно используют ядро, или оно может принудить их к работе более взаимозависимым способом. Все это является прозрачным для гипервизора и машины. Гипервизор в этом случае предоставляет эти дополнительные потоки гостевой OS, в то время как сам гипервизор продолжает работать на единственном потоке на ядро и управлять большой частью гостевого МТ окружения на базе ядра. Активизация посредством OS многопоточности более подробно описана в патентной заявке США под номером патентного реестра POU92014US1, под названием «Сохранение контекста потока в многопоточной компьютерной системе», регистрируемой одновременно с настоящим документом, содержимое которой включено в настоящий документ путем отсылки в полном объеме. Копия входит в состав файла.

В варианте осуществления диспетчеризации ядра описание состояния, задаваемое в виде операнда команды запуска VE с заданной МТ, является «первичным» описанием состояния, а связанный гостевой логический поток является «первичным» потоком. Другие описания состояния в группе в настоящем документе называют «вторичными» описаниями состояния и, если применяются, относятся к вторичным логическим потокам. Когда группа описаний состояния реализована или как список или как кольцо, в первичном описании состояния может иметься поле следующего описания (NSD) состояния, указывающее на первое вторичное описание состояния, которое, в свою очередь, либо 1) указывает на следующее вторичное описание состояния в группе, либо 2) содержит значение для указания на конец группы. Значение NSD в описании состояния для последнего в списке может быть представлено адресом первичного описания состояния, в этом случае, список образует кольцо описаний состояния.

В реализации без МТ гипервизор диспетчеризирует одновременно на данном физическом ядре один гостевой логический процессор (также называемый в настоящем документе «логическим потоком»). Если конкретный логический процессор находится в недопустимом состоянии, например, в остановленном состоянии или в деактивированном ожидании, то гипервизор не диспетчеризирует этого гостя. В окружении МТ диспетчеризация ядра позволяет гипервизору одновременно диспетчеризировать на ядре множественные гостевые потоки. С целью приспособления к возможности того, что один или несколько из числа потоков в группе описаний состояния данного логического ядра являются недопустимыми, вариант осуществления использует в первичном описании состояния маску (TVM) допустимости потока, каждый бит которой указывает на допустимость, с точки зрения программного обеспечения, логического потока в соответствующем описании состояния в группе.

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

Обращаясь теперь к фиг. 4, в общем, показано согласно варианту осуществления описание состояния логического потока, включающего в себя большую часть архитектурно спроектированного состояния гостя.

В этом контексте термин «описание состояния» включает в себя не только само описание состояния, но также и вспомогательные блоки, указатели которых находятся в описании состояния, и которые действуют в качестве расширения. Как показано на фиг. 4, описание 400 состояния может включать в себя гостевые общие регистры (GR) 402, регистры (AR) 404 доступа, регистры (CR) 406 управления, гостевые таймеры 408 (включающие в себя компаратор часов и таймер ЦП), гостевой регистр 410 префикса, номер (VCN) 412 виртуального ЦП, слово (PSW) состояния программы и адрес (IA) 414 команды. Кроме того, оно может включать в себя управляющую информацию, такую как биты 420 управления (IC) перехватом, служащие для указания на то, требуют ли конкретные команды (например, загрузки слова (LPSW) состояния программы и объявления недопустимой записи (IPTE) таблицы страниц) перехвата к хосту, или требуется очистка гостевого ассоциативного буфера (TLB) трансляции перед началом выполнения гостевой команды. Описание состояния также содержит описание 422 (NSD) следующего состояния, которое используется для задания списков и колец описаний состояния, как описано на фиг. 6-9. Первичное описание состояния также включает в себя TVM 430, как описано на фиг. 5, и номер 432 (LPN) логического раздела.

Номер (VCN) 412 виртуального ЦП эквивалентен номеру ЦП, и потенциально приспособлен для включения в себя номера потока в режиме МТ, как описано в патентной заявке США под номером 14/226 947 (наш регистрационный номер POU92014US1) и под названием «Расширение и сокращение адреса в многопоточной компьютерной системе» (Address Expansion and Contraction in a Multithreading Computer System), регистрируемой одновременно с настоящим документом, содержимое которой включено в настоящий документ путем отсылки в полном объеме. Копия входит в состав файла.

Потоки в ядре могут быть идентифицированы посредством двоичной идентификации (TID) потока. Для краткости, на описываемых ниже чертежах поток х зачастую обозначается термином TIDx, что в данном случае, имеет значение «поток с TIDx».

Со ссылкой теперь на фиг. 5, в общем, показана согласно варианту осуществления блок-диаграмма маски (TVM) 520 допустимости потока. Как показано на фиг. 5, бит 0 530 в составе TVM 520 представляет допустимость логического потока 0 в группе описаний состояния, бит 1 531 представляет допустимость потока 1, бит 2 532 представляет допустимость потока 2, бит 3 533 представляет допустимость потока 3 и т.д., вплоть до бита n 537, представляющего допустимость потока n, последнего логического потока в группе описаний состояния, связанной с этим ядром. TVM может находиться в первичном описании состояния для группы.

Обращаясь теперь к фиг. 6, в общем, показана согласно варианту осуществления структура группы описаний состояния фиксированного смещения. Как показано на фиг. 6, группы описаний состояния задаются на фиксированных смещениях (N) друг от друга. В этом случае, операнд команды 602 запуска VE указывает на первичное описание 603 состояния для логического потока 0. Вторичное описание 605 состояния для логического потока х располагается с фиксированным смещением в N байтов после первичного описания состояния, и вторичное описание 607 состояния для логического потока у располагается на N байтов позади вторичного описания состояния для потока х. Такое расположение сохраняется для всех потоков в группе. Число потоков в группе может быть задано многими способами, включая сюда число отсчетов в первичном описании состояния или концевой маркер после последнего адреса описания состояния в списке.

Фиг. 6 может представлять два случая, в первом случае группа включает в себя описания состояния для всех логических потоков в группе, независимо от их допустимости или недопустимости, и во втором случае только допустимые описания состояния включаются в состав группы. В первом случае описание 605 состояния для потока х представляет состояние потока 1, а описание состояния 607 для потока у представляет состояние потока 2. TVM 620, которая является необходимой только в этом первом случае, представляет допустимость каждого из этих логических потоков. Во втором случае описание 605 состояния для потока х представляет состояние первого допустимого логического вторичного потока, а описание 607 состояния для логического потока у представляет состояние второго допустимого вторичного потока. Например, если поток 1 не является допустимым, а потоки 2 и 3 оба являются допустимыми, то поток х по описанию 605 представляет поток 2, а поток у по описанию 607 представляет поток 3.

В составе группы отсутствует какое-либо описание состояния для потока 1, поскольку он является недопустимым. Те же два случая могут также относиться к вариантам осуществления, показанным на фиг. 7-9 ниже, однако описан и изображен только случай 1.

Обращаясь теперь к фиг. 7, в общем, показана согласно варианту осуществления структура группы описаний состояния, задаваемой в виде списка. В этом случае операнд команды 702 запуска VE представляет список адресов описания состояния с первой записью 704 в списке, указывающей на первичное описание 705 состояния для потока 0, второй записью 706 в списке, указывающей на вторичное описание 707 состояния для потока 1, третьей записью 708 в списке, указывающей на вторичное описание 709 состояния для потока 2, и так далее, продолжаясь для всех потоков в группе. TVM 720 представляет допустимость каждого из этих потоков.

Обращаясь теперь к фиг. 8, в общем, показана согласно варианту осуществления структура группы описаний состояния, задаваемой в виде связанного списка. В этом случае, как в случае, изображенном на фиг. 6, операнд команды 802 запуска-VE указывает на первичное описание 803 состояния для потока 0, но, в отличие от примера на фиг. 6, указатель 804 для вторичного описания 805 состояния для потока 1 предоставляется в виде поля 804 следующего описания (NSD) состояния в первичном описании состояния. В свою очередь, указатель 806 для вторичного описания 807 состояния для потока 2 предоставляется как NSD 806 во вторичном описании состояния для потока 1. Это продолжается для всех потоков в группе с NSD 810 в описании 809 состояния для последнего n потока, которое задают нолями или некоторым другим уникальным значением, указывающим на конец списка. Предоставляемая в первичном описании 803 состояния TVM 820 представляет допустимость каждого из этих потоков.

Обращаясь теперь к фиг. 9, в общем, показана согласно варианту осуществления структура группы описания состояния, задаваемой в виде циклического списка или кольца. Этот случай является идентичным случаю показанному на фиг. 8 случаю в том отношении, что операнд команды 902 запуска VE указывает на первичное описание 903 состояния для потока 0, которое содержит NSD 904 для вторичного описания 905 состояния для потока 1, которое содержит NSD 906 для вторичного описания 907 состояния для потока 2, и это продолжается для всех потоков вплоть до последнего потока п. В варианте осуществления, показанном на фиг. 9, однако, NSD 910 в описании 909 состояния для потока n образует циклический список и указывает обратно на первичное описание 903 состояния. Предоставляемая в первичном описании 903 состояния TVM 920 представляет допустимость каждого из этих потоков.

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

Со ссылкой теперь на фиг. 10, в общем, показан согласно варианту осуществления процесс диспетчеризации ядра. Как показано на фиг. 10, гипервизор работает однопоточным образом на физическом ядре N 1010 и физическом потоке А 1020. В блоке 1022 гипервизор выпускает команду запуска VE с заданной МТ для диспетчеризации многопоточного гостевого ядра. Машина выявляет, что гость является многопоточным и, в блоке 1024, делает физические потоки В и С доступными для выполнения программного обеспечения. Машина загружает гостевое состояние из описания состояния для каждого из потоков в соответствующий физический поток. В варианте осуществления, изображенном на фиг. 10, машина использует несколько физических потоков для выполнения этой функции, то есть, работающий на физическом потоке А 1020 милликод загружает состояние гостевого логического потока X в физический поток А, как показано в блоке 1026. Аналогично, работающий на физических потоках В 1040 и С 1060 милликод загружает состояние гостевых логических потоков Y и Z в физические потоки В и С, как показано в блоках 1046 и 1066. Как только гостевое состояние загружено, работающее на гостевых логических потоках X, Y, и Z программное обеспечение выполняется на физических потоках А, В и С, как показано в блоках 1028, 1048 и 1068.

Со ссылкой теперь на фиг. 11, в общем, показан согласно варианту осуществления скоординированный выход из виртуального выполнения. Как показано на фиг. 11, гостевые логические потоки X, Y и Z выполняют гостевое программное обеспечение на физических потоках А 1120, В 1140 и С 1160, как обозначено в блоках 1128, 1148 и 1168. Один или несколько гостевых потоков выявляют потребность выхода из виртуального выполнения. Согласно фиг. 11, работающий на физическом потоке В 1140 гостевой логический поток Y выявляет, что он должен выйти из виртуального выполнения, как показано в блоке 1150, что принуждает машину отправить физическим потокам А 1120 и С 1160 сигнал о выходе из виртуального выполнения, как показано в блоке 1152. В блоках 1136, 1154 и 1174 работающий на каждом из физических потоков милликод координирует выход из виртуального выполнения, а затем делает физические потоки В 1140 и С 1160 недоступными для использования программным обеспечением, как обозначено в блоках 1156 и 1176. Милликод на физическом потоке А 1120 перезагружает состояние хоста в аппаратные средства, как показано в блоке 1138, что приводит к выполнению программного обеспечения гипервизора на физическом потоке А, как показано в блоке 1140. Гипервизор затем, по мере необходимости, обрабатывает любые незаконченные гостевые перехваты и прерывания хоста.

Фиг. 12 изображает согласно варианту осуществления блок-диаграмму ориентированной на ядро области (COSCA) управления системы для единственной гостевой конфигурации, включающей в себя множественные логические ядра. Показанная на фиг. 12 COSCA может использоваться для предоставления координации как между логическими потоками в ядре, так и между логическими потоками на различных ядрах. COSCA может включать в себя общую область, представляющую всю гостевую конфигурацию с указателями, по одному для каждого логического ядра, служащими для разделения областей описания ядра. Каждое описание ядра включает в себя общую область, представляющую это ядро, а также серию непрерывных, отдельных, специфичных для потока областей или описаний потока для этого ядра. В другом варианте осуществления описание ядра предоставляет местоположения описаний потока. Предоставляемые местоположения могут быть неявно заданными (например, они являются содержащимся в описании ядра списком, или они могут пребывать в блоках данных в памяти, которые следуют за описанием ядра). В других вариантах осуществления могут быть предоставлены указатели на другие содержащие описания потока местоположения памяти. При рассмотрении в настоящем документе, термин «указывает на местоположение» используется для отсылки к любому из упомянутых или к любому дополнительному способу указания на местоположение объекта (например, описания потока или другие элементы в COSCA). Такая структура поддерживает подобное дереву представление гостевой конфигурации МТ, облегчающее в некоторых ситуациях, в особенности на уровне гипервизора, процесс администрирования на основе ядра, но в других ситуациях, процесс администрирования на основе процессора или потока.

Тот же адрес (COSCAO) начала COSCA может быть предоставлен в поле адреса (SCAO) начала SCA в описаниях состояния для всех гостевых потоков в пределах гостевой конфигурации, а тот же адрес (CDAA) области описания ядра может быть предоставлен для всех потоков в данном ядре. Преимущество этого варианта осуществления состоит в том, что не требуется таких же объемов непрерывной реальной памяти, предоставление которой может быть затруднительным для некоторых гипервизоров. В другом варианте осуществления является возможным добавление дополнительного уровня косвенной адресации, и включение в каждое описание ядра списка указателей для каждой специфичной для потока области, что устраняет необходимость в блоках управления, поддерживающих непрерывность этих областей.

Со ссылкой теперь на фиг. 12, в общем, показан типовой вариант осуществления COSCA для единственной гостевой конфигурации, включающей в себя два логических ядра с тремя логическими потоками в каждом ядре. В варианте осуществления COSCA включает в себя содержимое общей области 1260 COSCA (показанной на фиг. 12 как «COSCACA 1260»), области 1270 описания ядра и области 1280 описания ядра. Первичное описание 1203 состояния для группы описаний состояния, связанной с логическим ядром 0, задается в виде операнда 1202 команды запуска VE, используемой гипервизором для диспетчеризации гостевого ядра 0. Кроме того, первичное описание 1233 состояния для группы описаний состояния, связанной с логическим ядром 1, задается в виде операнда 1232 команды запуска VE, используемой для диспетчеризации ядра 1. Это первичное описание 1203 состояния для «ядра 0 потока 0» содержит NSD01 1205, указывающий на вторичное описание 1213 состояния для ядра 0 потока 1, которое, в свою очередь, содержит NSD02 1215, указывающий на заключительное вторичное описание 1223 состояния для ядра 0 потока 2 в группе. Подобным образом, группа описаний состояния для логического ядра 1 начинается с первичного описания 1233 состояния для ядра 1 потока 0, содержащего NSD11 1235, указывающий на вторичное описание 1243 состояния для ядра 1 потока 1, содержащего NSD12 1245, указывающий на заключительное вторичное описание 1253 состояния для ядра 1 потока 2. Описания 1203, 1213, 1223, 1233, 1243, 1253 состояния для всех шести потоков в этой гостевой конфигурации содержат то же значение в SCAO 1204, 1214, 1224, 1234, 1244, 1254, которое указывает на общую область 1260 COSCA.

Общая область 1260 COSCA, как показано на фиг. 12, содержит информацию уровня ядра, используемую для координации функций для всей гостевой конфигурации. Общая область 1260 COSCA включает в себя маску (SCVM) допустимости ядра 1261 SCA, указывающую на допустимость каждого логического ядра в пределах гостевой конфигурации, а также включает в себя адрес (CDAA) области описания ядра для каждого ядра 1262, 1264. Как биты в SCVM, так и матрица адресов описаний ядра могут быть проиндексированы посредством номера ядра. CDAA0 1262, который указывает на область 1270 (CDA) описания ядра для ядра 0, включается в состав общей области 1260 COSCA. Кроме того, поле CDAA 1206, 1216, 1226 в описаниях состояния для всех потоков в ядре 0 также указывает на CDA 1270 для ядра 0. CDAA1 1264, указывающий на CDA 1280 для ядра 1, также включается в состав общей области 1260 COSCA и, аналогично, поле CDAA 1246, 1236, 1256 в описаниях состояния для всех потоков в ядре 1 также указывает на CDA 1280 для ядра 1. Область 1270 (CDA) описания ядра для ядра 0 содержит SCA маску 1271 (STVM0) допустимости потока, указывающую на допустимость каждого логического потока в пределах ядра 0. Она также содержит области описания потока ядра 0: для потока 0 - 1272, для потока 1 - 1274 и для потока 2 - 1276. CDA 1280 для ядра 1, подобным образом, содержит STVM1 1281 и области описания потока ядра 1: для потока 0 - 1282, для потока 1 - 1284 и для потока 2 -1286). Каждая из этих областей 1272, 1274, 1276, 1282, 1284, 1286 описания потока содержит адрес (SDA) 1273, 1275, 1277, 1283, 1285, 1287 описания состояния для потока, соответствующего данной области описания потока, ядро 0 поток 0, ядро 0 поток 1, ядро 0 поток 2, ядро 1 поток 0, ядро 1 поток 1 и ядро 1 поток 2, соответственно. Как биты в SCVM, так и матрица областей описаний потоков могут быть проиндексированы посредством идентификатора потока. Эти SDA облегчают для гипервизора администрирование потоками в ядре, а для машины - представление гостевых межпроцессорных прерываний.

Фиг. 13 изображает последовательность операций для администрирования многопоточными ядрами согласно варианту осуществления, в котором используется COSCA, показанная на фиг. 12. В показанном на фиг. 13 примере в блоке 1302 гостевая операционная система (OS), работающая на первом физическом потоке (например, ядро 0 поток 1, задан описанием 1213 состояния), выявляет свою готовность сигнализировать второму логическому потоку или целевому потоку (например, ядро 1 поток 2, задан описанием 1253 состояния). В блоке 1304 гостевая OS делает это, например, путем выпуска команды межпроцессорного прерывания. Машина, в качестве части выполнения команды межпроцессорного прерывания, использует COSCA для эмуляции гостевой команды межпроцессорного прерывания. Команда межпроцессорного прерывания эмулируется посредством машины, поскольку логическое ядро, включающее в себя целевой логический поток, может как быть, так и не быть диспетчеризованным на момент передачи сигнала. В блоке 1306 машина локализирует местонахождение (например, посредством SCA0 1214, поскольку команда межпроцессорного прерывания была выполнена посредством логического ядра 0 потока 1) общей области (например, общей области 1260 COSCA) для гостевой конфигурации с целью получения доступа к SCVM (например, SCVM 1261) для проверки допустимости целевого ядра и для получения соответствующего CDAA (например, CDAA1 1264, поскольку целевой поток находится на ядре 1).

Затем, в блоке 1308, машина локализирует местонахождение (например, посредством CDA1 1264) области описания ядра для целевого ядра (например, CDA 1280). Машина проверяет допустимость целевого потока путем получения доступа к STVM в области описания ядра (например, STVM1 1281 в CDA 1280). В блоке 1310 машина локализирует местонахождение области описания потока (например, области 1286 описания потока, соответствующей потоку 2, поскольку целевой поток является потоком 2). В блоке 1312 информация относительно прерывания регистрируется в области описания потока для целевого потока (например, этот процесс размещает идентификационные данные передающего потока в область 1286 описания потока). В блоке 1314 машина локализирует местонахождение (например, посредством SDA12 1287 в области 1286 описания потока) описания состояния для целевого потока (например, вторичного описания 1253 TID2 состояния для ядра 1). В блоке 1316 прерывание делается отложенным в целевом описании состояния (например, задается бит 1257 IP в описании 1253 состояния для ядра 1 TID2). В результате, когда целевой логический процессор (например, ядро 1 поток 2) диспетчеризируется на физическом потоке и активируется для прерывания, машина предоставляет прерывание, если оно активировано, для гостевой операционной системы. Если целевой логический процессор уже является диспетчеризованным на то время, когда прерывание становится отложенным, то он принимает прерывание, как только оно активируется.

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

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

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

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

Имеются некоторые операции, такие как очистка TLB, которые могут быть заданы для применения ко всему ядру. Это избавляет от нужды в выявлении для каждого потока потребности в его очистке и, при необходимости, в выполнении этой очистки. Кроме того, имеются некоторые ресурсы ядра, которые совместно используются или являются общими для физических потоков в ядре. Милликод может использовать в своих интересах то обстоятельство, что совместно используемые ресурсы нуждаются только в загрузке от единственного потока и, что единственный поток может загрузить все копии общих ресурсов потока, если такие действия могут быть распознаны как более экономные. Милликод VE записи может также использовать биты активации гостевой многопоточности и допустимости потока для обхода инициализации недопустимых логических потоков с целью ускорения выполнения милликода инициализации допустимых потоков. Гибкая конструкция аппаратных средств позволяет вариантам осуществления милликода оптимизировать их реализации по мере разработки проекта.

Обращаясь теперь к фиг. 14, которая включает в себя фиг. 14А и 14Б, в общем, показана согласно варианту осуществления машинная реализация диспетчеризации ядра. Как показано на фиг. 14А, в блоке 1400, диспетчеризация ядра инициализируется гипервизором, работающим на единственном потоке (называемом первичным потоком) с использованием команды запуска VE, в которой задается МТ. На основании выпуска гипервизором команды запуска VE милликод VE записи вызывается на первичном потоке, то есть выпускающем команду потоке, и он запускается путем инициализирования многопоточности на аппаратных средствах для всего ядра. Большая часть этой инициализации может включать в себя проверку битов состояния аппаратных средств от всех применимых вторичных потоков и/или задание битов или полей управления аппаратных средств во всех применимых вторичных потоках. Биты 1450 управления и состояния, показанные на фиг. 14А, могут логическим образом находиться в аппаратных средствах вторичного потока как такового или они могут логическим образом находиться в общих, совместно используемых потоками аппаратных ресурсах, которые, однако, представляют вторичный поток и управляют им. В блоке 1402 милликод VE записи с помощью маски (TVM) допустимости потока в описании состояния выявляет, какой гостевой логический поток (потоки) является допустимым в плане программного обеспечения, и поэтому должен быть загружен в аппаратные средства. Он также выявляет построение соответствий допустимых логических потоков к физическим потокам.

Блоки 1404-1414 на фиг. 14А выполняются посредством милликода для проверки доступности затребованных физических потоков. В блоке 1404 милликод препятствует принятию применимыми вторичными аппаратными потоками новых прерываний, которые могут вызывать внутренний код или изначально выполнять какой-либо новый программный код. Это может быть достигнуто путем задания соответствующих аппаратных управляющих элементов во вторичном потоке (потоках). В блоке 1406 выявляется, работает ли программное обеспечение на вторичных потоках. В варианте осуществления гипервизор, выпускающий команду запуска VE на первичном потоке, гарантирует, что другие аппаратные потоки на этом ядре не выполняют какой-либо программный код (например, гипервизорный или гостевой код). В другом варианте осуществления выпускающий команду запуска VE гипервизор может не быть в состоянии легко выявить, выполняют ли какие-либо другие, требующиеся для нового запуска VE аппаратные потоки, программный код, например код, связанный с независимым запуском VE. В этом случае милликод VE записи проверяет соответствующий бит (биты) состояния аппаратных средств на вторичном потоке (потоках) в блоке 1406.

Если в блоке 1406 выявляется, что программный код работает на аппаратных средствах, которые требуются для выполнения гостевого вторичного потока, новая команда запуска VE завершается, и в блоке 1408 гипервизор посредством машины информируется о том, что команда запуска VE оказалась неудачной и, потенциально, информируется о числе доступных на текущий момент времени аппаратных потоков. В результате, гипервизор может принять соответствующие меры, такие как сокращение числа допустимых гостевых потоков, которые подлежат диспетчеризации или ожидают в течение некоторого заданного времени, как обозначено блоком 1410, прежде нового выпуска команды запуска VE в блоке 1400. Если в блоке 1406 выявляется, что аппаратные средства являются доступными, то обработка продолжается к блоку 1412. В блоке 1412 милликод выявляет, например, путем проверки соответствующего бита (битов) состояния в аппаратных средствах, выполняет ли какой-либо применимый вторичный аппаратный поток (потоки) внутренний микропрограммный код. В таком случае, в одном варианте осуществления первичный поток ожидает окончания вторичным потоком (потоками) выполнения внутреннего кода и, в процессе ожидания, с целью предотвращения зависаний, первичный поток может принимать из очереди на обработку некоторые прерывания. Это может, однако, заблокировать вторичный поток (потоки) от принятия других прерываний таким образом, что они могут достигать состояния ожидания более быстро. Обработка в этом случае продолжается в блоке 1416. В другом варианте осуществления, если аппаратный поток выполняет внутренний микропрограммный код, как определено в блоке 1412, машина может аннулировать команду запуска VE и возвратить управление обратно гипервизору в блоке 1414. Это дает первичному потоку возможность принятия внутренних микропрограммных прерываний и предотвращения потенциальных зависаний и, как только никаких прерываний не находится на рассмотрении на первичном потоке, команда запуска-VE вновь выполняется. Оба эти варианта осуществления обладают преимуществами по сравнению с приостановкой внутреннего встроенного программного обеспечения и повторным его перезапуском на аппаратных средствах по завершении многопоточной работы, поскольку функционирование микропрограммного кода зачастую является важным для функционирования системы (многопоточного обновления, например) и, кроме того, потоки выполняют внутреннее встроенное программное обеспечение достаточно нечасто, что делает ожидание его окончания практичным решением.

Обработка в этом случае продолжается в блоке 1416 для запуска загрузки логического потока (потоков) в физические потоки на физическом ядре. В блоке 1416 милликод проверяет на конкретные условия исключений, и принимает относящиеся к ним исключения. Некоторые условия исключений могут относиться к команде запуска VE как таковой (например, недопустимая кольцевая структура описания состояния), а другие относятся к условиям, применимым к вторичному логическому потоку (например, исключение доступа на NSD). В блоке 1418 могут быть очищены записи гостевых аппаратных ассоциативных буферов (включая сюда TLB). Это может включать в себя, когда применимо, очистку ассоциативных буферов для вторичного потока (потоков). В блоке 1420 загружаются минимальные состояния из первичных и вторичных описаний состояния, а также инициализируются необходимые аппаратные средства, включая сюда каждый из допустимых потоков. В варианте осуществления минимальные состояния включают в себя адреса описаний состояния для вторичных потоков. В блоке 1422 задаются аппаратные управляющие элементы для вторичного потока (потоков) с целью прекращения выборки какого-либо внутреннего потока (потоков) команд. Это может упростить переключение от однопоточного выполнения к многопоточному выполнению. В блоке 1424 загружается адрес (milli-IA) команды милликода для каждого другого допустимого вторичного потока (потоков). Адрес milli-IA является местоположением, в котором вторичные потоки начинают выполняться, как только они начинают выбирать внутренний поток команд, и он обычно указывает на местоположение в милликоде, который завершает инициализацию каждого допустимого логического потока. Первичный поток продолжает свое выполнение милликода VE записи и, поэтому там не требуется загрузки каких-либо новых milli-IA. В блоке 1426, в одном варианте осуществления первичный поток активизирует вторичный поток (потоки) путем задания аппаратных управляющих элементов, изменяющих их режим выполнения на миллирежим, что принуждает их начинать выполнение в ранее загруженном milli-IA. В другом варианте осуществления первичный поток (Та) может активизировать первый вторичный поток (Tb),

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

Со ссылкой теперь на фиг. 14Б, в блоках 1428 и 1478 первичный поток и каждый допустимый вторичный поток выполняют милликод, требуемый для завершения загрузки связанного состояния гостевого логического потока в аппаратные средства. В варианте осуществления состояние включает в себя гостевые общие регистры (GR) 402, регистры (AR) 404 доступа, регистры (CR) 406 управления, регистр 408 префикса, гостевые таймеры 410, номер 412 (VCN) виртуального ЦП, слово (PSW) состояния программы и адрес (IA) 414 команды, биты управления (IC) 420 перехватом, и номер (LPN) 432 логического раздела, как показано на фиг. 4. В блоках 1430 и 1480 первичный поток и вторичные потоки завершают выполнение VE записи и выходят из режима милликода (например, миллирежима). В блоках 1432 и 1482 они начинают выполнение потока программных команд гостевого потока. В варианте осуществления завершение каждого потока VE записи является независимым от завершения других потоков. В другом варианте осуществления потоки синхронизируются перед завершением VE записи.

В варианте осуществления с целью поддержки использования диспетчеризации ядра и работы гипервизора в однопоточном режиме, может быть предоставлен скоординированный выход из виртуального выполнения (VE выход), при котором все гостевые потоки в данном ядре одновременно выходят обратно в ST хост. В контексте скоординированного VE выхода типы VE выхода могут быть разделены на три категории: (1) прерывания хоста, принадлежащие операции хоста, (2) прерывания хоста, принадлежащие гостевой операции, и (3) гостевые перехваты. Внешние для хоста, I/O и некоторые прерывания машинного контроля попадают в категорию (1) VE выхода. В этом случае, для позволения хосту обрабатывать прерывание требуется выход всех гостевых потоков из режима виртуального выполнения. Это прерывание, вероятным образом, принуждает хост диспетчеризировать другого гостя. Если прерывание происходит при выполнении в режиме виртуального выполнения, прерывание хоста либо может быть обнаружено на всех потоках таким образом, что они могут выйти из режима виртуального выполнения, либо может быть обнаружено на единственном потоке, который затем сигнализирует другим потокам в случае, если они должны выйти.

Категория (2) VE выхода, охватывающая принадлежащие гостю прерывания хоста, может включать в себя некоторые прерывания машинного контроля (такие как некорректируемая ошибка памяти). В немногопоточной ситуации эти состояния представляются как прерывания хоста. При диспетчеризации ядра имеется только один поток хоста, но поскольку эти исключения принадлежат гостевой операции, для множественных гостевых потоков является возможным обнаружение самых различных причин для того же прерывания хоста. Для приспособления к этому обстоятельству, при диспетчеризации ядра, когда применимо, эти прерывания хоста, вместо этого, располагают в соответствующем описании гостевого состояния как новый тип гостевого перехвата и обрабатывают аналогично категории (3), как описано ниже. В варианте осуществления прерывания ошибочной трансляции адресов хоста, возникающие вследствие гостевых ссылок на ячейку памяти, также попадают в категорию (2), и могут быть представлены в качестве другого нового типа гостевого перехвата.

Гостевые перехваты, также и в гостевом многопоточном окружении, для обеих категорий (2) и (3) VE выхода (см. выше) принадлежат одиночному гостевому потоку и являются независимыми от гостевого выполнения другого потока. Кроме того, является возможным, что множественные гостевые потоки распознают такие условия одновременно, что требует для всех них обработки хостом. Как правило, в случае перехвата, хост имитирует некоторую логику работы от имени гостя, а затем повторно диспетчеризирует того же гостя. Для этих случаев, поскольку хост работает однопоточным образом, все гостевые потоки должны выйти из режима виртуального выполнения прежде, чем хост сможет обрабатывать перехват (перехваты). Это может быть достигнуто либо посредством ожидания выхода всех потоков естественным образом, либо посредством передачи сигналов к выходу другим потокам, когда один поток выявил необходимость перехвата обратно к хосту. Это называют «скоординированным VE выходом».

По мере того, как каждый поток выявляет, что он должен выйти из режима виртуального выполнения, он входит в VE выход, и ожидает в начальном контуре синхронизации VE выхода до тех пор, пока все другие допустимые потоки также не окажутся готовыми к выходу. Если это требуется в реализации, то он отправляет другим потокам сигнал к выходу прежде вхождения в этот контур синхронизации. Во время пребывания в контуре синхронизации VE выхода обрабатывается только минимальное число прерываний. С целью обеспечения ситуации, в которой требуется выход гостевого потока из режима виртуального выполнения, когда не применяется какое-либо прерывание хоста и какой-либо гостевой перехват, задают перехват «без действий» для указания хосту, что в интересах этого гостя не требуется какое-либо действие перехвата.

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

Вариант осуществления включает в себя машинную реализацию скоординированного выхода из виртуального выполнения, включающего в себя приостановку многопоточного гостевого выполнения и возврат управления обратно к однопоточному хосту. В окружении МТ милликод выхода из виртуального выполнения (VE выхода), в большинстве случаев, несет ответственность за передачу сигналов другим допустимым гостевым потокам на выход из виртуального выполнения, как только это становится выполнимым. С позиции запрашивающего выход потока задержка может оказаться существенной, в особенности, если поток на текущий момент времени выполняет внутренний код, который не может быть прерван для выхода из виртуального выполнения. В то время как поток ожидает другие потоки для выхода из виртуального выполнения, милликод может использоваться для обработки некоторых прерываний, таких как те, которые могут привести к состояниям зависания, или тех, которые могут затронуть полную производительность системы. Обработка других прерываний милликодом может оказаться не оптимальной в том случае, когда они могут всего лишь задержать возможный выход в настоящее время из виртуального выполнения, о котором просигнализировали другие потоки (чья работа, возможно, была прервана). Это все должно быть сделано при продолжении поддержания надлежащего приоритета прерывания.

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

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

Как только любой поток выявляет потребность в выходе из виртуального выполнения, он сигнализирует другим потокам, как описано ниже, например, с отсылками на фиг. 15, которая включает в себя фиг. 15А и 15Б. Используемый процесс может изменяться в зависимости от того, является ли выходящий из виртуального выполнения поток первичным потоком или вторичным потоком.

В варианте осуществления первичный поток может сигнализировать допустимым вторичным потокам о выходе из виртуального выполнения, если удовлетворяются все следующие условия: (1) поток намеревается выйти из режима виртуального выполнения и возвратить управление обратно гипервизору, (2) все другие допустимые потоки еще не находятся в процессе выхода (то есть, по меньшей мере один поток все еще выполняет гостевые команды), (3) все другие потоки еще не получили сигнал о выходе, и (4) существует по меньшей мере еще один допустимый поток. Если эти условия не соблюдаются, каждый вторичный поток получает время на очистку и выход из виртуального выполнения независимым образом. В варианте осуществления вторичный поток сигнализирует первичному потоку (также и в случае, когда он является недопустимым), а также всем другим допустимым вторичным потокам о выходе из режима виртуального выполнения, если соблюдаются все вышеприведенные условия (1)-(4). В варианте осуществления вторичный поток должен отправить сигнал первичному потоку также и в том случае, когда он является единственным допустимым потоком, поскольку он должен сигнализировать первичному потоку о завершении скоординированного выхода из виртуального выполнения.

Обращаясь теперь к фиг. 15, которая включает в себя фиг. 15А и 15Б, в общем, показана согласно варианту осуществления машинная реализация скоординированного выхода из виртуального выполнения. В показанном на фиг. 15 примере первичный поток Р выполняет гостевой поток Р команд в 1502, вторичный поток А выполняет гостевой поток А команд в 1542, и вторичный поток В выполняет гостевой поток В команд в 1572. В блоке 1544 вторичный поток А выявляет, что он должен выйти из виртуального выполнения и, с помощью описанных выше критериев, выявляет в блоке 1546, что он должен сигнализировать другим потокам также выходить. Вторичный поток сигнализирует другим потокам путем преобразования внутреннего прерывания по запросу на выход из виртуального выполнения в отложенное прерывание в управляющем элементе состояния аппаратных средств первичного потока Р 1508 и в управляющем элементе состояния аппаратных средств вторичного потока В 1578. На фиг. 15А также показан управляющий элемент состояния аппаратных средств вторичного потока А 1548. При ответе на внутреннее прерывание в блоке 1510 для первичного потока Р и в блоке 1580 для вторичного потока В, каждый поток проверяет причину внутреннего прерывания и выявляет в блоке 1512 для первичного потока Р и в блоке 1582 для вторичного потока В, является ли внутреннее прерывание запросом на выход из виртуального выполнения. Если выявляется, что прерывание не является запросом на выход из виртуального выполнения, то первичный поток Р и вторичный поток В выполняют блоки 1514 и 1584, соответственно, для обработки другого запроса на прерывание.

Если прерывание является запросом на выход из виртуального выполнения, то в варианте осуществления каждый поток может независимо выполнять следующий процесс. В блоке 1516 для первичного потока Р и в блоке 1586 для вторичного потока В выявляется, является ли поток допустимым. Вторичный поток, который запрашивал выход из виртуального выполнения, может быть принят как допустимый. Для потока, выявленного в качестве допустимого, большая часть связанного гостевого состояния из аппаратных средств сохраняется в его собственном описании состояния. Это включает в себя, как показано на фиг. 4, гостевые общие регистры (GR) 402, регистры (AR) 404 доступа, регистры (CR) 406 управления, слово (PSW) состояния программы и адрес (IA) 414 команды. Гостевое состояние, которое не изменяется в процессе виртуального выполнения, такое как номер (VCN) 412 виртуального ЦП и номер (LPN) 432 логического раздела, не подлежит сохранению. Это показано на фиг. 15А в блоке 1518 для первичного потока Р, в блоке 1558 для вторичного потока А и в блоке 1588 для вторичного потока В. Каждый поток обновляет свое внутреннее состояние для указания на то, что он находится в начальной точке синхронизации милликода VE выхода. Это показано на фиг. 15А в блоке 1520 для первичного потока Р, в блоке 1560 для вторичного потока А, и в блоке 1590 для вторичного потока В.

Перед продолжением каждый поток ожидает достижения начальной точки синхронизации первичным потоком (например, первичным потоком Р), а также всеми допустимыми вторичными потоками (например, вторичными потоками А и В). Это показано на фиг. 15А в блоке 1521 для первичного потока Р, в блоке 1561 для вторичного потока А, и в блоке 1591 для вторичного потока В. Как только все потоки достигают начальной точки синхронизации в милликоде выхода из виртуального выполнения, каждый из потоков заканчивает обновление соответствующей информации в описании состояния. Примеры такой информации могут включать в себя таймер гостевого ЦП, который является частью гостевых таймеров 408 на фиг. 4. Это показано на фиг. 15А в блоке 1522 для первичного потока Р, в блоке 1562 для вторичного потока А, и в блоке 1592 для вторичного потока В. Задержка сохранения этого состояния до точки синхронизации улучшает стабильность гостевого согласования по времени между потоками.

Со ссылкой теперь на фиг. 15Б, каждый поток обновляет свое собственное внутреннее состояние для указания на то, что он находится в конечной точке синхронизации милликода VE выхода. Это показано на фиг. 115Б в блоках 1524 для первичного потока Р, в блоках 1564 для вторичного потока А, и в блоках 1594 для вторичного потока В. Кроме того, до продолжения к блоку 1528, первичный поток А ожидает достижения всеми потоками конечной точки синхронизации 1599 в блоке 1526. Каждый вторичный поток задает внутренний аппаратный бит на указание того, что он более не выполняет допустимый поток программных команд, принуждающий машину выходить из миллирежима и прекращать выполнение кода.

Это показано на фиг. 15Б в блоке 1566 для вторичного потока А, и в блоке 1596 для вторичного потока В. В варианте осуществления каждый вторичный поток не выполняет какой-либо программный код до следующего запуска VE, однако, он может, по мере необходимости, выполнять внутренний код для обработки внутренних прерываний.

Как только все потоки достигают конечной точки синхронизации в милликоде VE выхода, показанной как точка 1599 на фиг. 15Б, однопоточное выполнение запускается на первичном потоке Р. Первичный поток Р завершает очистку ядра в блоке 1528, загружает состояние гипервизора в аппаратные средства, включая сюда IA хост-программы, в блоке 1530, и выходит из миллирежима в блоке 1532. В результате, первичный поток Р работает в режиме хоста и обрабатывает любые соответствующие прерывания хоста, а гипервизор обрабатывает любые гостевые перехваты.

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

Варианты осуществления включают в себя систему, способ и компьютерный программный продукт для диспетчеризации многопоточной гостевой виртуальной машины (VM). Согласно одному аспекту компьютерная система включает в себя конфигурацию с машиной, активированной для эксплуатации в режиме единственного потока (ST) и в многопоточном (МТ) режиме. Кроме того, машина включает в себя физические потоки. Машина сконфигурирована для выполнения способа, включающего в себя выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевого логического объекта, включающего в себя множественные логические потоки на ядре. Гостевой логический объект включает в себя, полностью или частично, гостевую VM, а выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST. Выполнение команды запуска VE машиной включает в себя построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков, инициализацию каждого из приведенных к соответствию физических потоков с состоянием соответствующего ему логического потока, и запуск выполнения гостевого логического объекта на ядре в режиме МТ.

Согласно другому аспекту предоставляется компьютерно-реализуемый способ диспетчеризации многопоточной гостевой виртуальной машины (VM) в конфигурации. Конфигурация включает в себя машину, имеющую единственное ядро, активированное для функционирования в режиме единственного потока (ST) и в многопоточном (МТ) режиме. Ядро включает в себя физические потоки. Способ включает в себя выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевого логического объекта, включающего в себя множественные логические потоки на ядре. Гостевой логический объект включает в себя, полностью или частично, гостевую VM, а выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST. Выполнение команды запуска VE машиной включает в себя построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков, инициализацию каждого из приведенных к соответствию физических потоков с состоянием соответствующего ему логического потока, и запуск выполнения гостевого логического объекта на ядре в режиме МТ.

Другой аспект включает в себя компьютерный программный продукт для диспетчеризации многопоточной гостевой виртуальной машины (VM) в конфигурации. Конфигурация включает в себя машину, имеющую единственное ядро, активированное для функционирования в режиме ST и в режиме МТ. Кроме того, машина включает в себя физические потоки. Компьютерный программный продукт включает в себя машиночитаемый информационный носитель, имеющий воплощенными на нем программные команды, причем машиночитаемый информационный носитель не является сигналом. Программные команды могут быть считаны посредством устройства обработки данных для принуждения устройства обработки данных к выполнению способа. Способ включает в себя выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевого логического объекта, включающего в себя множественные логические потоки на ядре. Гостевой логический объект включает в себя, полностью или частично, гостевую VM, а выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST. Выполнение команды запуска VE машиной включает в себя построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков, инициализацию каждого из приведенных к соответствию физических потоков с состоянием соответствующего ему логического потока, и запуск выполнения гостевого логического объекта на ядре в режиме МТ.

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

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

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

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

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

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

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

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

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

Используемая в настоящем документе терминология служит исключительно целям описания конкретных вариантов осуществления и не предназначается для ограничения изобретения. При использовании в настоящем документе, формы единственного числа предназначены для включения в себя также и форм множественного числа, если только контекст не указывает на иное недвусмысленным образом. В последующем изложении подразумевается, что термины «содержит» и/или «содержащий» при их использовании в данном техническом описании задают присутствие заявленных признаков, целочисленных переменных, этапов, операций, элементов и/или компонентов, но не исключают присутствия или добавления одного или нескольких других признаков, целочисленных переменных, этапов, операций, элементов, компонентов и/или образованных ими групп.

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

Описания различных вариантов осуществления настоящего изобретения были предложены в целях иллюстрации, но не предназначаются для полного охвата или ограничения заявленных вариантов осуществления. Многие модификации и изменения являются очевидными для средних специалистов в области техники без отступления от существа и объема описанных вариантов осуществления. Используемая в настоящем документе терминология выбрана для наилучшего объяснения принципов вариантов осуществления, практического применения или технического улучшения по сравнению с имеющимися в коммерческом доступе технологиями, или для обеспечения другим средним специалистам в области техники возможности понимания описанных в настоящем документе вариантов осуществления.

Со ссылкой теперь на фиг. 16, в одном примере, компьютерный программный продукт 1600 включает в себя, например, один или несколько информационных носителей 1602, причем носители могут быть представлены материальными и/или энергонезависимыми носителями для хранения на них машиночитаемых средств программного кода или логики 1604 для предоставления и способствования реализации одного или нескольких аспектов описанных в настоящем документе вариантов осуществления.

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

Машиночитаемый информационный носитель может быть представлен материальным устройством, которое способно удерживать и сохранять команды для использования посредством устройства выполнения команд. Машиночитаемый информационный носитель может быть представлен, например, в том числе, но не ограничиваясь, устройством электронной памяти, магнитным запоминающим устройством, оптическим запоминающим устройством, электромагнитным запоминающим устройством, полупроводниковым запоминающим устройством или любой подходящей комбинацией из вышеупомянутого. Неисчерпывающий список более конкретных примеров машиночитаемого информационного носителя включает в себя следующее: портативная компьютерная дискета, жесткий диск, оперативная память (RAM), постоянная память (ROM), стираемая программируемая постоянная память (EPROM или флеш-память), статическая оперативная память (SRAM), переносной компакт-диск для однократной записи данных (CD-ROM), цифровой универсальный диск (DVD), карта памяти, гибкий диск, механически закодированное устройство, такое как перфокарты или выступающие структуры в канавке с записанными на них командами, а также любая подходящая комбинация из вышеупомянутого. Машиночитаемый информационный носитель, как он рассматривается в настоящем документе, не подлежит истолкованию в качестве представленного преходящими сигналами как таковыми, такими как радиоволны или другие свободно распространяющиеся электромагнитные волны, электромагнитные волны, распространяющиеся через волновод или другие среды передачи (например, проходящие через волоконно-оптический кабель световые импульсы), или передаваемые через провода электрические сигналы.

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

Машиночитаемые программные команды для выполнения операций настоящего изобретения могут быть представлены командами ассемблера, командами архитектуры системы команд (ISA), машинными командами, машинно зависимыми командами, микрокодом, командами встроенного программного обеспечения, присваивающими значение состоянию данными, или иным исходным кодом или объектным кодом, записанным на любой комбинации из одного или нескольких языков программирования, включая сюда объектно-ориентированные языки программирования, такие как Smalltalk, С++ и т.п., а также обычные языки процедурного программирования, такие как язык программирования «С» или подобные языки программирования. Машиночитаемые программные команды могут выполняться полностью на компьютере пользователя, частично на компьютере пользователя, как автономный пакет программного обеспечения, частично на компьютере пользователя и частично на удаленном компьютере или полностью на удаленном компьютере или сервере. В последнем сценарии удаленный компьютер может быть присоединен к компьютеру пользователя через любой тип сети, включая сюда локальную сеть (LAN) или глобальную сеть (WAN), или присоединение может быть сделано к внешнему компьютеру (например, через Интернет с использованием Интернет-провайдера). В некоторых вариантах осуществления электронные схемы, включающие в себя, например, программируемые логические схемы, программируемые на месте вентильные матрицы (FPGA) или программируемые логические матрицы (PLA) могут выполнять машиночитаемые программные команды посредством использования информации о состоянии машиночитаемых программных команд для настройки электронной схемы с целью выполнения аспектов настоящего изобретения.

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

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

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

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

Изобретение относится к диспетчеризации множественных потоков в компьютере. Техническим результатом является обеспечение диспетчеризации многопотоковой гостевой виртуальной машины. Компьютерная система содержит конфигурацию, содержащую машину, выполненную с возможностью эксплуатации в режиме единственного потока (ST) и в многопоточном (МТ) режиме. Дополнительно машина включает в себя физические потоки. Машина сконфигурирована для выполнения способа, содержащего выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевого логического объекта, включающего в себя множественные логические потоки на ядре. Гостевой логический объект включает в себя, полностью или частично, гостевую VM, а выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST. Выполнение команды запуска VE машиной включает в себя построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков, инициализацию каждого из приведенных к соответствию физических потоков с состоянием соответствующего ему логического потока и запуск выполнения гостевого логического объекта на ядре в режиме МТ. 3 н. и 12 з.п. ф-лы, 16 ил.

1. Компьютерная система для диспетчеризации многопоточной гостевой виртуальной машины (VM), причем компьютерная система содержит:

- конфигурацию, содержащую машину, включающую в себя единственное ядро, активированное для эксплуатации в режиме единственного потока (ST) и в многопоточном (МТ) режиме, причем ядро содержит физические потоки,

машина сконфигурирована для выполнения способа, содержащего:

- выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевой виртуальной машины (VM), содержащей множественные логические потоки на ядре, причем выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST, выполнение команды запуска VE машиной, содержащее:

- построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков,

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

- запуск выполнения гостевой VM на ядре в режиме МТ.

2. Компьютерная система по п. 1, содержащая:

- идентификацию того, какие логические потоки являются допустимыми, и

- построение соответствий только для допустимых логических потоков к соответствующему физическому потоку.

3. Компьютерная система по п. 1, причем инициализация включает в себя:

- загрузку для каждого из логических потоков одной части состояния логического потока в соответствующий физический поток,

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

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

4. Компьютерная система по п. 3, причем одна часть состояния включает в себя адрес описания состояния остальной части состояния.

5. Компьютерная система по п. 3, причем один из физических потоков выполняет загрузку для каждого из логических потоков одной части состояния логического потока.

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

7. Компьютерная система по п. 1, причем запуск выполнения для каждого из физических потоков осуществляется на основании завершения инициализации для физического потока.

8. Компьютерная система по п. 1, причем запуск выполнения для каждого из физических потоков осуществляется на основании завершения инициализации для всех физических потоков.

9. Компьютерная система по п. 1, причем выполнение, кроме того, содержит:

- выявление того, что программное обеспечение работает на одном из соотнесенных физических потоков, и

- на основании такого выявления уведомление хоста о неудаче выполнения команды запуска VE.

10. Компьютерная система по п. 1, причем выполнение, кроме того, содержит:

- выявление того, что встроенное программное обеспечение работает на одном из соотнесенных физических потоков, и

- на основании такого выявления выполнение по меньшей мере одного из действий:

- аннулирование команды запуска VE и возвращение управления к хосту, и

- ожидание восстановления доступности соотнесенного физического потока.

11. Компьютерно-реализуемый способ диспетчеризации многопоточной гостевой виртуальной машины (VM) в конфигурации, содержащей машину, включающую в себя единственное ядро, активированное для эксплуатации в режиме единственного потока (ST) и в многопоточном (МТ) режиме, причем ядро содержит физические потоки, и причем машина реализует способ, содержащий:

- выпуск команды запуска виртуального выполнения (запуска VE) для диспетчеризации гостевой виртуальной машины (VM), содержащей множественные логические потоки на ядре, причем выпуск команды выполняется хостом, работающим на одном из физических потоков на ядре в режиме ST, выполнение команды запуска VE машиной, содержащее:

- построение соответствия для каждого из логических потоков с соответствующим ему потоком из числа физических потоков,

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

- запуск выполнения гостевой VM на ядре в режиме МТ.

12. Способ по п. 11, содержащий:

- идентификацию того, какие логические потоки являются допустимыми, и

- построение соответствий только для допустимых логических потоков к соответствующему физическому потоку.

13. Способ по п. 11, причем инициализация включает в себя:

- загрузку для каждого из логических потоков одной части состояния логического потока в соответствующий физический поток,

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

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

14. Способ по п. 11, причем выполнение, кроме того, содержит проверку на то, что соотнесенные физические потоки на текущий момент времени не выполняют какой-либо программный код или внутренний код до инициализации.

15. Машиночитаемый информационный носитель, содержащий воплощенные на нем программные команды для диспетчеризации многопоточной гостевой виртуальной машины в конфигурации, включающей в себя машину, имеющую единственное ядро, активированное для функционирования в режиме единственного потока (ST) и в многопоточном (МТ) режиме, причем выполнение указанных программных команд посредством устройства обработки данных обеспечивает осуществление способа по одному из пп. 11-14.