仿真os隔离定序器上的用户级多线程处理的机制的制作方法

文档序号:6553502阅读:188来源:国知局
专利名称:仿真os隔离定序器上的用户级多线程处理的机制的制作方法
技术领域
本公开内容一般涉及信息处理系统,并且更具体地,涉及在其中一个或多个定序器可与操作系统隔离的多定序器系统上的多线程处理。
背景技术
为提高信息处理系统、诸如包括微处理器的那些信息处理系统的性能,采用了硬件和软件技术。在硬件方面,提高微处理器性能的微处理器设计方案包括了更快的时钟速度、流水线技术、分支预测、超标量执行、无序执行和高速缓存。许多此类方案使得晶体管数量增加,并且在一些情况下,甚至导致晶体管数量增加率大于性能提高率。
其他性能增强涉及软件技术,而不是寻求完全通过增加晶体管来提高性能。一种已用于提高处理器性能的软件方案称为“多线程处理”。在软件多线程处理中,指令流可分成可以并行执行的多个指令流。或者,多个独立的软件流可并行执行。
在一个称为时间片多线程处理或时间复用(“TMUX”)多线程处理的方案中,单个处理器在固定时间段后在线程之间切换。在还有的另一方案中,在发生例如长等待时间高速缓存缺失的触发事件时,单个处理器在线程之间切换。在称为基于事件切换的多线程处理(“SoEMT”)的此后一方案中,在给定时间最多只有一个线程是活动的。
在硬件方面,越来越支持多线程处理。例如,在一个方案中,在诸如芯片多处理器(“CMP”)系统(单个芯片封装上多个处理器)和对称多线程处理(“SMP”)系统(多个芯片上多个处理器)等多处理器系统中的处理器各自可并发对多个软件线程之一起作用。在称为同时多线程处理(“SMT”)的另一方案中,单个物理处理器变得对操作系统和用户程序好像是多个逻辑处理器。对于SMT,多个软件线程可以是活动的,并同时在单个处理器上执行而无需切换。也就是说,每个逻辑处理器维护一套完整的架构状态,但共享诸如高速缓存、执行单元、分支预测器、控制逻辑和总线等物理处理器的许多其他资源。对于SMT,来自多个软件线程的指令因而在每个逻辑处理器上并发执行。
对于支持软件线程并发执行的系统,如SMT、SMP和/或CMP系统,操作系统(“OS”)应用可控制软件线程的调度和执行。然而,一般情况下,操作系统控制不能良好地扩展;操作系统应用调度线程而对性能没有负面影响的能力通常只限于较少量的线程。
附图简述可参照下面的附图理解本发明的实施例,其中,类似的要素用类似的标号表示。这些图形无意于限制,而是用于说明在多定序器系统上执行用户级多线程处理的设备、系统和方法的选定实施例,其中,经OS透明的抽象层提供在OS隔离定序器上的用户级纤程(shred)控制。


图1是方框图,示出多定序器系统的一般并行编程方案的图形表示。
图2是方框图,示出在用户级多线程处理的至少一个实施例的线程和纤程之间的共享存储器和状态。
图3是方框图,示出多定序器系统的各个实施例。
图4是方框图,示出多定序器多线程处理系统的软件机制的至少一个实施例。
图5是方框图,示出包括作为虚拟机监视器一部分的纤程处理仿真层的多定序器处理系统。
图6是方框图,示出一个或多个定序器隔离的至少一个实施例。
图7是流程图,示出用于启动包括纤程处理仿真层的软件层的方法的至少一个实施例。
图8是方框图,示出在操作系统和虚拟机监视器启动后的示范多定序器系统的隔离定序器和OS可见定序器的状态。
图9是控制流程图,示出用于定序器重定向的方法的至少一个实施例的方法和控制流。
图10是控制流程图,示出用于纤程创建的方法的至少一个实施例的方法和控制流。
图11是控制流程图,示出由于环过渡原因纤程暂停的至少一个实施例。
图12是控制流程图,示出在处理环过渡后纤程恢复的至少一个实施例。
图13是控制流程图,示出代理执行机制的至少一个实施例。
图14是流程图,示出代理执行方法的至少一个实施例。
图15是方框图,示出能够执行公开技术的系统的至少一个实施例。
详细说明下面的论述描述了允许用户级应用程序在多定序器多线程处理系统中创建和控制与OS无关的执行线程(称为“纤程”)的方法、系统和机制的选定实施例。以完全的操作系统透明度创建、调度和执行用户级纤程。执行公开技术的多定序器系统的硬件不必支持架构纤程控制指令。相反,可通过OS透明的软件或固件仿真层提供此类功能。
可结合单核或多核多线程处理系统来利用本文所述机制。在下面的说明中,陈述了如下的许多特定的细节以更透彻地理解本发明,如处理器类型、多线程处理环境、系统配置、多定序器系统中定序器的数量和拓扑、微架构结构及指令名称和参数。然而,本领域的技术人员将理解,可无需此类特定细节来实现本发明。另外,未详细示出一些熟知的结构、电路及诸如此类以免不必要地混淆本发明。
下述的图1和图2示出包括用户控制的“纤程”的共享存储器多处理范例,这些纤程是在隔离在操作系统视野和控制外的定序器上执行的指令序列。此类OS隔离定序器有时称为“OS不可见”定序器。图3和图15示出可实施此类范例的处理器和/或系统的示范实施例。图4概括示出称为纤程处理仿真层的抽象层的至少一个实施例,该层可在定序器硬件不支持架构纤程处理指令的多定序器系统上提供用户级纤程处理功能。最后,图5-14示出纤程处理仿真层的特定方法和系统实施例。
共享存储器多处理范例可在称为并行编程的方案中使用。根据此方案,应用程序员可将有时称为“应用”或“进程”的软件程序分成要并发运行的多个任务以便表示软件程序的并行性。同一软件程序(“进程”)的所有线程共享共同的存储器逻辑视图。
图1是方框图,示出在多定序器多线程处理系统上的并行编程方案的图形表示。图1示出操作系统140可见的进程100、120。这些进程100、120可以是不同的软件应用程序,如字处理程序和电子邮件管理程序。通常,每个进程在不同的地址空间中操作。
操作系统(“OS”)140一般负责为诸如图1所示进程120等进程管理用户创建的任务。相应地,操作系统140可为与进程120相关联的每个用户定义的任务创建独特的线程125、126,并可将线程125、126映射到线程执行资源。(在图1中未示出线程执行资源,但下面有详细论述。)OS 140一般负责调度这些线程125、126以在执行资源上执行。与单个进程相关联的线程一般具有相同的存储器视图,并共享相同的虚拟地址空间。
由于OS 140负责创建、映射和调度线程,因此,线程125、126是OS 140可见的。另外,本发明的实施例包含OS 140不可见的另外的线程130-136。也说是说,OS 140并不创建、管理或以其他方式确认或控制这些另外的线程130-136。这些非OS 140创建或控制的另外的线程在本文有时称为“纤程”130-136,以便区分它们与OS可见的线程。由用户级程序创建和管理这些纤程,并调度这些纤程以在与操作系统隔离的定序器上运行。OS隔离定序器共享与OS可见定序器相同的环0状态。纤程130-136因而共享为与同一进程126相关联的线程125、126创建的同一执行环境(地址映射)。
术语“线程”和“纤程”在本文中使用时至少包括与进程的其他线程和/或纤程并发执行的指令流独立执行的概念。线程和“纤程”术语均包含该想法,因此,包含软件指令流的执行与相关联的处理器状态。均为指令流的线程(由OS控制)与纤程(操作系统不可见并由用户控制)之间的区分因素在本文中使用时指如何管理线程和纤程指令流的执行的差异。响应对OS的系统调用而生成线程。OS生成该线程并分配资源以运行该线程。为线程分配的此类资源可包括操作系统用于控制和调度线程的数据结构。
与此相反,经用户级软件指令生成纤程的至少一个实施例,该指令调用软件库或其他与OS无关的机制以生成OS不知道的纤程。因此可响应用户级软件库调用而生成纤程。软件库调用可在由软件库维护的纤程工作队列(未示出)中创建条目。此类纤程工作队列可为调度以在OS隔离定序器上运行的每个纤程保存条目。要了解纤程工作队列的至少一个实施例的进一步论述,请参阅题为“在无操作系统干预的情况下在OS隔离定序器上调度线程的机制”(Mechanismto Schedule Threads on OS-Sequestered Sequencers without OperatingSystem Intervention)的同时待审的美国专利申请(代理人案号42390.P20205)。
图2是方框图,以图形形式示出有关上述的声明即同一软件程序或进程的所有线程共享共同的存储器逻辑视图的其他细节。对于本发明的实施例,此声明在与进程100、120相关联的纤程方面同样适用。也说是说,多个纤程130-136可与单个OS管理的线程125相关联。由线程125初始化以运行与该线程125相关联的纤程的所有定序器(定序器1-定序器4)共享由操作系统为该线程构建的同一虚拟存储器视图。
在本文中参照图1论述图2。图2采用图1所示进程120、线程125、126及纤程130-136的图形表示。然而,此类表示不应视为限制。本发明的实施例无需对与进程相关联的线程或纤程的数量强加上限或下限。在下限方面,图1示出,在给定时间运行的每个进程根本无需一定与一些线程或纤程相关联。例如,图1所示的进程0 100示为在图1所示的特殊时间运行,既无线程,也无纤程。
然而,如图1所示,另一进程120可与一个或多个线程125、126相关联。另外,进程120还可另外与一个或多个纤程130-136相关联。进程120的两个线程125、126和四个纤程130-136的表示只是为了说明,不应视为限制。与进程相关联的OS可见线程的数量可受OS程序的限制。然而,对于至少一个实施例,与进程相关联的纤程的累计数量的上限只受在执行期间的特殊时间可用的线程执行资源的数量的限制。图2示出,与进程120相关联的第二线程126可具有和第一线程125不同数量(n)的线程与其相关联。(N对于线程125、126任意之一或两者均可为0。)图2示出,特殊的存储器逻辑视图200由与特殊进程120相关联的所有线程125、126共享。图2示出,每个线程125、126分别具有其自己的应用和系统状态202a、202b。图2示出,线程125、126的应用和系统状态202由与特殊线程相关联的所有纤程(例如,纤程130-136)共享。
相应地,图2示出,本发明至少一个实施例的系统可支持在诸如线程125的OS可见线程和与该线程相关联的(OS不可见)纤程130-136之间的1对多关系。纤程是OS(参见图1中的140)不“可见的”指是应用程序员而不是OS可采用用户级技术创建、同步和以其他方式管理和控制纤程的操作。虽然OS 140知道并管理线程125、126,但OS 140不知道也不管理或控制纤程。
因此,不依赖操作系统管理线程单元硬件与纤程之间的映射,而理想的是可由用户级应用直接控制此类映射,并直接操纵与纤程执行相关联的控制和状态转移。为便于此类直接控制和操纵,线程单元架构的用户可见的特性可包括至少一套规范的指令,这些指令允许用户级应用程序指引线程单元硬件的操纵和控制。
对于至少一个实施例,理想的是可在多纤程处理系统中实施任一或所有以下功能。此类功能各自可由实现功能的单独的架构指令支持。或者,可由更高级别的原语或软件库函数实施这些功能,这些原语或函数基于一小套规范的纤程创建和控制指令。在题为“在多个指令定序器上的基于指令集的线程执行机制”(A Mechanism ForInstructions Set-Based Thread Execution on a Plurality of InstructionSequencers)的同时待审的美国专利申请(代理人案号42390.P19770)中可找到有关规范的架构用户级纤程处理指令硬件实施的进一步论述。
可作为用户级纤程处理编程范例的一部分提供到程序员的功能可包括任一或所有以下功能中的一个或多个功能1.将定序器隔离以免受OS控制2.实现定序器间控制转移的定序器算术3.环过渡检测和用户级异常处理4.OS可见定序器的“代理执行”以支持隔离定序器的特权操作处理下面将更详细地论述这些功能中的每个功能。
理想的是可在从硬件架构上不支持以上所列的用户级纤程处理功能的系统上提供用户级纤程创建和控制功能。相应地,纤程创建、控制和同步指令的功能可改为由抽象层仿真。下面大部分论述和权利要求书谈到的正是此用户级纤程处理仿真。如上所述,此类仿真可在基础线程单元不支持用于用户级纤程创建、映射、控制和同步的架构指令的系统中实施。然而,本文中所述的软件仿真机制的实施例并不限于此类系统。可在一个或多个线程单元不支持架构纤程指令的系统上实现这些实施例。
线程单元在本文也可互换地称为“定序器”,在本文中使用时可以是能够执行线程或纤程的任一物理或逻辑单元。它可包括为给定线程或纤程确定要执行的下一指令的下一指令指针逻辑。例如,图2所示的OS线程125可在未示出的定序器上执行,而每个活动纤程130-136可分别在其他定序器即“SEQ 1”-“SEQ 4”上执行。定序器可以是逻辑线程单元或物理线程单元。图3中示出了逻辑线程单元与物理线程单元之间的此类不同。
图3是方框图,示出能够执行公开技术的多定序器系统的实施例310、350的选定硬件特性。图3示出SMT多定序器多线程处理环境310的选定硬件特性。图3还示出其中每个定序器是单独的物理处理器核的多核多线程处理环境350的选定硬件特性。
在SMT环境310中,单个物理处理器304变得对操作系统和用户程序好像是多个逻辑处理器(未示出),这些逻辑处理器在本文中称为LP1到LPn。每个逻辑处理器LP1到LPn分别维护一套完整的架构状态AS1-ASn。对于至少一个实施例,架构状态包括数据寄存器、段寄存器、控制寄存器、调试寄存器和大多数模型特定的寄存器。逻辑处理器LP1-LPn共享物理处理器304的大部分其他资源,如高速缓存、执行单元、分支预测器、控制逻辑和总线。虽然此类特性可共享,但多线程处理环境310中的每个线程上下文可独立生成下一指令地址(并执行例如从指令高速缓存、执行指令高速缓存或跟踪高速缓存的取出(fetch))。
因此,处理器304包括逻辑上独立的下一指令指针和取出逻辑320,以便即使可在单个物理取出/解码单元322中实施多个逻辑定序器,也可为每个线程上下文取出指令。对于SMT或实施例,术语“定序器”至少包含线程上下文的下一指令指针和取出逻辑320以及该线程上下文的相关联的架构状态AS中的至少一些。应注意的是,SMT系统310的定序器无需对称。例如,同一物理核的两个SMT定序器可在它们各自维护的架构状态信息量方面不同。
因此,对于至少一个实施例,多定序器系统3 10是支持并发多线程处理的单核处理器304。对于此类实施例,每个定序器是具有其自己的指令下一指令指针和取出逻辑320及其自己的架构状态信息AS的逻辑处理器,但同一物理处理器核304执行所有线程指令。对于此类实施例,逻辑处理器维护其自己版本的架构状态,但可在并发执行的线程之间共享单个处理器核的执行资源。
图3还示出多核多线程处理环境350的至少一个实施例。此类环境350包括两个或更多个单独的物理处理器304a-304n,每个处理器能够执行不同的线程/纤程,使得至少部分不同线程/纤程的执行可同时进行。每个处理器304a到304n包括物理上独立的取出单元322,以取出其相应线程或纤程的指令信息。在其中每个处理器304a-304n执行单个线程/纤程的实施例中,取出/解码单元322实施单个下一指令指针和取出逻辑320。然而,在其中每个处理器304a-304n支持多个线程上下文的实施例中,取出/解码单元322为每个支持的线程上下文实施独特的下一指令指针和取出逻辑320。在图3中由虚线表示多处理器环境350中另外的下一指令指针和取出逻辑320的可选本质。
因此,对于图3所示的多核系统350的至少一个实施例,每个定序器可以是处理器核304,多个核304a-304n位于单个芯片封装360中。每个核304a-304n可以是单线程或多线程的处理器核。在图3中用虚线表示芯片封装360,以指示多核系统350的所示单芯片实施例只用于说明。对于其他实施例,多核系统350的处理器核304a-304n可位于不同芯片上。
对于至少一个实施例,以上所列的用户级纤程创建、控制和同步功能并不由如图3中所示的基础定序器硬件的架构指令集来提供。然而,理想的是程序员能够编写调用用户级纤程处理功能的代码。对于此类系统,可经固件或软件抽象层来仿真用户级纤程处理功能,这样,程序员可透明地编写代码,就好像基础硬件支持纤程指令一样。软件或固件层可用于提供抽象层,从而实现在OS隔离定序器上与OS无关的执行纤程的用户级创建、控制和同步。
图4是方框图,示出包括可隔离在操作系统140的视野和控制外的一个或多个定序器的多定序器多线程处理系统400的抽象层402的至少一个实施例。抽象层402提供一种机制来为其中在隔离定序器上不支持用户级纤程处理的架构指令的系统实现用户级线程控制。相应地,对于图4所示的实施例,假设多个定序器432a-432n中的一个或多个定序器并不提供对与OS无关的执行纤程的用户级创建和控制的架构硬件支持,并且假设相同的定序器可隔离在OS的视野和控制外。
图4示出抽象402是逻辑上位于多定序器硬件430顶部的抽象层。操作系统140可至少比抽象层高一层操作,抽象层有时在本文中称为纤程处理仿真层(“SEL”)。
图4示出SEL 420可包括执行各种纤程函数的模块。图4示出SEL 420可包括定序器隔离模块404、代理执行模块406、定序器算术模块408和过渡检测模块410。SEL 420的功能模块404、406、408、410的此类逻辑表示不应视为限制。本领域的技术人员将认识到,这些模块旨在表示执行指定函数的逻辑。逻辑可以是软件、硬件、固件或其任一组合。另外,多个模块404、406、408、410的功能可一起实施为更大的函数或逻辑模块。或者,一个或多个特殊模块的逻辑可再分成更小的子模块。此外,一个或多个模块可与一个或多个其他模块共享逻辑,如共享的函数调用或其他共享的逻辑,而不是包括冗余的逻辑副本。
对于至少一个实施例,SEL 402可以是独立的逻辑模块。对于至少另一实施例,SEL 402可以实施为对现有逻辑模块的修改。例如,SEL 402可实施为对现有软件抽象层的一组修改。下述某些实施例包括作为对虚拟机监视器(“VMM”)的一组修改的SEL 402。同样地,提供此类实施例只是为了在特定实施环境的上下文中更详细地说明SEL 402的选定特性。然而,下面对有关VMM实施例的此类细节的论述不应视为限制。SEL 402可独立实施,或者可实施为在操作系统与定序器硬件之间提供接口的任何其他抽象层的一部分。然而,为阐明可实施为对现有VMM的修改的SEL 402的那些实施例,下面对图5的论述提供有关所示VVM实施例的另外的信息。
图5是方框图,示出包括作为VMM 506的一部分的SEL 402的多定序器处理系统500。系统500包括硬件资源520,而硬件资源包括处理器资源530。处理器资源530可包括多个定序器532a-532n。定序器532a-532n可以是非对称的。
图5所示的说明性系统500还可包括被单独忽略以免混淆本文所述其他特性的其他硬件资源526。此类其他硬件资源526例如可包括但不限于内存、外围装置、芯片组、存储器及诸如此类。
图5示出,除上面刚论述的硬件资源520外,系统500还可包括软件资源。此类软件资源可包括虚拟机监视器506。VMM 506能够以一种允许一个或多个操作系统503a-503n在同一系统500上并发执行的方式对处理系统500的硬件资源进行分区和管理。每个OS503a-503n可在称为分区或虚拟机(VM)510a-510n的基本上独立的软件环境内操作。对于图5所示的示范实施例,VMM 506支持多个虚拟机510a-510n,每个虚拟机分别运行其自己独立的客户OS503a-503n。本领域的技术人员将认识到,本文中所述的实施例可在支持单个VM 510的系统中采用。在图5中用虚线表示另外的VM 510以指示它们是可选的。
对于至少一个实施例,通过诸如微内核512和服务OS 513等软件或固件组件的执行来实施VMM 506。微内核512可包括用于诸如指令调度等系统管理任务的少量指令。服务OS 513可包括用于创建和维护虚拟机的装置驱动程序和环境虚拟化软件。
相应地,对于图5所示系统500的至少一个实施例,VMM软件506可保持对硬件资源520的控制,并可在非特权模式运行客户OS503a-503n作为VMM 506的客户。某些客户事件、指令和情况可陷入VMM 506,并且VMM 506然后可处理此类事件、指令和/或情况。VMM 506因此为客户OS软件503a-503n提供处理器抽象。
在本文中使用时,从客户OS 503a-503n到VMM 506的陷阱(trap)在本文中称为VMEXIT。从VMM 506控制回到客户OS 503a-503n的过渡在本文中称为VMENTER。VMM 506与客户OS软件503a-503n之间的过渡可由称为虚拟机控制结构(VMCS)560的硬件结构控制。VMCS 560可在进入和离开VMM 506控制的此类过渡发生时存储客户(如503a-503n)状态、VMM 506状态和各种控制寄存器的状态。控制寄存器值可指示哪些客户事件应陷入VMM 506并且指示在VMEXIT和VMENTER过渡时载入和存储什么状态。
对于至少一个实施例,VMM 506为VMEXIT和VMENTER过渡执行以下处理。对于VMEXIT,将生成过渡事件的客户OS 503的状态信息存储到VMCS 560的客户状态区。对于VMENTER,从VMCS560的客户状态区还原客户状态。对于至少一个实施例,VMM 506可利用在本文中分别称为VMREAD和VMWRITE的专用读和写指令来读写VMCS 560的字段。
VMCS 560和VMM 506的基本功能可用于将SEL 402实施为VMM 506的一部分的系统的至少一个实施例。下面陈述了VMM 506可如何用于仿真特定的用户级纤程创建、控制和同步功能的特定示例。
定序器隔离。术语定序器隔离在本文中使用时,用于表示多定序器多线程处理系统的一个或多个定序器已过渡到隔离状态或状况。此类隔离状态或状况的特征在于OS不为此类状态或状况中的定序器调度指令。相应地,对于在给定时间具有在隔离状态的一个或多个定序器的系统,我们说只有非隔离定序器才是OS“可见的”。在任一给定时间,视一个或多个定序器是否被隔离而定,OS可看到比平台上确实可用的更少的定序器。只有“可见的”非隔离定序器才可用于OS控制的线程执行。可响应用户级指令在隔离(即,“OS不可见”)定序器上执行纤程。
图6是方框图,示出定序器隔离的至少一个实施例。应注意的是,隔离定序器可以但不必是彼此对称或与OS可见定序器对称。对于至少一个实施例,可在诸如虚拟机中的客户OS等操作系统603的引导期间实现一个或多个定序器622、624、626的隔离。对于此类实施例,OS 603的引导参数650可位于存储器中,如在文件(例如,boot.ini)中。可在引导前配置引导参数650,使得只有系统600的全部定序器的子集(例如,定序器620)是OS 603可见的。(对于至少一个实施例,引导参数可由具有重新配置操作系统设置的根特权的系统管理员配置。)对于至少一个实施例,可在OS 603已完成其引导进程后启动VMM 506。
或者,可为其中在OS 603之前启动VMM 506的实施例实现一个或多个定序器622、624、626的隔离。例如,此类实施例可经BIOS(基本输入/输出系统)或EFI(可扩展固件接口)或充当硬件与操作系统603之间接口的其他固件启动VMM 506。可在切换到OS 603之前由此类固件启动VMM 506。可通过由操作系统603利用的ACPI(高级配置和电源接口)表中的值来控制向OS 603暴露的定序器数量,而不是利用OS的引导参数文件实现隔离。(同样地,ACPI可由系统管理员或由引导管理器(BIOS、EFI等)的供应商编程。)虽然图6中只示出一个OS可见定序器620,但此类图示只是为了说明,而不应视为限制。系统600的任意数量的定序器可以是操作系统603可见的。操作系统603有效处理大量并发线程的能力限制可告知有关系统600中全部定序器中多少定序器应是OS 603可见的与多少定序器应是隔离的判定。
图6示出VMM 506可控制系统600的所有定序器620、622、624、626,包括OS 603可见的定序器620。隔离定序器622、624、626虽然是操作系统603不可见的,但在VMM 506的直接控制下操作。VMM506可为可见定序器620在客户模式运行OS 603。
定序器隔离模块404可执行初始化隔离定序器622、624、626的处理,以让它们准备执行如用户级指令指引的线程。在VMM启动后,定序器隔离模块404可发送初始化指令到每个隔离定序器622、624、626。
由于它们是OS 603不可见的,因此,隔离定序器不执行要求操作系统603的特权环服务的特权代码。对于至少一个实施例,可通过下面更详细论述的透明代理机制向程序员屏蔽特殊定序器无法执行特权指令(如系统调用和缺页故障处理)。
图7是流程图,示出用于启动包括如图4所示SEL 402等纤程处理仿真层的软件层的方法700的至少一个实施例。对于至少一个实施例,SEL 402可作为诸如VMM等更综合的软件模块的一部分启动。可由OS可见定序器上的启动驱动程序来启动方法700。
图7示出方法700从块702开始,并继续到块704。在块704,将软件层的图像载入系统的存储器中。对于至少一个实施例,图像可由启动驱动程序载入。处理随后继续到块706。在块706,调用软件层。结果是控制从启动驱动程序转移到在块704载入的SEL图像。
图7示出,响应在块706的调用,SEL可执行某些处理724-732。当然,将理解,处理724-732无需一定按所示顺序执行,并且一些块可组合在一起作为更大的宏块执行,或者可分解成更小的子块。
对于至少一个实施例,图7所示的处理724-732可由诸如VMM等已修改为包括SEL 420的软件层执行。图7示出在块724,方法700执行初始化。初始化724可包括VMXON指令的执行,这会启用定序器中可用的VMX(虚拟机扩展)特性。初始化724还可包括设置VMM要执行时所在的单独虚拟地址空间。从块724,处理继续到块726。
在块726,方法700控制与OS隔离的定序器。对于至少一个实施例,经将启动处理器间中断(或SIPI)发送到每个隔离定序器而断定此类控制。处理随后从块726继续到728。
在块728,将每个隔离定序器置于等待状态以等待来自调度程序的工作。在此之后,可由纤程调度程序(未示出)在隔离定序器上调度工作。纤程调度程序例如可作为运行库(未示出)的一部分操作。或者,纤程调度程序可作为SEL(参见图4的420)的一部分操作。在题为“在无操作系统干预的情况下在OS隔离定序器上调度线程的机制”(Mechanism to Schedule Threads on OS-SequesteredSequencers without Operating System Intervention)的同时待审的美国专利申请(代理人案号42390.P20205)中,可找到有关纤程调度程序的至少一个实施例的另外的细节。
从块728,处理可继续到块730。在块730,方法700为OS可见定序器设置虚拟存储器控制结构(VMCS)。可操纵在块730设置的VMCS值以每次在OS可见定序器上发生异常时造成到VMM的陷阱。处理随后可继续到块732。
在块732,方法700可执行VMENTER以将控制返回给最初启动SEL的驱动程序(参见块706)。对于OS可见定序器,转移732有效地将控制转给OS。对于至少一个实施例,在启动时执行此第一VMENTER后,对于OS可见定序器,操作系统可作为VMM顶部的客户以非特权模式(下述的“0D”)运行。在块708,客户OS随后可继续执行正常处理。方法700的处理随后可在块710结束。
本领域的技术人员将认识到,可以用维持本文中所述一般功能的多种替代顺序执行图7的块。例如,在块726后,可在执行块728前执行块730和732。
图8是方框图,示出在VMM 806和OS 803启动后的示范多定序器系统800的隔离定序器S1和OS可见定序器S0的状态。图8所示的示例包括两个定序器S0和S1。对于至少一个实施例,每个定序器S0、S1是SMT多线程处理器800的逻辑处理器。对于至少一个替代实施例,定序器S0、S1可以是能够为多核多线程处理系统800并发执行线程的独立处理器核。对于本文中所述的所有实施例,还可在包括比图中所示更多或更少定序器的系统上执行公开的技术。
图8示出第一定序器S0是OS 803可见的,并可在OS 803的指引和控制下执行线程。OS 803调度要由定序器S0执行的工作。然而,由于OS 803作为VMM 806的客户操作,因此,VMM 806控制两个定序器S0、S1。也就是说,对于至少一个实施例,VMM 806控制所有定序器S0、S1,并且将OS可见定序器S0虚拟化到OS 803。当定序器S0尝试执行特权操作时,例如如果在OS 803上运行的应用806尝试访问控制寄存器,则VMM 808可操纵向OS 803暴露的控制值。
在OS 803的顶部运行的应用808在OS 803的环3上以非特权模式运行。此类应用808的非特权环3操作模式在图8中由名称“3D”表示。客户OS 803的内核和驱动程序812在操作系统803的环0中运行,但为非特权模式。操作系统803的非特权环0操作模式在图8中由名称“0D”表示。
图8示出与OS 803隔离的定序器S1在VMM 806控制下操作。图8还示出VMM 806以特权环0模式P0操作。如果尝试由OS可见定序器S0执行某些特权操作,则这些特权操作可能导致到VMM806的VMEXIT。下面结合图9-图13更详细地描述了此类VMEXIT处理的SEL 802处理的进一步说明。
定序器算术。术语定序器算术在本文中使用时用于表示在两个隔离定序器之间的用户级控制转移。对于SEL(参见图4的402)的至少一个实施例,提供了同步和异步的定序器间控制转移功能。当然,对于替代实施例,可分别提供仅同步或仅异步定序器间控制转移功能。可由SEL提供同步和/或异步用户级定序器间控制转移功能,而不论基础定序器硬件是否提供对此类功能的架构支持。
通常,SEL的同步控制转移特性可由用户级指令调用,该指令在由第一定序器执行时使信号发送到第二定序器。对于至少一个实施例,在本文中称为VMCALL的新用户级指令可由程序员用于调用SEL的定序器算术功能。VMCALL指令的参数可由用户级应用操纵以便实现各种类型的定序器间控制转移方案。
(下面表1中陈述了此类定序器间控制转移方案的说明性采样。)利用新VMCALL指令的用户级应用在本文中称为“纤程感知的”应用。
新VMCALL指令的至少一个实施例允许纤程感知的客户软件强制从客户软件到VMM的VMEXIT。VMM随后管理到隔离定序器的信令。表1陈述了可由用户级应用对VMCALL指令的使用启动且可由VMM处理的信令方案的各种示范实施例。由于VMCALL造成退出客户软件控制,因此,表1中所列的方案在本文中称为“出口方案”。对于其他实施例,可实施另外的或不同的出口方案。
表1-从OS可见定序器转移到隔离定序器的同步定序器间控制转移的出口方案


因此,定序器算术的同步定序器间控制转移特性,在本文中称为纤程转移(SXFR)功能,提供一种机制来为定序器之间的服务执行纤程间信令。SXFR功能是同步的,表现在应用程序员可通过明智地将调用SXFR功能的指令放置到纤程感知的代码中而相对于生成信号的定序器的纤程指令流中其他指令的执行来控制该控制转移的执行的定时。生成用于SXFR功能的信号的定序器在本文中使用时称为伺服定序器,而所生成信号的接收方在本文中称为客户端定序器。
可通过新VMCALL指令的变体由用户级应用调用SXFR功能。在处理VMCALL指令时,VMM可处理新用户级指令,这样,它们使隔离定序器接受异步控制转移。VMM可由于用户生成的VMCALL指令而生成发送到隔离定序器的控制消息。此类控制消息可使伺服定序器以异步方式接受如VMM指引的控制。此类异步入口事件使纤程处理输入事件,类似于中断处理。相应地,在接收入口信号时,伺服定序器无需是闲置的。在隔离定序器接收入口方案信号时,如果当前在该隔离定序器上执行纤程,则VMM可将该纤程的执行重定向到新指令指针地址(EIP)。如上所述,此类处理类似于将用户级中断输送到在执行纤程以便将纤程上的执行重定向到新EIP。
由于这些信号使纤程开始在VMM控制下执行,因此,在表2中所列的方案在本文中称为“入口方案”。对于其他实施例,可实施另外的或不同的入口方案。
表2-从OS可见定序器转移到隔离定序器的异步定序器间控制转移的入口方案

VMM因此提供接口以实施表1和表2中所列的出口和入口方案,从而启动和停止在OS可见和OS隔离定序器之间的纤程执行。现在参照图9和图10,方法900、1000的示范实施例利用VMCALL指令,使得VMM有利于定序器间信令从OS可见定序器上运行的纤程感知的程序到隔离定序器。图9示出处理指引定序器在新地址继续执行的VMCALL指令的变体的方法900的至少一个实施例。图10示出处理执行Fork操作的VMCALL指令的变体的方法1000的至少一个实施例。
图9是控制流程图,示出执行VMCALL指令的变体以实施经SEL950到隔离定序器的信令的方法900和控制流的至少一个实施例。此类变体例如可用于以前已暂停并且现在应在与其下一指令不同的EIP恢复的纤程。对于此类使用,信令变体可概念化为下面结合图12所述的恢复机制的变体。变体还可用于定序器之间的任何其他信令。因此,图9所示的信令变体可用作实施表1中所列的一个或多个出口方案的基本机制。图9所示的方法900可由SEL的定序器算术模块(参见例如图4所示的SEL 402的定序器算术模块408)执行。
图9示出,方法900可将隔离定序器n的执行从一个指令指针地址(a)重定向到另一地址(j)。对于至少一个实施例,可由SEL 950(无论体现为VMM的一部分还是其他情况)执行方法900的操作。对于至少一个实施例,可由SEL 950的定序器算术模块(参见图4的408)执行方法900。
图9示出,在OS可见定序器m执行902 VMCALL指令时,可触发执行VMCALL指令的方法900,参数设为指示VMCALL指令是实施SXFR功能的指令。具体地说,图9示出,VMCALL指令指示一种类型的同步控制转移指令“Redirect”,该指令是重定向在单独的隔离定序器n上的纤程以在新EIP恢复执行。
图9示出,VMCALL指令在定序器n上的执行902生成VMEXIT,这造成从在定序器m上运行的客户OS(未示出)到SEL 950的陷阱。响应于此类陷阱,SEL 950在块910开始方法900的执行,并且处理继续到块912。
对于SEL 950可能并不立即将异步中断事件输送到隔离定序器的实施例,执行块912。当然,对于其他实施例,可立即输送异步中断,从块918开始,而不执行块912、914或916。对于图9所示的实施例,SEL 950在块912记录重定向信号即将输送到指定定序器n的情况。处理随后继续到块914。
在块914,SEL 950等待发生从环0到环3的过渡。响应于此类过渡,处理继续到块916。在块916,SEL 950确定以前已在块912记录了纤程事件。相应地,处理继续到块918以处理事件。
在块918,SEL 950将定序器n上暂停的纤程本应恢复执行的EIP(在图9中示为指令a的地址)推到与纤程相关联的栈上。这样,当前EIP被保存以用于以后恢复纤程的当前指令流。处理随后继续到块920。
在块920,SEL 920操纵纤程栈以在功能上仿真“call”指令,使定序器n上的纤程在指令j开始执行。VMM 950因此使定序器n上的纤程在新EIP即j恢复。方法900的处理随后继续到块921。在块921,SEL 920将控制返回给OS可见定序器m。处理随后在块922结束。
图9示出,在新EIP即j开始执行的纤程可视为信号服务例程970。信号服务例程970可以用返回指令972结束。由定序器n执行返回指令972可导致在定序器n上在EIP即a恢复以前在EIP即a中断的处理。对于各种实施例,可通过各种机制实现此类动作。例如,对于至少一个实施例,可响应于返回指令972而执行以下动作在返回指令972执行时,定序器n可将SEL 950在块918推到栈上的EIP值从栈弹出。定序器n随后可在EIP即a恢复以前在EIP即a中断的处理。
或者,可采用其他机制在EIP即a恢复以前在EIP即a中断的定序器n的处理。对于至少一个替代实施例,不涉及栈弹出。相反,可利用另一调用约定。例如,一个此类替代的调用约定是利用寄存器而不是栈的转移链接(branch-and-link)样式的返回机制。
图10是控制流程图,示出可由SEL 1050提供的定序器算术功能的另一实施例。图10示出实施Fork出口方案的VMCALL指令的执行。VMM处理VMCALL指令的此特殊变体以允许OS可见定序器发送(启动新纤程的)信号到隔离定序器。同样地,可由SEL的定序器算术模块(参见例如图4所示的SEL 402的定序器算术模块408)执行图10所示的方法1000。
图10示出,VMM可指引新线程的执行以在与隔离定序器相关联的新指令指针地址开始执行。虽然图10示出由纤程感知的纤程生成Fork指令的实施例,但此类示例不应视为限制。本发明的实施例考虑了可由一个隔离定序器执行Fork指令以在另一隔离定序器上产生纤程。
图10示出,除图9所示重定向外,或代替该重定向,SEL 1050可利用定序器间信令执行Fork操作,使得在OS可见定序器x上的用户生成的指令可促使在隔离定序器y上产生纤程。如上面的表1所示,应用程序员可将用于Fork出口方案的VMCALL指令置于在OS可见定序器x上运行的纤程感知的应用中。
当在OS可见定序器x上操作的纤程感知的程序执行VMCALL指令的“Fork”变体(图10中示为在EIP“t”的指令)时,在指令中指定的“Fork”出口方案促使控制转移给SEL 1050。在图10的1002表示Fork指令的执行。图10示出VMCALL指令的Fork变体的至少一个实施例指示产生的线程应开始执行的EIP(“u”)和表示保留用于新纤程的栈空间的指示符(“stack”)。作为可选参数,应用程序员可指定要在其上执行新纤程的隔离定序器y。或者,应用程序员可将此类分配功能留给SEL 1050。SEL 1050例如可根据循环分配策略为新纤程分配隔离定序器。
由于OS可见定序器(x)执行VMCALL指令的Fork变体而引起的控制转移在图10中称为VMEXIT。响应于VMEXIT,SEL 1050开始执行方法1000以执行Fork操作。
图10示出,方法1000从块1010开始,并继续到块1012。在块1012,SEL 1050为纤程分配隔离定序器y,并为指配的定序器y生成执行1002环境。对于至少一个实施例,通过以下方式在块1012生成执行环境。应理解的是,下面提供的示例只是用于说明的、利用WINDOWS操作系统的特性的一个示范实施例。然而,其他实施例可为利用其他或另外的结构的新纤程生成执行环境。
来自用于定序器x的VMCS 1080的客户状态区包括已由操作系统设置以在定序器x上执行纤程感知的应用的状态的快照。此类客户状态可包括诸如CR3等控制寄存器的值及全局描述符表寄存器(“GDTR”)和段寄存器的值。在块1012,如VMCS 1080中反映的定序器x的客户状态由SEL 1050复制,以在与SEL 1050为执行如VMCALL Fork指令中识别的新纤程而已分配的隔离定序器y相关联的VMCS 1082中设置状态。
SEL 1050因而使用产生定序器x的客户状态来填充要执行新纤程的定序器y的客户状态。相应地,在块1012,SEL 1050可实现为隔离定序器y创建执行环境的目标,该执行环境类似于操作系统为纤程感知的应用在定序器x上的执行而设置的执行环境。
SEL 1050随后可利用(仍在块1012)VMCALL Fork指令的参数来修改在用于隔离定序器y的VMCS 1082中的隔离定序器状态。在块1012,可在VMCS 1082中修改隔离定序器y的客户EIP,以反映在VMCALL Fork指令中指定的EIP即u。类似地,在块1012,SEL1050还可修改VMCS 1082中的客户栈指针,以反映在VMCALL Fork指令中指定的栈指针值“stack”。在块1012,SEL 1050还可修改用于隔离定序器y的VMCS 1082中的标记,以指示在纤程执行期间要阻止所有可屏蔽中断。
除这些修改的值(如EIP、栈指针和中断标记)外,用于OS可见的纤程感知的定序器x的VMCS 1080中的客户状态与已在块1012为隔离定序器y生成的客户状态(如VMCS 1082中反映的)相同。处理随后继续到块1014。
在块1014,SEL 1050记录纤程将在其上下文中执行的线程。对于至少一个基于WINDOWS的实施例,SEL 1050利用OS指配的线程id执行此操作。由于对于至少一个实施例,OS可见定序器(如x)生成的所有纤程要与OS可见定序器共享虚拟存储器视图,因此,在块1014记录OS可见定序器的线程id值,以识别隔离定序器(如y)的新纤程要在其上下文中执行的进程。处理随后继续到块1016。
在块1016,SEL 1050允许OS可见定序器x的客户OS恢复在OS可见定序器x上的纤程感知的应用的执行。对于至少一个实施例,这通过执行将控制转移回给OS可见定序器x的客户OS的VMRESUME指令而实现。此外,SEL 1050执行VMENTER操作,以在块1012创建的执行环境中开始在隔离定序器y上的纤程代码的执行。处理随后在块1018结束。
在执行VMENTER时,隔离定序器(y)的存储器视图与定序器x的存储器视图相同,这是因为这两个定序器与相同的、在其相应的VMCS 1080、1082中的用于客户模式执行的GDT和CR3寄存器值相关联。本领域的技术人员将认识到,GDT和CR3寄存器值影响在相应定序器x、y执行期间将虚拟地址转换成物理地址的方式。
图10示出,通过执行方法1000,SEL 1050有效地实施类似于上面表2中所示的go_shred入口方案的异步入口方案。可响应于在纤程感知的应用中的用户提供的VMCALL Fork指令而执行隔离定序器x的入口方案。图10示出,在执行方法1000的其他块1010-1014后,SEL 1050在块1016开始纤程代码的执行,并且为隔离定序器y设置的执行环境实际上与操作系统为OS控制的定序器x设置的执行环境相同。这样,由SEL 1050执行方法1000有效地为Fork操作实现了上面结合图1和图2所述的共享存储器并行多处理范例。
图9和图10的提供用于示出软件仿真层的至少一个实施例的定序器算术功能特定说明性示例。此类示例不应视为限制;SEL 1050可提供许多其他定序器算术功能。
用户级异常处理。对于本文中所述的机制的至少一个实施例,当在OS可见定序器或隔离定序器上的纤程执行期间发生环过渡时,应暂停在隔离定序器上的用户级纤程指令的执行。经常响应于在OS可见定序器或隔离定序器上生成的异常、中断或系统调用而生成环过渡。对于在OS可见定序器上的环过渡,在OS已处理中断/异常/系统调用后,并且OS随后为继续执行而调度纤程感知的应用时,可恢复暂停的纤程的执行。对于至少一个实施例,下面结合图10和图11所述的纤程暂停和恢复方法可由过渡检测模块(参见如图4所示的SEL 402的过渡检测模块410)执行。
图11是控制流程图,示出用于由于环过渡而纤程暂停的一种机制的至少一个实施例。在特殊示例的上下文中描述图11所示的机制-当在OS可见定序器c上发生环3到环0过渡时,暂停隔离定序器d上的纤程执行。当然,本领域的技术人员将认识到,当在OS隔离定序器上发生环3到环0过渡时也可采用类似的暂停逻辑(参阅下面的代理机制论述)。
对于图11所示的暂停机制的至少一个实施例,示出了三个操作阶段。在第一阶段1110,执行初始化。此类初始化1110可由SEL 1150执行。对于至少一个实施例,执行初始化1110以便规定由于异常引起的环3到环0过渡将记录为异常,并将因此引起VMEXIT。在此类初始化1110期间,配置控制结构,使得只要在OS可见定序器c上的线程执行期间发生由于环3到环0过渡引起的异常,便将发生到SEL 1150控制的过渡。
对于至少一个实施例,可通过在用于OS可见定序器c的VMCS1180中的异常位图中设置用于所需系统事件(由于定序器c上的异常引起的环3到环0过渡)的异常位,执行初始化1110。虽然图11中只示出一个OS可见定序器c及其相关联的VMCS 1180,但应理解,可为多个OS可见定序器执行初始化1110。
对于其中SEL 1150是VMM的一部分的实施例,初始化1110实现了一种机制,该机制使用VMCS 1180的异常位图以当在定序器c上发生由于异常引起的环过渡时引发VMEXIT(控制转移到VMM)。
当然,还可在OS可见定序器c的纤程处理期间发生诸如中断或系统调用等其他类型的系统事件。初始化1110还规定在发生需要在OS可见定序器c上的OS处理的中断或系统调用或其他系统事件时引发VMEXIT。对于至少一个实施例,可经蹦床机制实施用于中断、系统调用及诸如此类的初始化1110。蹦床机制在第一次从客户OS“弹起”时暂时地进行控制,以在将控制“弹”回客户OS前执行某些纤程暂停动作。
对于用于中断的蹦床机制的一个实施例,SEL 1150可配置该机制用于中断的主机控制,使得只要当客户OS在运行时发生中断,SEL1150便进行控制。对于至少一个实施例,SEL 1150可在初始化1110期间调用特殊的驱动程序。该驱动程序可修改由OS可见定序器的客户OS利用的某些设置以处理中断和系统调用。
在未失去一般性的情况下,提供了配置蹦床机制的特定示例。然而,该示例不应视为任一方面的限制,这是因为可以用若干不同方式中的任一方式实现此类配置。对于至少一个示范实施例,驱动程序可在初始化1110期间修改中断描述符表(IDT)。此类修改可修正与一个或多个中断服务例程(ISR)相关联的IDT中的偏移,而这些例程与系统调用和中断相关联。修正的偏移可促使在执行与中断或系统调用相关联的ISR前生成VMCALL。当在OS可见定序器c上发生中断或系统调用时,在初始化1110期间对IDT进行的修改因此可使控制“弹”给SEL 1150。正如下面更详细论述的,SEL 1150可在将控制“弹”回给定序器c的ISR前采取某些纤程暂停动作。
可在块1110以类似的方式为系统调用初始化蹦床机制。在块1110,SEL 1150可执行初始化,使得SEL 1150可检测系统调用的发生。对于至少一个实施例,可通过禁用一般绕过SEL 1150的快速系统调用或其他类型的系统调用而实现此初始化。对于此类实施例,禁用快速系统调用可使OS可见定序器的客户OS将中断指令(如,INT)用于系统调用。当然,对于其中SEL 1150可捕获快速系统调用的实施例,无需一定要禁用快速系统调用,并且可执行(在下一段中提到的)IDT的修改以确保快速系统调用陷入SEL 1150。
还在块1110执行初始化,使得由OS可见定序器c的客户OS进行的中断指令(或其他系统调用,如快速系统调用)的执行可以用如上就中断所述的类似方式(即,IDT的修改)将控制“弹”给SEL1150。换而言之,此类初始化1110使系统调用陷入SEL 1150。
最后,在块1110的初始化还可包括诸如定序器d等OS隔离定序器的初始化,使得只要它们收到非可屏幕中断(NMI),它们便将陷入SEL 1150(参阅下面结合块1104的进一步论述)。可通过修正与隔离定序器d相关联的VMCS 1182的异常位图而执行此类初始化,以指示在收到NMI时应发生到SEL 1150控制的过渡。
图11示出,可由OS可见定序器c执行第二阶段1120。当在OS可见定序器c上的线程执行期间,定序器可由于环3到环0过渡而生成异常,或者可遇到系统调用、中断或需要OS服务的其他系统事件。由于上述初始化1110的原因,此类事件的发生可引起到SEL 1150控制的、VMEXIT类型的过渡,而不是允许定序器c的客户OS立即处理事件。对于其中SEL 1250是VMM的一部分的实施例,在第二阶段1120期间生成的过渡1101可称为VMEXIT。
图11示出,在发生VMEXIT类型的过渡时,将控制转移给SEL1150。在第三阶段1130期间,SEL 1150执行用于纤程暂停的方法1100。对于其中将SEL 1150逻辑包含到VMM中的实施例,可由VMM执行方法1100。
图11示出,响应于在OS可见定序器c上由系统事件触发的VMEXIT 1101,在允许客户OS在OS可见定序器c上处理事件前,SEL 1150执行方法1100。可至少出于以下原因而采用此类机制客户OS不知道隔离的纤程,并且这些纤程因此在客户OS的任一内核模式代码在OS可见定序器上执行时不应继续执行。
图11示出,方法1100从块1102开始,并继续到块1104。在块1104,SEL 1150发送中断到一个或多个OS隔离定序器d,这些定序器在运行与OS可见定序器c执行的纤程感知的代码相关联的代码。图11只示出一个此类隔离定序器d。然而,本领域的技术人员将认识到,可在块1104向多个隔离定序器发出中断。对于至少一个实施例,在块1104发出的中断是接收定序器无法忽略的非可屏蔽中断。SEL 1150可例如通过对高级可编程中断控制器(APIC)进行编程,使得在块1104发出中断。
通过使得在块1104发送中断,SEL 1150有效地触发在隔离定序器d上的纤程执行的异步暂停,并因此仿真“Suspend”纤程控制指令。在块1104的中断触发因而实现了隔离定序器d的halt_shred入口方案,该halt_shred入口方案类似于表2所示的halt_shred入口方案。SEL1150基于在块1104发出的中断在块1106等待从隔离定序器d的控制过渡。
图11示出,在块1104生成的中断可由OS不可见定序器d接收,并且又可引起隔离定序器d的到SEL 1150控制的过渡1105。同样地,对于其中将SEL 1150逻辑包含在VMM中的实施例,此类过渡1105可称为VMEXIT。(如果在块1104向不止一个隔离定序器发出中断,则多个定序器中的每个定序器将生成VMEXIT,并且对于多个隔离定序器中的每个定序器,可执行后面的块1108和1110。)响应于来自OS隔离定序器d的、由在块1104发出的中断引起的VMEXIT 1105,SEL 1150在块1106检测过渡,并继续执行块1108。在块1108,SEL 1150执行处理以准备在由OS可见定序器c的客户OS的事件处理程序例程已处理系统事件后恢复纤程。为此,SEL 1150的至少一个实施例利用代码断点。
相应地,在块1108,SEL 1150可在一个或多个调试寄存器(DR)中设置代码断点,以便在最初触发系统事件的指令的EIP指令地址t设置OS可见定序器c的代码断点。假设在OS可见定序器c的客户OS已处理系统事件后,它将开始在EIP t的纤程感知的线程的执行,并且因此将在已处理系统事件后触发断点。(下面结合图12和纤程恢复机制的论述,陈述了断点处理的进一步论述。)对于至少一个实施例,断点机制允许SEL 1150以对OS可见定序器c的客户OS透明的方式跟踪OS可见定序器上的环过渡,表现在断点是客户OS不可见的。
处理随后从块1108继续到块1110。在块1110,SEL 1150将与在定序器c上生成事件的纤程感知的线程相关联的每个隔离定序器d置于等待状态。处理随后继续到块1112。
在块1112,SEL 1150将控制交还给OS可见定序器c的客户OS,以便客户OS可处理事件。处理随后在块1114结束。
图12是控制流程图,示出用于在环过渡后恢复纤程执行的机制的至少一个实施例的控制流和方法1200。图12示出继续上面结合图11所述的示范方案的示范方案。
图12示出,OS可见定序器c已完成其事件处理序列,并已返回到最初生成事件的纤程感知的线程指令流的执行。也就是说,图12示出,OS可见定序器c已执行在EIPt的指令,在图11的块1108为EIP t设置了断点。
图12示出,已设置断点的指令t的执行生成引起到SEL 1250控制的过渡1201的调试异常。SEL 1250因而依赖其在暂停方法1100(图11)期间设置的断点来确定恢复纤程的时间。
图12示出,响应于过渡1201,SEL 1250开始纤程恢复方法1200的执行。该方法从块1202开始,并继续到块1204。在块1204,执行验证以证实适当的纤程已生成调试异常和结果控制过渡1201。也说是说,对于至少一个实施例,在任一线程、甚至不同的线程执行在指定的断点EIP地址的指令时,可触发调试异常。
在块1204,SEL 1250因此证实与生成调试异常和结果控制过渡1201的线程相关联的线程标识符匹配暂停纤程相关联的线程的线程标识符。对于至少一个实施例,通过比较在用于OS可见定序器c的VMCS 1280的客户区域中的线程标识符(如CR3寄存器值)与用于隔离定序器d的VMCS 1282的客户区域中的线程标识符值(如CR3寄存器值)执行此类验证1204。如果值匹配,则处理继续到块1206。否则,由于“虚假命中”而生成过渡1201,并且处理继续到块1210。
在块1206,SEL 1250清除其以前在图11的块1108在调试寄存器中设置的断点值。处理随后继续到块1208和1209,其中,SEL 1250放弃对OS可见线程和OS不可见纤程的控制(不必为所示顺序)。处理随后在块1214结束。
在块1210,在EIP t的指令是单步式(这可包括诸如EFLAGS指示符等异常指示符的修改以指定在由定序器c执行下一指令后应生成异常)。处理随后继续到块1212。在块1212,从调试寄存器清除在图11的块1108生成的断点设置。处理随后继续到块1213,在该块中,将控制交给OS可见定序器的客户OS。方法1200的处理随后在块1214结束。
对于至少一个实施例,在处理“虚假命中”期间,可在块1213将控制交给OS可见定序器后执行恢复机制的另外的阶段(未示出)。也说是说,在客户OS已由于块1213而进行控制后,它将执行其下一指令。由于在块1210的单步式设置,客户OS将在执行这一个指令后再次遇到异常。在处理此异常期间,SEL 1210可重置调试寄存器,以便它可执行方法1200来尝试下次由在OS可见定序器上的纤程执行所示EIP时恢复纤程处理。
代理执行。术语代理执行在本文中使用时指定序器间纤程迁移-控制和状态信息从隔离定序器转移到OS可见定序器,使得OS可见定序器可触发操作系统来代表隔离定序器执行特权操作。代理执行因此是一种工具,通过它OS可见定序器可得到操作系统的注意,以处理在隔离定序器上的纤程执行期间发生的系统事件。代理执行可用于向应用程序员显现有关包括非对称定序器的系统的架构对称性错觉。下面参照图13进一步论述代理执行。
图13是控制流程图,示出在包括一个或多个隔离定序器b和一个或多个OS可见定序器a的多定序器系统中的代理执行机制的至少一个实施例。对于如图13所示的代理执行的至少一个实施例,假设OS可见定序器a的客户操作系统不知道在隔离定序器b上执行的纤程。还假设在隔离定序器b上运行的纤程无法执行需要OS服务的特权指令。对于至少一个实施例,可由SEL的代理执行模块(参见图4中所示的SEL 402的模块406)执行图13所示的方法1300。
概括地说,图13示出一个实施例,其中,OS可见定序器a模仿纤程以便处理需要操作系统的某种形式的服务的事件,如缺页故障、系统调用及诸如此类。这样,触发操作系统来为在纤程执行期间发生的系统事件服务。
为便于说明,图13示出一种利用代理执行处理由纤程生成的缺页故障的方法。然而,本领域的技术人员将认识到,图13所示的方法1300的替代实施例可用于代表纤程处理任一异常、中断、系统调用或其他特权事件和/或系统事件。
对于图13所示的代理机制的至少一个实施例,示出了三个操作阶段。在第一阶段1310,执行初始化。可由SEL 1350执行此类初始化1310。在此类初始化1310期间,配置控制结构,使得只要在隔离定序器b上运行的纤程遇到选定类型的系统事件,便将发生到SEL1350控制的过渡。可为诸如缺页故障、系统调用等需要代理执行的多个类型的系统事件执行此类初始化1310。由于初始化1310的原因,只要在隔离定序器b上的纤程执行期间发生选定事件类型之一,SEL1350将进行控制。对于其中SEL 1350是VMM的一部分的一个实施例,初始化1310实现了一种在发生任一选定系统事件时引发VMEXIT(控制转移到VMM)的机制。
对于至少一个实施例,可通过在用于隔离定序器b的VMCS 1382中设置用于每个所需系统事件的异常位,执行初始化1310。虽然图13只示出一个隔离定序器b及其相关联的VMCS 1382,但应理解,可为多个隔离定序器执行初始化1310。
图13示出,可由隔离定序器b执行第二阶段1320。当在隔离定序器b上的纤程执行期间,定序器可生成选定的系统事件之一。响应于该系统事件,纤程的事件处理程序(未示出)可捕获纤程的当前状态,包括纤程的当前EIP及由定序器生成的、便于事件处理或识别的所有出错代码。(对于包括作为客户OS的WINDOWS操作系统的实施例,捕获纤程状态可包括捕获CR2控制寄存器的值以捕获引发系统事件的指令的地址。)事件处理程序随后可生成到SEL1350控制的过渡1301。对于其中SEL 1350是VMM的一部分的实施例,在第二阶段1320期间生成的过渡1301可称为VMEXIT。
随后,在第二阶段1320期间,当发生选定的系统事件之一时触发到SEL 1350控制的过渡(如VMEXIT)。可基于定序器的VMCS1382中的、在定序器b的初始化1310期间设置的异常位来触发此类过渡1301。
图13示出,在发生VMEXIT类型的过渡1301时,将控制转移给SEL 1350。在第三阶段1330期间,SEL 1350执行代理执行的方法1300。通常,方法1300涉及a)保存在OS可见定序器上运行的OS可见线程的状态;b)将状态从事件生成纤程迁移到OS可见定序器;c)将控制转移给OS可见定序器,以便它可在OS可见定序器上再现(如果可行)在隔离定序器上发生的事件,使得d)操作系统为事件服务;e)恢复SEL控制并还原OS可见定序器的原始状态;以及f)随后继续OS可见和隔离定序器两者的原执行流。下面更详细地论述方法1300的这些要素中的每个要素。
对于替代实施例,SEL 1350可只是捕获事件,并随后可跳到预指配的地址以执行用户生成的出错处理例程,而不是执行方法1300。对于此类替代实施例,可通过用户生成的出错处理例程而不是由SEL1350来执行方法1300的功能。
图13示出,方法1300从块1302开始,并继续到块1304。在块1304,SEL 1350准备将纤程状态从隔离定序器b迁移到OS可见定序器a。对于至少一个实施例,此类准备1304包括将事件生成隔离定序器b的状态保存到还可由OS可见定序器a访问的状态储存区域1315(参见区域“b”)。对于至少一个实施例,可响应于由SEL 1350执行的VMCALL指令的特定上下文状态储存变体,执行此类动作。对于至少一个实施例,在本文中称为SSAVE的示范上下文状态储存变体将定序器标识符和指针指定到保存区域1315中。
对于至少一个实施例,为纤程状态迁移所做的准备1304还可包括在OS可见定序器a采纳隔离定序器的状态前保存此类定序器的状态。这样,保存OS可见定序器a的状态并可在以后OS可见定序器a恢复其自己的线程时还原该状态。同样地,可响应于将指针指定到保存区域1315中的上下文保存指令,将OS可见定序器a的状态保存到保存区域1315(参见区域“a”)。处理随后可从块1304继续到块1306。
在块1306,将事件生成纤程的控制从隔离定序器b转移给OS可见定序器a。对于至少一个实施例,通过为OS可见纤程执行可由SEL执行VMCALL指令的代理变体而触发的入口方案,实现转移1306。(对于上述的一个替代实施例,可通过由在隔离定序器b上的出错处理例程(未示出)生成的VMCALL代理指令实现转移1306。)VMCALL指令的代理变体可指示以下参数目的定序器标识符、入口方案标识符和等待/无等待指示符。图13的块1306示出,图13所示示例的示范代理指令的参数可包括以下参数值a、begin_proxy、wait。相应地,将控制转移给定序器a以开始执行代理方案,并且隔离定序器(b)在继续其自己的指令流的执行前要等待该代理方案的完成。
对于至少一个实施例,控制迁移1306,在由SEL 1350执行时,在SEL 1350响应于在OS可见定序器上的环0到环3过渡而进行控制时来执行。然而,此类等待不是必需的。对于至少一个替代实施例,立即执行控制迁移1306,而不是等待下一个到SEL 1350控制的过渡。
对于至少一个实施例,控制迁移1306包括将事件生成定序器b的保存状态(包括CR2和EIP)从状态区域1315(b部分)迁移到代理定序器a。在转移控制前,SEL 1350还可在块1306采取步骤以在OS可见处理器a上注入系统事件。
图13示出,响应于在块1306执行的控制转移,将控制返回给OS可见定序器a的OS。控制转移1306可实施为Yield指令,使得OS可见定序器a暂停其当前线程的执行,并开始在EIP begin_proxy的执行,这是代理执行例程1400的开始。
在OS可见定序器a执行了代理执行例程1400(下面结合图14论述)后,在块1308控制返回给SEL 1350。在块1308,SEL 1350从状态保存区域1315还原OS可见定序器的原始状态(在块1304保存)。类似于在上面表1中所列的RSTOR方案,可通过VMCALL指令的RSTOR变体来实施此类状态还原。类似地,在块1308,SEL1350从状态保存区域1315的其相关联部分b还原隔离定序器的原始状态(也在块1304保存)。VMM 1350随后恢复在隔离定序器b上的纤程和在OS可见定序器a上的线程。方法1300随后在块1310结束。
图14是示出代理执行方法1400的流程图。对于至少一个实施例,可由诸如OS可见定序器的一个定序器代表诸如隔离定序器的另一定序器执行此类方法1400。图14示出,方法1400从块1402开始,并继续到块1404。
在块1404,OS可见定序器尝试再现在隔离定序器上触发的系统事件。对于至少一个实施例,可经SEL 1350将系统事件注入OS可见定序器a的OS而实现系统事件的再现。(参阅上面块1306的论述。)对于至少一个实施例,可使用“进入时转向(vector on entry)”特性来注入此类事件,该特性允许VMM注入异常并随后恢复客户OS。这样,SEL 1350可在代理定序器a上模仿系统事件。图14示出,事件模仿可在OS可见定序器上引发环3到环0过渡。
处理随后继续到块1406。在块1406,代理定序器的OS在环0特权级处理系统事件(参阅上面结合图8的非特权环0级“0D”的论述)。例如,如果事件是缺页故障,则事件可在需要时通过从盘调页(paging)来处理1406。客户OS的事件处理程序还可执行另外的任务,如修改页表等。方法1400随后继续到块1408。
在块1408,代理定序器尝试执行如其当前EIP值所示的、其指令流中的下一指令。将注意到,对于至少一个实施例,代理定序器的EIP可由于代理相关状态迁移而已被修改(参见图13的块1306)。因此,在块1408,代理定序器可尝试执行引起事件的指令(例如,参阅图13中在EIPt的指令),该事件是首先触发代理执行的事件。对于至少一个实施例,执行特权指令的尝试将引发环3到环0过渡。
相应地,在OS可见定序器的客户OS在块1406维修异常后,在块1408,环0到环3过渡可在定序器尝试执行事件触发指令时发生。该过渡指示OS事件处理服务完成。因此,该过渡表示代理执行服务结束。当代理执行这样完成时,在OS可见处理器上的模仿的处理完成,并且将控制迁回给原始定序器b因而是适当的。由于例如在图7的块730可能已执行的初始化的原因,在环过渡时生成的异常造成到SEL 1350的陷阱。
在发生由在块1408的执行事件生成指令的尝试生成的环过渡时,控制过渡回给SEL 1350(参见图13的块1308)。
虽然上面结合图13所述的处理是在利用OS可见定序器代表OS不可见定序器执行操作的说明性上下文中论述,但此类说明性上下文不应视为限制。例如,对于一个替代实施例,可利用图13所示的代理机制的替代实施例,使得一个OS隔离定序器可代表另一OS隔离定序器执行指令。例如可在包括非对称定序器的多定序器系统上利用此类实施例。
因此,应注意的是,能够执行本文中公开的技术实施例的系统的定序器无需对称。定序器可以在任一方面不同,包括影响计算质量的那些方面。例如,定序器可在功耗、计算性能速度、功能特性或诸如此类方面不同。例如,对于一个实施例,定序器可在功能方面不同。图7-13所示的功能非对称性的示例示出,至少一个定序器可以是OS可见的(例如参见图1的140)并可以因此能够执行“环0”操作,如执行系统调用、维修缺页故障及诸如此类。另一方面,一个或多个其他定序器可与OS隔离,并因此无法执行环0操作。然而,这只是功能对称性的一个示例。多定序器系统的定序器还可在任一其他方面不同,如尺寸、字和/或数据路径大小、拓扑、存储器、功耗、功能单元数量、通信架构(多点与点对点互连)或与功能、性能、占地面积或诸如此类相关的任何其他度量。
例如,一个定序器可能能够执行整数和浮点指令,但无法执行指令扩展的单指令多数据(“SIMD”)集,如流式SIMD扩展3(“SSE3”)。另一方面,另一定序器可能能够执行第一定序器可以执行的所有指令,并且也可以执行SSE3指令。对于此类实施例,可利用图13所示的代理机制的替代实施例,使得诸如能够执行SSE3指令的一个OS隔离定序器可充当代理,为诸如无法执行SSE3指令的另一OS隔离定序器执行代码。类似地,可调用代理执行机制的实施例以实现例如隔离处理器不支持的特殊浮点指令的执行。这样,非对称性可以是对应用程序员透明的。
可在包括单核SMT系统(例如参见图3的310)和多核系统(例如参见图3的350)的任一多定序器系统上实施本文中论述的纤程处理仿真层和相关联的技术。下面结合图15进行此类系统的进一步论述。
图15示出能够执行公开技术的计算系统1500的至少一个示范实施例。计算系统1500包括至少一个处理器核1504和存储器系统1540。存储器系统1540可包括更大、相对较慢的存储器存储部件1502及一个或多个更小、相对较快的高速缓存,如指令高速缓存1544和/或数据高速缓存1542。存储器存储部件1502可存储用于控制处理器核1504的操作的指令1510和数据1512。
旨在将存储器系统1540作为存储器的广义表示,并且存储器系统1540可包括多种形式的存储器,如硬盘驱动器、CD-ROM、随机存取存储器(RAM)、动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、闪存及相关的电路。存储器系统1540可存储由处理器1504可执行的数据信号表示的指令1510和/或数据1512。指令1510和/或数据1512可包括用于执行本文中论述的任一或所有技术的代码和/或数据。例如,指令1510可包括实施纤程处理仿真层402的指令。
处理器1504可包括向执行核1530提供指令信息的前端1520。取出的指令信息可在高速缓存1525中缓冲以等待由执行核1530来执行。前端1520可按程序顺序向执行核1530提供指令信息。对于至少一个实施例,前端1520包括确定要执行的下一指令的取出/解码单元322。对于系统1500的至少一个实施例,取出/解码单元322可包括单个下一指令指针和取出逻辑320。然而,在其中每个处理器1504支持多个线程上下文的一个实施例中,取出/解码单元322为每个支持的线程上下文实施独特的下一指令指针和取出逻辑320。在图15中由虚线表示多处理器环境中另外的下一指令指针和取出逻辑320的可选本质。
可以用硬件、硬件仿真软件或其他软件、固件或此类实施方案的组合来实施本文中所述的方法实施例。可为包括至少一个处理器、数据存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入装置和至少一个输出装置的可编程系统来实施本发明的实施例。对本申请来说,处理系统包括具有处理器的任一系统,如数字信号处理器(DSP)、微控制器、专用集成电路(ASIC)或微处理器。
程序可存储在通用或专用可编程处理系统可读取的存储介质或装置(例如,硬盘驱动器、软盘驱动器、只读存储器(ROM)、CD-ROM装置、闪存装置、数字多功能盘(DVD)或其他存储装置)上。处理系统中的处理器可访问的指令提供在处理系统读取存储介质或装置以执行本文中所述的过程时配置和操作处理系统。本发明的实施例还可视为实施为配置用于处理系统的机器可读存储介质,其中,如此配置的存储介质使处理系统以特定和预定方式操作来执行本文中所述的功能。
示范系统1400代表基于Intel公司提供的Pentium、PentiumPro、PentiumII、PentiumIII、Pentium4及Itanium和Itanium2微处理器的处理系统,但还可使用其他系统(包括具有其他微处理器的个人计算机(PC)、工程工作站、个人数字助理和其他手持式装置、机顶盒及诸如此类)。对于一个实施例,示范系统可执行Microsoft公司提供的WindowsTM操作系统版本,但还可使用例如其他操作系统和图形用户界面。
虽然已示出和描述了本发明的特殊实施例,但本领域的技术人员将明白,在不脱离随附权利要求书在其更广义方面的范围的情况下,可进行更改和修改。随附权利要求书因此将在其范围内包含在本发明真实范围内的所有此类更改和修改。
权利要求
1.一种方法,包括向与操作系统(OS)隔离的定序器发出一个或多个线程控制信号;其中,响应于用户生成的指令由抽象层执行所述发出。
2.如权利要求1所述的方法,其中还响应于OS可见定序器上的、OS可见线程中的所述用户生成的指令的执行由所述抽象层执行所述发出。
3.如权利要求1所述的方法,其中所述一个或多个线程控制信号还包括使所述隔离定序器开始执行指令序列的信号。
4.如权利要求3所述的方法,其中所述一个或多个线程控制信号还包括使所述隔离定序器开始执行在修改的指令指针地址的指令序列的信号。
5.如权利要求1所述的方法,还包括在第一定序器上并发执行由所述操作系统调度的第一指令序列,其中,所述第一指令序列包括所述用户生成的指令;同时在所述隔离定序器上执行第二指令序列。
6.如权利要求1所述的方法,还包括为所述隔离定序器生成执行环境;其中,由所述抽象层执行所述生成。
7.如权利要求1所述的方法,其中,所述线程控制信号还包括中断所述隔离定序器上的执行的信号。
8.如权利要求7所述的方法,其中,所述线程控制信号还包括中断信号。
9.如权利要求1所述的方法,还包括执行一组操作以使OS可见定序器代表所述隔离定序器触发事件处理例程的执行;其中,由所述抽象层执行所述一组操作。
10.如权利要求9所述的方法,其中,所述一组操作还包括将所述隔离定序器的状态迁移到所述OS可见定序器。
11.如权利要求1所述的方法,还包括执行一组操作以使所述隔离定序器上的执行暂停;其中,响应于OS可见定序器上的环过渡由所述抽象层执行所述一组操作;以及其中,所述一组操作还包括发出所述一个或多个控制信号,其中,所述控制信号包括将所述隔离定序器置于等待状态的信号。
12.如权利要求11所述的方法,其中,所述一组操作还包括以对所述OS透明的方式跟踪所述OS可见定序器上的环过渡。
13.如权利要求1所述的方法,还包括执行一组操作以使所述隔离定序器上的执行恢复;其中,响应于OS可见定序器上的异常处理例程的完成由所述抽象层执行所述一组操作;以及其中,所述一组操作还包括发出所述一个或多个控制信号,其中,所述控制信号包括恢复所述隔离定序器上的执行的信号。
14.如权利要求13所述的方法,其中,所述一组操作还包括清除所述OS可见定序器上的断点。
15.一种系统,包括并发执行多个指令流的多个定序器;耦合到所述定序器的存储器;耦合到所述定序器、将所述定序器中的一个或多个与操作系统隔离的抽象层;其中,所述抽象层还控制所述隔离定序器中的一个或多个上的一个或多个所述指令流的执行。
16.如权利要求15所述的系统,其中所述多个定序器至少之一相对于其他定序器中的一个或多个是计算上非对称的。
17.如权利要求15所述的系统,其中所述存储器是DRAM。
18.如权利要求15所述的系统,其中所述抽象层还包括隔离所述一个或多个定序器的定序器隔离模块。
19.如权利要求15所述的系统,其中所述抽象层还包括为所述隔离定序器调用操作系统服务的代理执行模块。
20.如权利要求15所述的系统,其中所述抽象层还包括在所述多个定序器中的至少两个之间提供信令的定序器算术模块。
21.如权利要求15所述的系统,其中所述抽象层还包括使所述隔离定序器至少之一在所述操作系统的环0操作期间暂停操作的过渡检测模块。
22.如权利要求21所述的系统,其中所述抽象层还包括使所述隔离定序器至少之一在所述操作系统的环0操作后恢复操作的过渡检测模块。
23.如权利要求15所述的系统,其中所述抽象层的指令包括在所述存储器中。
24.如权利要求15所述的系统,其中所述存储器包括将所述操作系统作为所述抽象层的客户运行的指令。
25.一种制品,包括具有抽象层的多个机器可访问指令的机器可访问介质,其中,在所述指令由处理器执行时,所述指令提供以下操作向与操作系统(OS)隔离的定序器发出一个或多个线程控制信号;其中,响应于用户生成的指令由所述抽象层执行用于所述发出的所述指令。
26.如权利要求25所述的制品,其中还响应于OS可见定序器上的、OS可见线程中的所述用户生成的指令的执行由所述抽象层执行用于所述发出的所述指令。
27.如权利要求25所述的制品,其中所述一个或多个线程控制信号还包括使所述隔离定序器开始执行指令序列的信号。
28.如权利要求27所述的制品,其中所述一个或多个线程控制信号还包括使所述隔离定序器开始执行在修改的指令指针地址的指令序列的信号。
29.如权利要求25所述的制品,其中,所述处理器还在第一定序器上并发执行由所述操作系统调度的第一指令序列,其中,所述第一指令序列包括所述用户生成的指令;同时在所述隔离定序器上执行第二指令序列。
30.如权利要求25所述的制品,其中,所述抽象层指令还包括在由所述处理器执行时提供以下操作的指令为所述隔离定序器生成执行环境。
31.如权利要求25所述的制品,其中,所述线程控制信号还包括中断所述隔离定序器上的执行的信号。
32.如权利要求31所述的制品,其中,所述线程控制信号还包括中断信号。
33.如权利要求25所述的制品,其中,所述抽象层指令还包括在由所述处理器执行时提供以下操作的指令执行一组操作以使OS可见定序器代表所述隔离定序器触发事件处理例程的执行。
34.如权利要求33所述的制品,其中,所述一组操作还包括将所述隔离定序器的状态迁移到所述OS可见定序器。
35.如权利要求25所述的制品,其中,所述抽象层指令还包括在由所述处理器执行时提供以下操作的指令执行一组操作以使所述隔离定序器上的执行暂停;其中,响应于OS可见定序器上的环过渡由所述抽象层执行所述一组操作;以及其中,所述一组操作还包括发出所述一个或多个控制信号,其中,所述控制信号包括将所述隔离定序器置于等待状态的信号。
36.如权利要求35所述的制品,其中,所述一组操作还包括在所述OS可见定序器上设置断点。
37.如权利要求25所述的制品,其中,所述抽象层指令还包括在由所述处理器执行时提供以下操作的指令执行一组操作以使所述隔离定序器上的执行恢复;其中,响应于OS可见定序器上的异常处理例程的完成由所述抽象层执行所述一组操作;以及其中,所述一组操作还包括发出所述一个或多个控制信号,其中,所述控制信号包括恢复所述隔离定序器上的执行的信号。
38.如权利要求37所述的制品,其中,所述一组操作还包括清除所述OS可见定序器上的断点。
39.如权利要求12所述的方法,其中,所述跟踪还包括设置所述OS可见定序器的断点。
全文摘要
本文公开了经抽象层为包括与操作系统控制隔离的一个或多个定序器的系统提供OS不可见执行“纤程”的用户级创建、控制和同步的方法、设备和系统实施例。对于至少一个实施例,抽象层提供隔离逻辑、代理执行逻辑、过渡检测和纤程暂停逻辑及定序器算术逻辑。本文还描述和声明了其他实施例。
文档编号G06F9/50GK101095112SQ200580045750
公开日2007年12月26日 申请日期2005年12月28日 优先权日2004年12月30日
发明者G·钦亚, H·王, X·邹, S·考施克, B·比比, J·沈, T·迪普, A·阿加瓦尔, B·V·帕特尔, J·P·赫尔德, P·塞蒂, R·A·汉金斯, J·L·赖德 申请人:英特尔公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1