[发明专利]用于在虚拟机监视器和符合ACPI的客户操作系统之间进行双向通信的方法、装置及系统

说明书

背景技术

高级配置与电源接口(“ACPI”，例如Revision 2.0b，October 11，2002)是用于平台配置和电源管理方案的开放工业标准规范。符合ACPI的操作系统(“OS”)通常通过两种方式与平台硬件进行交互。首先，硬件中的基本输入/输出系统(“BIOS”)可以产生由OS和其ACPI驱动器分析的一组存储器驻留表。这些表提供了在其他情况下不表示的所有平台硬件的软件列举的根。特别地，ACPI并不代表符合父总线标准(例如PC互联，“PCI”)的平台硬件，这是因为这种类型的硬件可以被列举并且使用所述标准来进行电源管理。所以，通常在ACPI表中声明的硬件是不能被列举的和/或使用总线标准来管理的平台硬件。换句话说，ACPI表包含平台中的所有特定于平台(即非总线标准)的硬件的列举和电源管理抽象。

由于平台硬件是相互依赖的，因此仅有一个“策略所有者”对其进行管理。在典型的计算环境中，OS管理平台资源。但在虚拟化的环境中，多个操作系统可以访问平台上的资源。虚拟技术使运行虚拟机监视器(“VMM”)的单个主机计算机能够提出主机的多个抽象和/或视图，从而主机的下层硬件呈现为一个或多个独立的操作虚拟机(“VM”)。每一VM可以用作自包含的平台，运行其自己的OS和/或软件应用。VMM通常管理主机上资源的分配以及执行上下文切换，这对根据round-robin或其他预定方案的不同的VM之间的循环是必需的。因此VMM负责与ACPI进行交互并避免资源冲突。

附图说明

通过示例对本发明进行说明，但本发明不受所附图示的限制，在附图中，相似的参考标记指示相似的元件，其中：

图1描述了典型的虚拟机主机的示例；

图2A-B进一步详细描述了本发明的各个实施例；

图3是描述本发明实施例的流程图；

图4是描述本发明实施例的流程图。

具体实施方式

本发明的实施例提供了用于在VMM和符合ACPI的客户(guest)操作系统(OS)之间进行双向通信的方法、装置和系统。说明书中的对本发明的“一个实施例”的引用表示结合该实施例描述的特定的特征、结构或特性至少包含在本发明的一个实施例中。因此，在本说明书中不同位置出现的短语“在一个实施例中”、“根据一个实施例”等并不一定指相同的实施例。

目前还没有一个方案可以利用，以在上述最后的场景(即，不包括主机OS的系统，例如管理程序)中解决来自主机上不同VM的变化的ACPI事件(例如，不同的ACPI启用/禁用操作、S-状态转换、C-状态转换、P-状态转换、T-状态转换和中断路由变更)。因此，例如，如果第一ACPI事件由第一VM生成且不同的ACPI事件由同一主机上的第二VM生成，当在这些事件之间发生冲突(例如，每一事件需要主机上的不同操作)时，目前还没有解决这些事件的方法。

本发明的实施例包括用于在VMM和符合ACPI的客户操作系统(OS)之间进行双向通信的方法、装置和系统。本领域技术人员可以理解，如果实施ACPI的替代方案，则客户OS符合替代方案。因此，出于本说明书的目的，在本文中对“OS”的任何引用均表示符合在平台上实现的电源配置和管理方案的操作系统。类似地，对ACPI和/或ACPI子系统的任何引用均应包括任何电源配置和管理方案，包括但不限于ACPI。

为了便于理解本发明的实施例，图1描述了典型的虚拟机主机平台(“主机100”)的示例。如上所述，虚拟机监视器(“VMM 130”)通常运行在主机平台上，并向其他软件呈现平台(也被称作“虚拟机”或“VM”)的抽象和/或视图。尽管仅示出了两个VM分区(“VM 110”和“VM 120”，下文中统称为“VM”)，但这些VM仅是说明性的，可以为主机添加额外的虚拟机。可以用软件(例如，实现为独立程序和/或主操作系统的部件)、硬件、固件和/或其任意组合来实现VMM130。

VMM 110和VM 120分别可以用作自包含平台，运行其自己的“客户操作系统”(即由VMM 130代管的操作系统，如图所示的“客户OS 111”和“客户OS 121”，在下文中统称为“客户OS”)和其他软件(如图所示的“客户软件112”和“客户软件122”，在下文中通称为“客户软件”)。每一客户OS和/或客软件以其仿佛是运行在专用计算机上而不是虚拟机上的方式来工作。也就是说，每一客户OS和/或客软件可以期望控制各种事件并访问主机100上的硬件资源。然而如上所述，实际上，VMM 130最终控制各个事件和硬件资源，并根据其自身的策略将资源分配给VM。