RU2429530C2

RU2429530C2 - Управление состоянием распределенных аппаратных средств в виртуальных машинах

Info

Publication number: RU2429530C2
Application number: RU2009111225/08A
Authority: RU
Inventors: Эдриан Дж. ОУНИ (US); Эдриан Дж. ОУНИ; Эндрю Джон ТОРНТОН (US); Эндрю Джон ТОРНТОН; Джейкоб ОШИНС (US); Джейкоб ОШИНС
Original assignee: Майкрософт Корпорейшн
Priority date: 2006-09-29
Filing date: 2007-08-28
Publication date: 2011-09-20
Also published as: KR20090074025A; BRPI0715921A2; CA2661025A1; US20080082975A1; BRPI0715921A8; EP2076843A1; AU2007300370A1; JP2010505198A; CN101523370A; EP2076843B1; US7877760B2; WO2008039625A1; NO20090937L; EP2076843A4; JP5050059B2; TW200821936A; MX2009002567A; RU2009111225A; CN101523370B

Abstract

Изобретение относится к области виртуальных машин. Техническим результатом является повышение эффективности управления состоянием распределенных аппаратных средств в виртуальных машинах. Система для управления операциями в среде виртуальных машин содержит: объект прокси-драйвера, расположенный в первом разделе, причем объект прокси-драйвера является прокси-драйвером для устройства; объект драйвера устройства, расположенный в стеке драйверов во втором разделе, причем объект драйвера сконфигурирован для управления упомянутым устройством; объект первого фильтра, расположенный под объектом драйвера устройства в упомянутом стеке драйверов, причем объект первого фильтра предоставляет интерфейс для объекта драйвера устройства, чтобы объект драйвера устройства участвовал в шинных функциях, включая управление упомянутым устройством; и объект второго фильтра, расположенный над объектом драйвера устройства в упомянутом стеке драйверов, причем объект второго фильтра сконфигурирован для выполнения по меньшей мере одной из следующих функций: (а) направлять первые инструкции от объекта прокси-драйвера объекту драйвера устройства и (b) перехватывать вторые инструкции, предназначенные для объекта драйвера устройства, причем упомянутые вторые инструкции происходят из упомянутого второго раздела. 3 н. и 17 з.п. ф-лы, 8 ил.

Description

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

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

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

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

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

фиг.5 показывает иллюстративную и неограничивающую реализацию системы с фиг.4;

фиг.6 подробно показывает поток пакетов запросов ввода-вывода (IRP - input/output request packets) через стек драйверов устройства (компонент системы с фиг.4);

фиг.7 показывает, как производятся операции изменения состояния plug-and-play и управления питанием; и

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

Подробное описание изобретения

Обзор

Предмет настоящего раскрытого изобретения вместе с решением упомянутых в разделе “Уровень техники” проблем обеспечивает по меньшей мере следующее: (a) способность доверенного раздела (которым зачастую является родительский раздел) выполнять полномашинные задачи, например “горячее” подключение устройства, спящий режим, отключение системы и так далее; (b) полномашинные задачи, которые могут выполняться либо в разделе, либо самим уровнем диспетчера виртуальных машин; (c) управление одним или более физических устройств недоверенным разделом при условии, что это управление не вызывает сбоя запущенного на той же машине другого программного обеспечения; и (d) предотвращение захвата всей машины, при котором невозможны спящий режим, отключение машины или подключение нового устройства.

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

Виртуальные машины в общих чертах

На фиг.1 изображена схема, представляющая логическое расслоение архитектуры аппаратных и программных средств для виртуализированной операционной среды в компьютерной системе. На фиг.1 программа 110 виртуализации запускается непосредственно или опосредованно на физической аппаратной архитектуре 112. Программой 110 виртуализации может быть (a) монитор виртуальных машин, запускаемый параллельно с размещающей операционной системой, или (b) размещающая операционная система с компонентом гипервизора, причем виртуализацию выполняет компонент гипервизора. Программа 110 виртуализации виртуализирует гостевую аппаратную архитектуру 108 (показанную пунктирными линиями, означающими, что этот компонент является разделом или “виртуальной машиной”), то есть аппаратные средства, которых на самом деле не существует, виртуализируются виртуализационной программой 110. Гостевая операционная система 106 запускается на гостевой аппаратной архитектуре 108, после чего программное приложение 104 может запускаться на гостевой операционной системе 106. В виртуализированной операционной среде с фиг.1 программное приложение 104 может запускаться в компьютерной системе 102, даже если программное приложение 104 предназначено для запуска на операционной системе, которая в общем случае несовместима с размещающей операционной системой и аппаратной архитектурой 112.

Фиг.2 иллюстрирует виртуализированную компьютерную систему, содержащую программный уровень 204 размещающей операционной системы (ОС), запускаемый непосредственно над физическими компьютерными аппаратными средствами 202, причем размещающая ОС 204 предоставляет доступ к ресурсам физических компьютерных аппаратных средств 202, обеспечивая интерфейсы для разделов A 208 и B 210 для возможности использования операционными системами A 212 и B 214 соответственно. Это позволяет размещающей ОС 204 оставаться незамеченной уровнями операционных систем 212 и 214, запущенными над ней. Опять же, для выполнения виртуализации размещающая ОС 204 может быть как специально разработанной операционной системой с заложенными виртуализационными возможностями, так и стандартной операционной системой с встроенным компонентом гипервизора для выполнения виртуализации (не показано).

Также по фиг.2 над размещающей ОС 204 есть два раздела: раздел A 208, который может быть, к примеру, виртуализированным процессором Intel 386, и раздел B 210, который может быть, к примеру, виртуализированной версией одного из процессоров семейства Motorola 680X0. Внутри каждого из разделов 208 и 210 есть гостевые операционные системы A 212 и B 214 соответственно. Над гостевой ОС A 212 запускаются два приложения: приложение A1 216 и приложение A2 218, а над гостевой ОС B 214 запускается приложение B1 220.

В отношении фиг.2 важно заметить, что раздел A 208 и раздел B 214 (показанные пунктирными линиями) являются виртуализированными компьютерными аппаратными представлениями, существующими только в виде программных конструкций. Их наличие становится возможным благодаря исполнению специализированных виртуализационных программных средств, которые не только предоставляют раздел A 208 и раздел B 210 гостевой ОС A 212 и гостевой ОС B 214 соответственно, но также выполняют все программные этапы, необходимые для того, чтобы гостевая ОС A 212 и гостевая ОС B 214 опосредованно взаимодействовали с настоящими физическими компьютерными аппаратными средствами 202.

Фиг.3 иллюстрирует альтернативную виртуализированную компьютерную систему, где виртуализация выполняется монитором виртуальных машин (VMM - virtual machine monitor) 204', запущенных параллельно с размещающей операционной системой 204”. В отдельных случаях VMM 204' может являться приложением, запущенным над размещающей операционной системой 204” и взаимодействующим с компьютерными аппаратными средствами 202 только через размещающую операционную систему 204”. В других случаях, как показано на фиг.3, VMM 204' может вместо этого содержать частично независимую программную систему, которая на некоторых уровнях опосредованно взаимодействует с компьютерными аппаратными средствами 202 через размещающую операционную систему 204”, но на других уровнях VMM 204' взаимодействует с компьютерными аппаратными средствами 202 непосредственно (аналогично случаю, когда размещающая операционная система непосредственно взаимодействует с компьютерными аппаратными средствами). В прочих случаях VMM 204' может содержать полностью независимую программную систему, которая на всех уровнях непосредственно взаимодействует с компьютерными аппаратными средствами 202 (аналогично случаю, когда размещающая операционная система непосредственно взаимодействует с компьютерными аппаратными средствами) без вовлечения размещающей операционной системы 204” (при этом продолжая взаимодействовать с размещающей операционной системой 204” с тем, чтобы согласовать использование компьютерных аппаратных средств 202 и избежать конфликтов и тому подобного).

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

Аспекты управления устройствами и состояниями системы в виртуальных машинах

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

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

К примеру, в одном неограничивающем аспекте настоящего раскрытия фиг.4 иллюстрирует систему управления операциями в среде виртуальных машин, обеспечивающую управление состоянием распределенных аппаратных средств. Иными словами, фиг.4 иллюстрирует, как, к примеру, объект 404 прокси-драйвера в основном разделе 400 может осуществлять связь с объектами 408, 406, 410 в стеке 416 драйверов, чтобы (даже если объект 406 драйвера устройства сохраняет управление над устройством 412) объект 404 прокси-драйвера все равно имел входные данные о том, как будет осуществляться управление таким устройством 412 способа, которым фильтры 408, 410 представляют инструкции объекту 406 драйвера устройства.

К примеру, второй фильтр 408 может пересылать инструкции от объекта 404 прокси-драйвера объекту 406 драйвера устройства, тем самым сообщая, каким будет поведение драйвера 406 устройства (и, следовательно, каким будет поведение устройства 412, управляемого объектом 406 драйвера устройства). Или, в противном случае, второй фильтр 408 может перехватывать инструкции, исходящие откуда-либо из второго раздела 402, и либо передавать их объекту 406 драйвера устройства, либо заменять их другими инструкциями, которые могут согласовываться с некоторыми политиками, установленными основным разделом 400 (причем такие инструкции могут, к примеру, предоставляться объектом 404 прокси-драйвера).

Таким образом, по фиг.4, согласно одному аспекту предмета настоящего раскрытия, может использоваться объект 404 прокси-драйвера, расположенный в основном разделе 400, причем объект 404 прокси-драйвера является прокси-драйвером для устройства 412. Иными словами, он, строго говоря, не является объектом драйвера для устройства 412, но ввиду того, что он может осуществлять связь с любыми из фильтров 408, 410 в стеке 416 драйверов и эти фильтры 408, 410 могут передавать (или не передавать) инструкции, которые увидит сам объект 406 драйвера устройства, он является драйвером устройства для устройства 412, даже через посредника.

Кроме того, на фиг.4 показан объект 406 драйвера устройства, расположенный в стеке 416 драйверов во вспомогательном разделе 402, причем объект 406 драйвера устройства настраивается для управления устройством 412. В стеке 416 драйверов можно увидеть объект 410 первого фильтра, расположенный под объектом 406 драйвера устройства. Объект 410 первого фильтра имеет много функций, одной из которых может быть предоставление интерфейса для объекта 406 драйвера устройства, чтобы объект 406 драйвера устройства мог участвовать в шинных функциях, включающих в себя управление устройством 412. Такие шинные функции, разумеется, не ограничиваются одним управлением устройством 412 и могут включать в себя получение информации, которую запрашивает объект 406 драйвера устройства, к примеру, первый фильтр 410 может выяснять у прокси-драйвера 404 информацию об адресном пространстве для устройства 412.

Дополнительно, объект 408 второго фильтра, расположенный над объектом 406 драйвера устройства в стеке 416 драйверов, может настраиваться так, чтобы (a) направлять первый набор инструкций от объекта 404 прокси-драйвера объекту 406 драйвера устройства и/или (b) перехватывать второй набор инструкций, предназначенный для объекта 406 драйвера устройства, причем вторые инструкции могут происходить из вспомогательного раздела 402. Это означает, что второй фильтр 408 может иметь двойную функцию: служить как механизм передачи инструкций от прокси-драйвера 404 драйверу 406 устройства и как механизм перехвата инструкций, выпущенных для драйвера 406 устройства, причем эти инструкции будут, как правило, выпускаться вспомогательным разделом 402, хотя могли бы выпускаться и другим разделом, например третичным недоверенным разделом.

В последнем случае при перехватывании вторых инструкций объект 408 второго фильтра может сравнивать вторые инструкции с политиками, установленными основным разделом 400 и/или виртуализационным модулем, таким как гипервизор, монитор виртуальных машин и прочее (показано на фиг.2 и 3). Если вторые инструкции конфликтуют с этими политиками, объект 408 второго фильтра может замещать эти инструкции такими, которые согласуются с политиками. Затем объект 408 второго фильтра может передавать эти согласованные инструкции объекту 406 драйвера устройства.

Согласно одному аспекту предмета настоящего раскрытия, по фиг.4, основной раздел 400 может иметь объект 414 (такой как объект диспетчера Plug-and-Play и/или объект диспетчера питания или любой другой объект, способный выпускать инструкции), осуществляющий связь с объектом 404 прокси-драйвера устройства, причем объект 414 основного раздела 400 указывает объекту 404 прокси-драйвера устройства реализовать события изменения состояния. Такие события изменения состояния могут передаваться через первые инструкции. Очевидно, что первые инструкции могут использоваться для вызова либо полносистемных событий, таких как отключение системы или ждущий режим системы для всей физической машины и каждого раздела, либо, в противном случае, более локальных событий, таких как команда, объекту 406 драйвера устройства отключить устройство 412.

Согласно другому аспекту система с фиг.4 может иметь объект 415 вспомогательного раздела (опять же такой, как объект диспетчера Plug-and-Play и/или объект диспетчера питания, или любой другой объект, способный выпускать инструкции), осуществляющий связь с объектом второго фильтра 408 через вышеупомянутые вторые инструкции. Объект 415 вспомогательного раздела может указывать объекту 408 второго фильтра реализовать инструкции, связанные с событием plug-and-play (подключение запоминающего устройства большой емкости, цифровой камеры и т.д.) и/или событием питания (отключение, переход в спящий режим и т.д.).

В случае перехвата или указания, если объект 406 драйвера устройства расходится по меньшей мере с одной политикой, установленной основным разделом 400 (то есть модулем в нем, таким как диспетчер 414), управление устройством 412 объектом 406 драйвера устройства может быть отменено. Эта отмена может зависеть от различных переменных, таких как набор строгих правил, стандартные указания и подобное. Специалисты в данной области техники без труда оценят множественность различных режимов проверки политик, которые могут реализоваться с описанным аспектом.

Эти аспекты лишь иллюстративные. Должно быть понятно, что, к примеру, каждое отношение с односторонней связью может влечь и обратную связь. Иными словами, если прокси-драйвер 404 может осуществлять связь с объектами 408, 406, 410 в стеке устройства, понятно, что противоположная связь также не исключена. Например, прокси-драйвер 404 может также принимать сообщения от объекта вспомогательного раздела 402, такие как запросы доступа к пространству настройки и другим ресурсам, которые не могут отображаться в памяти, или к I/O-пространству вспомогательного раздела 402.

Иллюстративные реализации управления операциями в виртуальных машинах

Для использования внутри виртуальных машин и разделов, показанных на фиг.2, 3 и 4, здесь предусмотрены различные операционные системы. К примеру, Windows, как правило, выполняет I/O посредством построения стеков объектов драйверов устройств, каждый из которых играет роль в управлении устройств и контроле над ними. Каждый отдельный I/O-пакет 418 запроса (IRP) может посылаться верхнему объекту драйвера (например, объекту 408 второго фильтра) внутри стека (например, стека 416 драйверов), который передает IRP вниз стека, когда заканчивает работу с ним. Каждый объект драйвера, в свою очередь, принимает IRP и выполняет надлежащую для своего уровня в стеке обработку. Самые нижние уровни, как правило, занимаются установкой и настройкой. К примеру, на фиг.5 этот нижний уровень соответствовал бы объектам “PCI.sys”, “VMBus.sys” и “ACPI.sys” (эти аббревиатуры означают объект “соединения периферийных компонентов” (PCI), объект “шины виртуальной машины” (VMBus) и объект “улучшенного интерфейса настройки и управления питанием” (ACPI)). Специалисты в данной области техники без труда распознают эти и любые другие использованные здесь аббревиатуры.

В Windows физические устройства (например, устройство 412) обнаруживаются шинными драйверами (например, “PCI.sys”), которым принадлежит управление всей шиной внутри физической компьютерной системы. Устройство может подключаться к шине “PCI Express” внутри системы и обнаруживаться драйвером шины “PCI Express” внутри Windows. Этот драйвер (“PCI.sys”) может участвовать в протоколе с диспетчером, например с диспетчером Plug-and-Play (PnP-диспетчером), который вызовет загрузку другого драйвера (называемого Функциональным Драйвером, или FDO (Functional Driver)). Этот FDO (например, драйвер 406 устройства) фактически управляет устройством. “PCI.sys” также может обеспечивать интерфейсы, которые характерны для настройки устройства PCI Express, позволяя FDO манипулировать устройством во время установки и настройки.

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

Фиг.5 показывает иллюстративную и неограничивающую реализацию предмета изобретения, рассмотренного на фиг.4. На фиг.5 в родительском (или доверенном) разделе 500 и дочернем (или недоверенном/непривилегированном) разделе 502 показан ряд стеков устройства с рядом PCI-шин. Это лишь иллюстративные разделы, которые соответствуют основному 400 и вспомогательному 402 разделам с фиг.4 соответственно. В различных доверенных и недоверенных отношениях могут использоваться другие разделы. Описанные стеки устройств могут быть множества типов, как то: видеоконтроллер 508, IDE-контроллер 510, стек 504 первой сети, стек 506 второй сети, стек 512 PCI-моста и корневой стек 514 PCI. Специалисты в данной области техники без труда распознают множественность разных стеков устройств, которые могут использоваться в типичной среде виртуальных машин.

На фиг.5 стеки устройства представлены прямоугольниками, а объекты устройств представлены овалами. Как уже упоминалось, самый нижний объект устройства в стеке может быть шинным драйвером, которым на фиг.5 является “PCI.sys” объект, за исключением случая с корневой шиной PCI. В этом примере корневую шину можно обнаружить в программно-аппаратных средствах ACPI, отчего “ACPI.sys” располагается внизу корневого стека 514 PCI. Другие объекты устройств, к примеру, “Net.sys” в стеке 504 Сети 1 или “Video” в стеке 508 Видео, располагаются над объектом PCI.sys и могут управлять физическими устройствами.

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

К примеру, если родительский раздел 500 хочет позволить дочернему разделу 502 непосредственно управлять устройством, возможно, сетевым интерфейсом, он может сначала выгрузить любой драйвер, в данный момент управляющий этим устройством в родительском разделе 500 (с тем, чтобы избежать любого конфликта с драйвером в дочернем разделе). Затем он может загрузить в родительском разделе 500 другой драйвер, приспособленный для управления запросами, передающимися дочернему разделу. На фиг.5 эта функция реализуется объектом “VMRedir.sys” в стеке 506 Сети 2. Таким образом, как предлагалось выше, объект “VMRedir.sys” в родительском разделе 500 является прокси-объектом для “Net.sys” объекта в стеке 516 Сети 2 дочернего раздела 502.

В дочернем разделе 502 драйвер может построить стек устройств, соответствующий физическому устройству (например, плате сетевого интерфейса (NIC)). Для этого может применяться любой набор драйверов устройства, распознающих виртуальную машину, но на фиг.5 показано, что применялся объект “VMBus.sys”, который может являться механизмом управления межраздельными I/O (см. № 11/128647, “Шина Разделов”, Досье Поверенного № MSFT-4771). Над этим объектом драйвера шины располагается уровень объекта устройства (“VMPCI.sys”), управляющего устройствами PCI Express, которые были определены дочернему разделу. Для этого над ним загружается стандартный драйвер (FDO) для PCI Express NIC (“Net.sys”). А над ним располагается уровень объекта другого устройства (опять же, “VMPCI.sys”) с целью перехвата некоторых IRP, посылаемых этому стеку изнутри вспомогательного раздела, и/или перенаправления инструкций от родительского раздела 500. И второй фильтр 408, и первый фильтр 410 с фиг.4 могут соответствовать объекту “VMPCI.sys” с фиг.5.

Далее фиг.6 более подробно иллюстрирует поток IRP 602 по стеку 516 драйверов устройств, показанному на фиг.5. Стрелки IRP 602 представляют поток в PnP-диспетчер и/или Диспетчер питания 600 (которые могут быть или не быть отдельными блоками) и из них. Верхний объект устройства (часть “VMPCI.sys”) перехватывает эти IRP и обращается с ними таким образом, что вспомогательный раздел 502 считает, будто этот стек устройств 516 учел каждую политику, поступившую изнутри вспомогательного раздела. Стрелки также показывают поток IRP 602, которые могут быть распознаны FDO, а именно “Net.sys”, и IRP, которые протекают вниз к драйверу шины (“VMBus.sys”).

На фиг.7 показано, как IRP 702 изменения состояния PnP и IRP 700 Управления Питанием (показаны пунктиром) могут посылаться в основной раздел 500, и как IRP 704 (также показаны пунктиром) пересылаются вспомогательному разделу 502. Эти IRP 704 по сути перенаправляются от объекта “PCI.sys” в сетевом стеке 506 основного раздела 500 к объекту “VMPCI.sys” в сетевом стеке 516 вспомогательного раздела 502. Затем объект “VMPCI.sys” (т.е. фильтр) может передавать их драйверу устройства “Net.sys” или использовать их как правила или указания для перехвата любых IRP 706 второго раздела 502.

Согласно одному аспекту предмета настоящего раскрытия IRP 702, посылаемые в основном разделе 500, могут вызвать посылку сообщений вспомогательному разделу 502. Эти сообщения могут возвращаться в IRP посредством VMPCI.sys и посылаться NIC-драйверу (т.е. “Net.sys”). NIC-драйвер может пересылать их (как и должен) объекту “VMPCI.sys”, и этот объект может удерживать их и не давать им пройти далее вниз по стеку. При этом любые IRP 706 изменения состояния, которые могут возникать внутри вспомогательного раздела 502 (по меньшей мере, частично показаны пунктиром), могут либо посылаться вниз по стеку к NIC-драйверу (т.е. “Net.sys”), либо обходить (708) его, поскольку уровни над и под “Net.sys” являются “VMPCI.sys” объектами.

Кроме того, любые попытки управлять устройствами на шинном уровне, возникающие у “Net.sys”, могут посылаться вниз по стеку к “VMPCI.sys” и обратно к основному разделу 500 и далее к объекту “PCI.sys”. Примеры управления на шинном уровне могут включать в себя запрос чтения пространства конфигураций сетевых устройств PCI Express. Специалисты в данной области техники, читая настоящее раскрытие, оценят множество других преобразований, обеспечиваемых рассмотренными выше аспектами. Никакие из этих аспектов не позиционируются как предельные и являются лишь иллюстративными.

Резюме

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

Потом, когда стек устройств с объектом первого фильтра, объектом драйвера устройства и объектом второго фильтра построен, этот стек устройств может взаимодействовать с объектом прокси-драйвера в другом разделе. Таким образом, в блоке 808 стек устройств может обрабатывать инструкции, IRP, сообщения и тому подобное (в сущности, любую информацию: код и/или данные). К примеру, в блоке 810 он может обрабатывать вышеупомянутый первый набор инструкций от объекта прокси-драйвера (причем такие инструкции могут иметь полносистемные или же только локальные эффекты). Кроме того, в блоке 812 он может обрабатывать второй набор инструкций, предназначенных для объекта драйвера устройства, причем вторые инструкции возникают в разделе (т.е. являются внутренними инструкциями того же раздела, что и стек, в отличие от межраздельных инструкций, возникающих в другом разделе) и могут осуществлять связь с событием plug-and-play и событием питания. Наконец, в блоке 814 первый фильтр может предоставлять интерфейс для объекта драйвера и получать необходимую для объекта драйвера информацию от другого раздела (например, шинную информацию).

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

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

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

Claims

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

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

3. Система по п.2, в которой упомянутый объект первого раздела является по меньшей мере одним из следующих: (а) объект диспетчера plug-and-play и (b) объект диспетчера питания.

4. Система по п.2, в которой упомянутое по меньшей мере одно событие изменения состояния является полносистемным событием.

5. Система по п.1, дополнительно содержащая объект второго раздела, осуществляющий связь с упомянутым по меньшей мере одним объектом второго фильтра через упомянутые вторые инструкции, причем упомянутый объект второго раздела указывает упомянутому по меньшей мере одному объекту второго фильтра реализовать инструкции, связанные по меньшей мере с одним из следующих событий: (а) событием plug-and-play и (b) событием питания.

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

7. Система по п.1, в которой, если упомянутый по меньшей мере один объект драйвера устройства расходится по меньшей мере с одной политикой, установленной упомянутым первым разделом, контроль упомянутого устройства упомянутым по меньшей мере одним объектом драйвера устройства отменяется.

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

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

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

11. Способ по п.8, дополнительно содержащий удаление объекта драйвера для упомянутого физического устройства из упомянутого другого раздела.

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

13. Способ по п.8, дополнительно содержащий перенаправление запросов для упомянутого объекта прокси-драйвера упомянутому стеку драйверов, причем упомянутые запросы имеют полносистемные эффекты.

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

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

16. Компьютерно-читаемый носитель, несущий компьютерно-исполняемые инструкции, реализуемые на физическом вычислительном устройстве, содержащие:
создание объектов прокси-драйверов в первом разделе, причем упомянутые объекты прокси-драйверов выступают в роли посредника для устройств;
создание объектов драйверов устройств в стеках драйверов во втором разделе, причем упомянутые объекты драйверов сконфигурированы для управления упомянутыми устройствами;
создание объектов первого фильтра под упомянутыми объектами драйверов устройств в упомянутых стеках драйверов, причем упомянутые объекты первого фильтра предоставляют интерфейсы для упомянутых объектов драйверов устройств, чтобы упомянутые объекты драйверов устройств управляли упомянутыми устройствами; и
создание объектов второго фильтра над упомянутыми объектами драйверов устройств в упомянутых стеках драйверов, причем упомянутые объекты второго фильтра сконфигурированы так, чтобы выполнять по меньшей мере одну из следующих функций: (а) направлять инструкции от первого раздела упомянутому объекту драйвера устройства и (b) перехватывать инструкции от второго раздела, предназначенные для упомянутого объекта драйвера устройства.

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

18. Компьютерно-читаемый носитель по п.16, дополнительно содержащий направление упомянутых инструкций от первого раздела упомянутым объектам драйверов устройств в ответ на запросы от управляющих модулей для упомянутых прокси-объектов устройств, причем упомянутые управляющие модули формируют набор модулей, включая диспетчеры plug-and-play и диспетчеры питания.

19. Компьютерно-читаемый носитель по п.16, дополнительно содержащий назначение упомянутого первого раздела доверенным разделом, а упомянутого второго раздела недоверенным разделом.

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