CN101470596A

CN101470596A - 虚拟化环境中的音频子系统共享

Info

Publication number: CN101470596A
Application number: CN200810189864.7A
Authority: CN
Inventors: A·辛哈尔; K·K·钦纳斯瓦米; D·沃雷尔; N·V·萨朗达
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2007-12-27
Filing date: 2008-12-26
Publication date: 2009-07-01
Anticipated expiration: 2028-12-26
Also published as: US8250573B2; CN101470596B; TW200937292A; TWI403955B; EP2075688A1; US20090171677A1

Abstract

公开了一种装置、方法以及系统。在一个实施例中，装置包含直接访问物理音频编解码器的第一虚拟机。装置也包含由第一虚拟机管理的虚拟音频编解码器。虚拟音频编解码器能为一个或多个另外的虚拟机(除第一虚拟机之外)提供到物理音频编解码器的定制接口。

Description

虚拟化环境中的音频子系统共享

技术领域

本发明涉及在计算机系统上运行的多个虚拟机之间共享计算机系统中的音频子系统。

背景技术

虚拟化是一种在常驻于计算机系统中的多个虚拟机(VM)之间共享计算机系统中可用的一些/所有资源/能力的机制。VM是像真实机器一样运行程序的机器(计算机)的软件实现。

在实现虚拟化的许多计算机系统中，通用操作系统(OS)，例如

，可运行在系统中的一个分区上的VM中。通用OS，此后称作能力OS(COS)，是能够独立地管理计算机系统上的所有资源以及提供所有服务给应用程序和更低级别的软件的操作系统。计算机系统中某些功能是重要的，即使在能力OS(COS)崩溃时仍需维持操作。应能够承受COS崩溃的一个应用程序是因特网语音协议(VoIP)应用程序。VoIP应用程序将受益于此以允许电话通话继续，即使COS崩溃。这将要求VoIP应用程序运行于能力OS分区之外。

随着不同的语音和音频应用程序运行在计算机系统上的多个VM/分区中越来越普遍，在任何给定系统中针对音频外设的使用的争夺可能增多。在许多实例中有多个VM，每个VM上运行着需要通过分立音频编解码器访问音频外设的应用程序。另外，在很多此类系统中，分立高清晰度(HD)音频编解码器芯片与音频控制器芯片配合操作以管理系统中的音频外设的使用。

发明内容

本发明提供一种装置，包括：直接访问物理音频编解码器的第一虚拟机；以及虚拟音频编解码器，由所述第一虚拟机管理，以为一个或多个另外的虚拟机提供到所述物理音频编解码器的定制接口。

本发明还提供一种方法，包括：直接访问物理音频编解码器，其中所述访问由第一虚拟机执行；以及为一个或多个另外的虚拟机提供到所述物理音频编解码器的定制接口。

本发明还提供一种系统，包括第一虚拟机以直接访问物理音频编解码器并将资源提供给运行在所述第一虚拟机上的服务操作系统，其中所述服务操作系统管理虚拟音频编解码器；所述虚拟音频编解码器，为一个或多个另外的虚拟机提供到所述物理音频编解码器的定制接口；以及所述一个或多个另外的虚拟机，将对所述虚拟音频编解码器的访问提供给一个或多个软件应用程序，所述一个或多个软件应用程序由运行在所述一个或多个另外的虚拟机中的至少一个上的至少一个能力操作系统管理。

附图说明

本发明通过示例的方式阐明且不由图限制，其中一样的标号表示相同的元件，其中：

图1描绘能够为系统上运行的多个虚拟机提供到物理音频编解码器的定制接口的计算机系统的一个实施例。

图2描绘虚拟音频编解码器的一个实施例。

图3更详细地描绘命令输出环缓冲器以及响应输入环缓冲器处理逻辑的一个实施例。

图4是方法的一个实施例的流程图，其通过单个虚拟机限制直接访问物理音频编解码器，同时为一个或多个其它的虚拟机提供到物理音频编解码器的定制虚拟接口。

具体实施方式

描述在虚拟化环境中共享音频子系统的方法、装置以及系统的实施例。在如下的描述中，阐明了大量具体细节。然而，应理解，可无需这些具体细节而实践这些实施例。在其它实例中，未详细讨论众所周知的元件、规范以及协议以免使本发明不明确。

图1描述了计算机系统的一个实施例，其能够为运行在系统上的多个虚拟机提供到物理音频编解码器的定制接口。图1中所示的计算机系统只不过是可包含下面图1-4中讨论的许多实施例的许多可能的计算机系统之一的说明性示例。不应将此图视为限制性的从而将一个或多个实施例限制于具有以这种方式设置的这些特定组件的计算机系统。现转向图1，计算机系统包含处理器100。在不同的实施例中，处理器可包含一个或多个处理器核。在一些多处理器的实施例中，有多个处理器管芯耦合在一起，每个包含一个或多个核每管芯(关于多个管芯上的处理器核的架构没有在图1中示出)。在不同的实施例中，处理器100可以是设计成在任何形式的个人计算机、手持装置、服务器、工作站或其它当前可用的计算装置中使用的任何类型的中央处理单元(CPU)。

在许多实施例中，将处理器耦合到系统存储器102。存储控制器控制对系统存储器102的访问。在一些实施例中，将存储控制器集成到处理器100中。在其它实施例中，存储控制器位于系统中的分立集成电路中。存储控制器未在图1中示出。在不同的实施例中，系统存储器102可由特定类型的动态随机访问存储器(DRAM)组成，例如双倍数据速率(DDR)同步DRAM。在其它实施例中，系统存储器102可由其它存储类型的装置组成。

处理器100还耦合到I/O(输入/输出)复合体(complex)104。在许多实施例中，I/O复合体包含一个或多个集成I/O主控制器。每个I/O主控制器可控制一个或多个的I/O链路(link)(即互联，总线)。每个链路可将I/O复合体耦合到一个或多个I/O装置、外部控制器、编解码器等等。I/O主控制器106就是一个这样的主控制器。在一些实施例中，I/O主控制器106是PCI

主控制器。在其它实施例中，I/O主控制器106可利用备选的协议。在许多实施例中，将分立物理音频编解码器(PAC)芯片108耦合到主控制器110以控制计算机系统内的音频子系统，包含附连到计算机系统的任何音频外设，例如音频外设110、112以及114。

在许多实施例中，图1中描述的计算机系统具有多个虚拟硬件分区。在许多实施例中，虚拟化引擎116帮助管理这些不同的硬件分区。在一些实施例中，将虚拟化引擎116集成到I/O主控制器106中。在其它的实施例中，将虚拟化引擎116往别处集成到I/O复合体104中(未示出)。在还有的其它的实施例中，虚拟化引擎116位于计算机系统中的别处，例如附加的分立集成电路(未示出)。

在某些其它的实施例中，通过在系统存储器或固件中运行的软件(未示出)管理硬件分区，因此不需要虚拟化引擎。

在系统具有多个硬件分区的实施例中，每个分区运行在常驻于系统存储器102中的虚拟机(VM)上。例如，在两个分区的系统中，VM A(118)和VM B(120)可都常驻在系统存储器102内。在此示例中，将系统存储器102的一部分分配给VM A，将系统存储器102的分开的另一部分分配给VM B。存储器的这两部分由其各自的VM单独利用，因此这些部分不在两个VM之间共享。另外，虚拟机管理器(VMM)122也可以常驻在系统存储器中以管理这些分配以及这两个VM。

在许多实施例中，在两个VM中的每一个的存储器空间内运行单独的操作系统(OS)，例如在VM A内运行的OS 124和在VM 126内运行的OS 126。在许多实施例中，两个OS之一，例如OS 124，是能力OS(COS)。能将COS理解为完全功能的标准OS，例如

Windows或Linux。因此，COS是能够独立地管理计算机系统上的所有资源以及提供所有服务给应用程序和更低级别的软件的操作系统。另外，在许多实施例中，另一个OS(这里的OS126)是服务OS(SOS)。在许多实施例中，SOS是限制功能的OS，其具有一个(或多个)非常具体的用途。例如，在一些实施例中SOS可运行因特网语音协议(VoIP)引擎-。这将允许VoIP引擎具有计算机系统的计算时间的很大一部分，而不论COS的状态如何。在其它实施例中，SOS能够是专用于一个或多个特定的功能而不是作为通用操作系统利用的COS。

在许多实施例中，SOS运行也常驻在VM 126内的软件编解码器仿真器128(SCE)。SCE 128是由管理硬件编解码器的SOS运行的软件。

虚拟语音编解码器130(VAC)也存在于系统中。VAC 130能使多个VM之间的音频外设以及音频功能能够共享。这样就最小化或消除了对PAC时间竞争的多个VM之间对单个PAC 108的争夺。具体地说，VAC130虚拟化音频外设，因此试图利用任何的音频外设的每个VM(或在每个VM内运行的每个OS)将得到外设的唯一虚拟复本。附加的VAC 130逻辑在OS之间仲裁以给每个OS某部分时间以利用每个外设。在OS之间仲裁部分时间的一个方法是利用时分多路复用。

在许多实施例中，VAC 130在硬件中实现。在不同的硬件实现中，可将VAC 130集成到I/O主控制器106、虚拟化引擎116或计算机系统的其它地方中(作为另一芯片内的集成逻辑或其本身芯片内的分立逻辑)。在其它实施例中，VAC 130的所有或部分在软件中实现(未示出)。例如，在一些VAC 130软件实现中，VAC 130可在其本身的分开的VM中实现。在还有的其它实施例中，VAC 130的某些部分在硬件中实现而VAC 130的其它部分在软件中实现。

在许多实施例中，VAC 130由一组寄存器(其维护PAC 108中的配置寄存器的组的复本)以及判决引擎(使得与VM B之间能够相互作用)组成。VAC 130仅能由VM B编程。因此，系统上的VM A以及任何其它的VM不可见到VAC 130内部。VAC 130参考图2在下面详细描述。

在许多实施例中，将主音频控制器132集成到I/O主控制器106中。在其它实施例中，音频控制器132是与主控制器分立的和/或集成到计算机系统中的另一芯片。例如，音频控制器132可以是用于基于高清晰度音频的子系统的控制器。

在许多实施例中，系统中可存在两个以上的VM以及两个以上的OS(未在图1中示出具有两个以上的VM的实施例)。

图2描述了虚拟音频编解码器(VAC)的一个实施例。VAC 130示为大的虚线方框。虚拟功能零200(VF0)以及虚拟功能一202(VF1)也示为虚线。在图2中，VF0 200由COS VM A(118)利用，VF1 202由SOS VM B(120)利用。每个虚拟功能(VF)包含音频控制器(图1中的132)的专用于两个OS中的每一个的部分。例如，在许多实施例中，音频控制器共有八个DMA(直接存储器访问)引擎，其中六个专用于在VM A中常驻的COS以及其中两个专用于在VM B中常驻的SOS。专用于两个OS中的每一个的DMA引擎的数量的差异是与每个OS相关的功能的存储访问需求相联系的。如上所述，SOS专用于有限数量的功能而COS是完全功能的OS。因此除音频编解码器之外，COS可能具有其它的编解码器需要管理，例如HDMI编解码器和调制解调器编解码器以及其它编解码器。这些额外的编解码器也需要DMA引擎对存储器的访问权。在一些实施例中，将依据由COS对比由SOS通常传输的数据的相对量在数量上划分DMA引擎。

在许多实施例中，VAC 130内的逻辑包含捕获逻辑(trap logic)210、命令解释器216、VAC寄存器218、VAC直接存储器访问(DMA)引擎222以及切换器226和232。下面详细描述这些逻辑装置。

VF0 200和VF1 202每个都具有音频控制器寄存器的复本和PCI配置寄存器的复本。在一些实施例中，音频控制器位于PCI

链路上。在一些实施例中，将依据由COS对比由SOS通常传输的数据的相对量的在数量上划分DMA引擎。例如，在图2中所示的实施例中，给COS分配了VF0 202中的六个音频控制器DMA引擎，给SOS分配了VF1 204中的两个音频控制器DMA引擎。

称为命令输出环缓冲器204(CORB)以及响应输入环缓冲器206(RIRB)的额外的DMA引擎，也在图2中示出。CORB和RIRB引擎提供COS和SOS存储器空间与系统中存在的物理编解码器的组之间的直接访问。因此，发送到PAC 108以及其它编解码器208的命令是由CORB引擎204物理发送的，从PAC 108以及从其它编解码器208接收的响应是由RIRB引擎206物理接收的。

在许多实施例中，VAC 130具有给COS呈现一组虚拟音频编解码器寄存器的能力。因此，COS试图访问PAC 108时，COS看到寄存器的虚拟复本而不是得到对PAC 108的直接访问。在I/O主控制器(图1中的106)上有逻辑，其捕获对PAC 114的COS请求且提供更简单的VAC 130视图给COS。COS不可见到平台上的PAC 108硬件的内部。

VAC 130具有捕获逻辑210，其探听命令路径214上从COS存储器空间212发送的命令。在正常的系统操作的过程中，COS将发送大量的命令给多个编解码器，例如音频编解码器、HDMI编解码器以及调制解调器编解码器等等。VAC 130只处理特别涉及到PAC 108的命令和响应。通过捕获逻辑210将涉及非音频编解码器的命令和响应传递给CORB DMA引擎204。当COS特别以PAC 108作为目标发送命令时，捕获逻辑210捕获该命令并把它发送给命令解释器216。命令解释器216将看到该命令正在尝试访问PAC 108，而且命令解释器根据该命令是什么将相应地做出响应。

命令解释器216具有一组VAC寄存器218。这组寄存器对于每个将与PAC 108正常联接的OS包含所有相关的PAC 108寄存器的复本。如果来自COS的命令是对PAC 108寄存器的写，则命令解释器216将执行写入相当于那个PAC 108寄存器的COS版本的相应的VAC寄存器。如果发生的该寄存器写将需要PAC 108配置中的修改，则命令解释器216通过经由VAC DMA引擎222发送该命令给SOS存储器空间220来通知SOS。例如，格式化命令或入/出使能(in/outenable)命令将要求对PAC108配置的修改。在许多实施例中，VACDAM引擎222利用指向SOS存储器空间220中传输该COS命令的位置的寄存器(未示出)，该命令通过解释器216传递，它需要SOS干预。

在许多实施例中，如果COS试图修改CORB写指针寄存器(

高清晰度音频规范中的偏移48h)，其将指示需要更新一个或多个PAC 108 CORB条目，命令解释器216将需要发送这个请求给SOS，因此SOS能相应地响应以及当需要时修改PAC 108配置。在许多实施例中，对CORB控制寄存器的写访问(

高清晰度音频规范中的偏移4Ch)也将由命令解释器216监视以确定何时CORB DMA运行位是置位的。

当PAC 108配置要求修改时，一旦SOS发现来自命令解释器216的请求，那么SOS能穿过命令路径224发送目标为PAC 108的特定命令。切换器226接收命令并确定何时发送命令给PAC 108。耦合到切换器226的仲裁器228确定发送到PAC 108的命令的顺序。正如所提到的，具体发送到PAC 108的命令以及发送到其它编解码器的命令通过CORB引擎206发送。在一些实施例中，仲裁器228是一个简单的轮询(round robin)仲裁器。在其它实施例中，利用不同类型的仲裁器。切换器226穿过命令路径224从SOS存储器220接收以PAC 108为目标的命令以及从捕获逻辑210接收以系统内的任何其它编解码器为目标的命令(即捕获逻辑21仅允许非音频编解码器命令直接从COS传递到切换器226)。

如果从COS到PAC 108寄存器有读访问命令，捕获逻辑210同样探听源于COS存储器空间212的读命令。该捕获逻辑发送以PAC为目标的读命令到命令解释器216。命令解释器随后访问VAC寄存器218中的PAC 108寄存器的COS版本且穿过响应路径230发送虚拟响应(即检索到的虚拟寄存器数据)到切换器232。切换器232也接收来自PAC 108的响应。

切换器232使用仲裁器228内的另外的仲裁逻辑在返回的PAC108响应以及返回的命令解释器216虚拟响应之间切换。仲裁器228内的该仲裁逻辑确定操作哪一个响应。另外，仲裁器228也基于从响应接收的寻址信息协助切换器232确定正确的存储器空间目标(COS或SOS)。仲裁器228也可跟踪从SOS和COS、正通过切换器226发送的请求的顺序且能使用请求信息潜在地确定响应路径。PAC 108响应通过RIRB引擎206从PAC108接收。切换器232将从RIRB引擎206接收的响应在响应路径234上路由到COS存储器空间212或在响应路径236上路由到SOS存储器空间220。目的存储器空间取决于接收的响应。将所有非PAC 108响应发送到COS存储器空间212，而根据响应的类型将PAC 108响应路由到COS或SOS存储器空间。

具体地说，对于PAC响应，如果响应来自物理PAC 108，那么将响应路由到SOS存储器空间220。如果响应是从命令解释器216接收的虚拟响应，则将虚拟PAC响应路由到COS存储器空间212。

作为对从COS发起的以PAC 108为目标的某些命令的响应，命令解释器将生成到SOS的中断。在许多实施例中，可将命令解释器216生成的中断穿过中断路径238发送到常驻在SOS VM B中的软件编解码器仿真器(SCE)128。SCE 128随后将发送更新给VF1音频控制器寄存器244以反映寄存器中的中断。在许多实施例中，VF1音频控制器寄存器244位于音频控制器(图1中的132)之内。另外，在许多实施例中，基本输入/输出系统(BIOS)可对中断高级可编程中断控制器(APIC)编程以为上述所生成的中断设定适当的地址映射(未示出APIC)。

VAC 130是可动态编程的，其允许每VM得到定制的能力。例如，第一VM只可看到连接到编解码器的扬声器而第二VM只可看到连接到编解码器的头戴式耳机。为了维持VAC 130的严格控制，只有SOS VM B可对VAC 130编程。VAC 136的编程可通过SOS中运行的功能驱动246完成。在许多实施例中，当音频控制器(图1中的138)安装于PCI

总线接口上时，可利用PCI总线驱动248结合SOS功能驱动246(其都运行在VM B上)以发送信息给(以及接收信息从)VF1音频控制器寄存器244、I/O主控制器(图1中106)中的VF1PCI

配置寄存器250，以及VAC 130每VM可定制的配置(位于SOS存储器空间202中)。在其它实施例中，出于对VAC 130编程的特定目的，可实现单独的智能驱动在VM B上运行(未示出智能驱动)。

使用该相同的驱动功能，COS通过VM A可见VF0音频控制器和主控制器。在许多实施例中，可利用运行于VM A上的通用音频架构(UAA)驱动252结合PCI总线驱动254以发送信息给(以及接收信息从)VF0音频控制器寄存器256和/或VF0PCI

配置寄存器258。然而，COS不可见VAC 130配置。

在一些实施例中，一旦将VM B配置为主VM，VM B和运行其上的SOS可直接访问PAC 108的物理硬件，所有其它VM(和各自的OS)看到一组虚拟的音频编解码器的寄存器的独立复本。在其它实施例中，每个VM能具有其自己的虚拟编解码器的实现，并且底层硬件或软件(例如VMM 122)管理VM之间的仲裁。

图3更详细地描述了CORB/RIRB处理逻辑的一个实施例。为了最好的阐明CORB/RIRB处理逻辑，下面逐步讨论每个可能的请求和响应。在许多实施例中，CORB和RIRB DMA引擎都具有分派的存储器空间以及寄存器用于操作。虚拟化这个存储器空间和这些寄存器，因此COS和SOS都具有它们自己的复本。

当将请求命令从SOS发送到PAC 108时，命令在SOS CORB存储器空间300中发起。在许多实施例中，修改一个或多个SOS CORB寄存器302以提供关于命令的信息。命令到达切换器226，其利用仲裁器228内的仲裁逻辑以确定哪个命令是下一个将发送到CORB引擎204的命令。到切换器226的其它输入是针对源于COS的非音频编解码器命令(这些命令将在下面更详细地描述)的命令路径。在一些实施例中，仲裁器228内的仲裁逻辑利用轮询方案来仲裁下一步发送SOS命令还是COS命令。一旦命令由仲裁逻辑准许发送，则将它发送到CORB引擎204。CORB引擎204接收命令并且也接收来自SOS CORB寄存器302的信息，例如传送参数(例如写指针)。然后，CORB引擎204将命令发送到帧传送(Tx)逻辑304，接着将命令传送到PAC 108。

备选地，当请求命令从COS CORB存储器空间306发送时，利用不同的处理以确定是否发送命令到PAC 108。如果COS发起的命令的目标是非音频编解码器，则让命令通过。否则，如果COS发起的命令以PAC 108为目标，则不将命令发送到PAC 108，而是利用别的处理。COS CORB存储器空间306是更大COS存储器空间(图2中的212)中的某个部分。从COS CORB存储器空间306发送的命令到达判决引擎308，此判决引擎确定命令的目标是否是PAC 108。在许多实施例中，判决引擎位于捕获逻辑(图2中的210)之内。如果命令不以PAC 108为目标，则将命令传递到切换器226。切换器226利用仲裁器228内的仲裁逻辑确定哪个命令是下一个将要发送到CORB引擎204的命令。一旦仲裁逻辑准许该命令发送，则将命令发送到CORB引擎206。CORB引擎206接收命令并且也接收来自COS CORB寄存器326的信息，例如传送参数(例如写指针)。然后，CORB引擎204发送命令到帧传送(Tx)逻辑304，接着将命令传送到PAC108。

如果COS CORB存储器空间306命令以PAC 108为目标，则判决引擎308发送命令到VAC命令解释器216。命令解释器216(其功能在上面已对照图2详细描述)将命令从原本目标为PAC 108的命令修改为目标为VAC的命令，接着发送命令到VAC响应缓冲器310。VAC响应缓冲器310允许命令缓冲的同时等待被准许在切换器312发送。最后切换器312将命令从响应缓冲器310发送到RIRB引擎206。RIRB引擎206接收命令，也接收来自COS RIRB寄存器314的信息，并利用该信息以发送命令到COS RIRB存储器空间316。COSRIRB存储器空间316是更大COS存储器空间(图2中212)的一部分。

当通过帧接收(Rx)逻辑318接收到响应命令时，命令到达多路信号分离器312。在许多实施例中，命令也到达判决引擎320，其确定命令是否是来自PAC 108的响应。如果命令不是来自PAC 108的响应，则不让命令通过多路信号分离器312，在这种情况下，让来自VAC响应缓冲器310的命令通过。如果命令是来自PAC 108的响应，那么判决引擎320允许响应通过多路信号分离器312传递到RIRB引擎206。RIRB引擎206发送响应命令到COS RIRB存储器316(利用COS RIRB寄存器314信息以发现存储器空间内的正确位置)或发送响应命令到SOS RIRB存储器324(利用来自SOS RIRB寄存器322的信息以发现存储器空间内的正确位置)。基于对于响应传输的目的编解码器确定响应命令是发送到COS还是SOS。

正如上面所提到的，对CORB控制寄存器的写访问将由命令解释器216监视以确定何时CORB DMA运行位是置位的。运行位启用CORB DMA引擎206。因为COS软件中的限制，COS软件发送命令到PAC 108(其由SOS截取)的时间和SOS编程PAC以响应该命令的时间之间可能有延迟。在一些实施例中，等待的时间的量可相应地由BIOS预定并编程。在一些实施例中，等待时间可能达到10毫秒。因此，除运行位之外，在许多实施例中，COS VF0和SOS VF1内的DMA引擎将在特定寄存器中具有与其相关的“等待”位。该位将默认设定为“0”(其意味不等待)。作为对COS VF0对该寄存器的写(其将发生在由COS发起的请求期间)的响应，该位将变成“1”，其实现等待。当该位设定为“1”时，对寄存器的任何额外的写将被丢弃。一旦SOS已经服务了该写事件，该位将由SOS复位为“0”。

图4是方法的一个实施例的流程图，该方法通过单个虚拟机限制对物理音频编解码器的直接访问同时为一个或多个其它虚拟机提供到物理音频编解码器的定制虚拟接口。该方法由可包括硬件、软件、或硬件与软件的组合的处理逻辑执行。转向图4，方法开始于处理逻辑捕获来自系统中存在的COS的命令(处理框400)。此命令发送到系统中的音频控制器中的CORB引擎，因此命令目标是系统内存在的编解码器。处理逻辑确定命令的特定目标是PAC还是别的编解码器(处理框402)。如果命令目标是系统内别的编解码器，则处理逻辑让命令通过CORB引擎直接传递到非PAC编解码器(处理框404)。

一些(但不是所有)发送到编解码器的命令想要引出来自那个编解码器的响应。因此，处理逻辑将检查来自非PAC编解码器的响应(处理框406)。如果没有必要响应，则对于该特定的命令方法结束，否则如果从非PAC编解码器确实返回了响应，处理逻辑发送非PAC编解码器响应到COS(处理框408)。

现在回到处理框402，如果命令特定的目标是PAC，处理逻辑解释命令以确定响应需要什么(处理框410)。如果需要，则处理逻辑将修改任何VAC寄存器(处理框412)。如果需要，处理逻辑也将修改SOS存储器空间中的PAC配置(处理框414)。如果需要，通过SOS访问PAC，处理逻辑也将直接修改PAC寄存器(处理框416)。

接着在对PAC和VAC寄存器、SOS存储器空间进行任何必要的修改后(上面已对照图2和3详细讨论了这些步骤)，处理逻辑将建立到COS的虚拟响应(处理框418)。最后，处理逻辑将发送虚拟响应到COS(处理框420)并且方法结束。因此，该方法通过单个虚拟机(使用VAC和SOS本身内的处理逻辑的SOS)限制对PAC的直接访问同时为一个或多个其它的虚拟机(即COS)提供到PAC的定制接口，然而，如上面所讨论的，也能给要求与PAC相互作用的一个或多个额外的COS提供它们自己的定制接口。

另外，在许多实施例中，VAC并行处理许多命令。在并行处理实施例中，一旦处理逻辑在处理框410中解释命令，从412到420的处理框的两个或更多个可以对不同的命令并行操作。此外，在这些并行处理实施例中，不必一定以如图4所示的特定顺序执行处理框412到420。

因此，描述了虚拟化环境中共享音频子系统的方法、装置以及系统的实施例。这些实施例已经参考其特定的示范实施例描述。从本公开受益的人将明白，在不脱离本文中描述的实施例的更广义的实质与范围的前提下，可对这些实施例做各种修改和改变。因此，应将说明书和附图视为具有解释性的而非限制性的含义。

Claims

1.一种装置，包括：

直接访问物理音频编解码器的第一虚拟机；以及

虚拟音频编解码器，由所述第一虚拟机管理，以为一个或多个另外的虚拟机提供到所述物理音频编解码器的定制接口。

2.如权利要求1所述的装置，其中所述虚拟音频编解码器还包括：

维护所述物理音频编解码器的一组配置寄存器的复本的一组虚拟音频编解码器寄存器；以及

促进与所述第一虚拟机相互作用的判决引擎。

3.如权利要求2所述的装置，其中还可操作所述虚拟音频编解码器以捕获从所述一个或多个另外的虚拟机中的至少一个发送到所述物理音频编解码器的一个或多个命令。

4.如权利要求3所述的装置，还包括逻辑，所述逻辑监视命令发出环缓冲器寄存器和响应返回环缓冲器寄存器以检测所述一个或多个另外的虚拟机中的至少一个对所述物理音频编解码器的一个或多个访问。

5.如权利要求3所述的装置，其中所述判决引擎还包括命令解释器，可操作所述命令解释器以将一个或多个所捕获的命令转换成对所述一组虚拟音频编解码器寄存器的一个或多个访问。

6.如权利要求5所述的装置，还包括直接存储器访问逻辑，所述直接存储器访问逻辑将所述一个或多个访问从所述一组虚拟音频编解码器寄存器发送到为所述第一虚拟机保留的系统存储器中的位置。

7.如权利要求6所述的装置，其中所述判决引擎还包括编解码器仿真器以

接收对所述一组虚拟音频编解码器寄存器的所述一个或多个访问；以及

通过响应所接收的访问，管理所述物理音频编解码器的操作。

8.如权利要求2所述的装置，其中所述的判决引擎还包括仲裁器以

解决来自一个或多个所述另外的虚拟机的请求的访问之间的物理音频编解码器操作的冲突；

管理影响所述物理音频编解码器的任何中断；以及

管理来自所述物理音频编解码器的未经请求的响应。

9.如权利要求1所述的装置，其中所述的第一虚拟机还包括服务操作系统，可操作所述服务操作系统以

管理所述物理音频编解码器的配置；以及

管理所述虚拟音频编解码器的配置。

10.如权利要求3所述的装置，其中所述一个或多个另外的虚拟机中的至少一个包含能力操作系统，可操作所述能力操作系统以

给运行在所述能力操作系统上的一个或多个软件应用程序提供对所述虚拟音频编解码器的访问，其中所述访问通过发送到所述物理音频编解码器的且由所述虚拟音频编解码器捕获的一个或多个命令提供。

11.一种方法，包括：

直接访问物理音频编解码器，其中所述访问由第一虚拟机执行；以及

为一个或多个另外的虚拟机提供到所述物理音频编解码器的定制接口。

12.如权利要求11所述的方法，还包括

在一组虚拟配置寄存器中维护所述物理音频编解码器的另一组配置寄存器。

13.如权利要求12所述的方法，还包括

在从所述一个或多个另外的虚拟机中的至少一个发送到所述物理音频编解码器的一个或多个命令到达所述物理音频编解码器之前捕获所述一个或多个命令。

14.如权利要求13所述的方法，还包括

监视命令发出环缓冲器寄存器和命令返回环缓冲器寄存器以检测所述一个或多个另外的虚拟机中的至少一个对所述物理音频编解码器的一个或多个访问。

15.如权利要求14所述的方法，还包括

将一个或多个所捕获的命令转换成对所述一组虚拟音频编解码器寄存器的一个或多个访问；以及

通过响应所转换的命令，管理所述物理音频编解码器的操作。

16.一种系统，包括

第一虚拟机以

直接访问物理音频编解码器；

将资源提供给运行在所述第一虚拟机上的服务操作系统，其中所述服务操作系统管理虚拟音频编解码器；

所述虚拟音频编解码器，为一个或多个另外的虚拟机提供到所述物理音频编解码器的定制接口；以及

所述一个或多个另外的虚拟机，将对所述虚拟音频编解码器的访问提供给一个或多个软件应用程序，所述一个或多个软件应用程序由运行在所述一个或多个另外的虚拟机中的至少一个上的至少一个能力操作系统管理。

17.如权利要求16所述的系统，其中所述虚拟音频编解码器还包括

维护所述物理音频编解码器的另一组配置寄存器的一组虚拟音频编解码器寄存器。

促进与所述第一虚拟机相互作用的判决引擎。

18.如权利要求17所述的系统，其中还可操作所述虚拟音频编解码器以在从所述一个或多个另外的虚拟机中的至少一个发送到所述物理音频编解码器的一个或多个命令到达所述物理音频编解码器之前捕获所述一个或多个命令。

19.如权利要求18所述的系统，还包括逻辑，所述逻辑监视命令发出环缓冲器寄存器和响应返回环缓冲器寄存器以检测所述一个或多个另外的虚拟机中的至少一个对所述物理音频编解码器的一个或多个访问。

20.如权利要求18所述的系统，其中所述判决引擎还包括命令解释器，可操作所述命令解释器以将一个或多个所捕获的命令转换成为对所述一组虚拟音频编解码器寄存器的一个或多个访问。

21.如权利要求20所述的系统，还包括直接存储器访问逻辑，所述直接存储器访问逻辑将所述一个或多个访问从所述一组虚拟音频编解码器寄存器发送到为所述第一虚拟机保留的系统存储器中的位置。

22.如权利要求21所述的系统，其中所述判决引擎还包括编解码器仿真器以

在为所述第一虚拟机保留的系统存储器中的位置中接收对所述一组虚拟音频编解码器寄存器的所述一个或多个访问；以及

23.如权利要求17所述的系统，其中所述判决引擎还包括仲裁器，以

管理影响所述物理音频编解码器的任何中断；以及

管理来自所述物理音频编解码器的未经请求的响应。

24.如权利要求16所述的系统，其中所述第一虚拟机还包括服务操作系统，可操作所述服务操作系统以

管理所述物理音频编解码器的配置；以及

管理所述虚拟音频编解码器的配置。

25.如权利要求24所述的系统，其中所述服务操作系统还可操作，以

管理因特网语音协议(VoIP)引擎，所述VoIP引擎通过所述服务操作系统利用所述物理音频编解码器。