KR20070095382A - 사용자-레벨 멀티스레딩 방법 및 시스템과 머신-액세스가능매체를 포함하는 물품 - Google Patents

사용자-레벨 멀티스레딩 방법 및 시스템과 머신-액세스가능매체를 포함하는 물품 Download PDF

Info

Publication number
KR20070095382A
KR20070095382A KR1020077017661A KR20077017661A KR20070095382A KR 20070095382 A KR20070095382 A KR 20070095382A KR 1020077017661 A KR1020077017661 A KR 1020077017661A KR 20077017661 A KR20077017661 A KR 20077017661A KR 20070095382 A KR20070095382 A KR 20070095382A
Authority
KR
South Korea
Prior art keywords
sequencer
user
isolated
instruction
visible
Prior art date
Application number
KR1020077017661A
Other languages
English (en)
Other versions
KR100951734B1 (ko
Inventor
가우담 친야
홍 왕
시앙 조우
시브 카우시크
브라이언트 빅비
존 센
트룽 디에프
아닐 아가발
베이주 브이 파텔
제임스 폴 헬드
프라샨트 세티
리차드 에이 한킨스
존 엘 레이드
Original Assignee
인텔 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 인텔 코포레이션 filed Critical 인텔 코포레이션
Publication of KR20070095382A publication Critical patent/KR20070095382A/ko
Application granted granted Critical
Publication of KR100951734B1 publication Critical patent/KR100951734B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Executing Machine-Instructions (AREA)
  • Debugging And Monitoring (AREA)
  • Devices For Executing Special Programs (AREA)
  • Logic Circuits (AREA)
  • Programmable Controllers (AREA)
  • Advance Control (AREA)

Abstract

운영체계 제어로부터 격리된 하나 이상의 시퀀서를 포함하는 시스템에 추상화 계층을 통한 실행의 OS-가시형 "슈레드"의 사용자-레벨 생성, 제어 및 합성을 제공하는 방법, 장치 및 시스템 실시예를 제공한다. 적어도 일 실시예에서, 추상화 계층은 격리 로직, 프록시 실행 로직, 전환 검출 및 슈레드 일시정지 로직, 그리고 시퀀서 연산 로직을 제공한다. 다른 실시예도 기술되고 청구된다.

Description

사용자-레벨 멀티스레딩 방법 및 시스템과 머신-액세스가능 매체를 포함하는 물품{MECHANISM TO EMULATE USER-LEVEL MULTITHREADING ON AN OS-SEQUESTERED SEQUENCER}
본 발명은 일반적으로 정보 처리시스템에 관한 것으로, 특히 하나 이상의 시퀀서(sequencer)가 운영체제로부터 격리될 수 있는 다중-시퀀서 시스템 상의 멀티스레딩(multithreading)에 관한 것이다.
마이크로프로세서를 포함하는 시스템과 같은 정보 처리 시스템의 성능을 증가시키기 위해, 하드웨어 및 소프트웨어 기법 모두를 사용해 왔다. 하드웨어 측면에서는, 마이크로프로세서 성능을 향상시키기 위한 마이크로프로세서 설계 방식은 증가된 클럭 속도, 파이프라이닝(pipelining), 브랜치 예측(branch prediction), 슈퍼-스칼라 처리(super-scalar execution), 비순차적 명령어 처리(out-of-order execution) 그리고 캐쉬(cache)를 포함하여 왔다. 많은 그러한 방식은 트랜지스터 개수를 증가시켰고, 일부 예에서는 증가된 성능의 비율보다 더 높은 비율로 트랜지스터 개수를 증가시키는 결과를 초래하였다.
추가적인 트랜지스터를 통해 전적으로 성능을 증가시키려 하기보다는, 다른 성능 향상은 소프트웨어 기법을 필요로 한다. 프로세서 성능 향상을 위해 사용되어 온 하나의 소프트웨어 방식은 "멀티스레딩(multithreading)"으로 알려져 있다. 소프트웨어 멀티스레딩에서, 명령어 스트림은 병렬로 실행 가능한 다수의 명령어 스트림으로 분할될 수 있다. 양자택일적으로, 다수의 독립적인 소프트웨어 스트림이 병렬로 실행되기도 한다.
타임-슬라이스(time-slice) 멀티스레딩 또는 타임-멀티플렉스("TMUX") 멀티스레딩으로 알려진 하나의 방식에서, 단일 프로세서는 고정된 시간 후에 스레드 사이에서 스위칭한다. 다른 방식에서는, 단일 프로세서는 긴 래이턴시 캐쉬 미스(long latency cache miss)와 같은 트리거 이벤트(trigger event)가 발생할 때 스레드 사이에서 스위칭한다. 스위치-온-이벤트(switch-on-event) 멀티스레딩("SoEMT")으로 알려진 이러한 후자의 방식에서는, 기껏해야 하나의 스레드만이 소정 시간에서 활성화된다.
점차적으로, 멀티스레딩은 하드웨어에서 지원된다. 예를 들어, 하나의 방식에서, 칩 멀티프로세서(CMP) 시스템(단일 칩 패키지 상의 다수의 프로세서)과 대칭적 멀티스레딩(SMP) 시스템(다수의 칩 상의 다수의 프로세서) 같은 다중-프로세서 시스템 내의 프로세서는 각각 다수의 소프트웨어 스레드(thread) 중의 하나 상에서 공동으로 작용할 수도 있다. 동시 멀티스레딩(SMT)라 불리는 다른 방식에서는, 단일 물리 프로세서는 운영체계와 사용자 프로그램에 대해 다수의 논리 프로세서로서 보여 지도록 만들어진다. SMT에 대해, 다수의 소프트웨어 스레드는 활성화되고 스 위칭 없이 단일 프로세서 상에서 동시에 처리될 수 있다. 즉, 각각의 논리 프로세서는 완전한 아키텍처 상태 세트를 유지하지만, 캐쉬, 실행 유닛, 브랜치 예측기, 제어 로직 그리고 버스와 같은 물리 프로세서의 많은 다른 자원은 공유된다. SMT에 대해, 다수의 소프트웨어 스레드로부터의 명령어는 각각의 논리 프로세서 상에서 동시에 처리된다.
SMT, SMP 및/또는 CMP 시스템과 같은 소프트웨어 스레드의 동시 처리를 지원하는 시스템에 대해, 운영체계 애플리케이션은 소프트웨어 스레드의 처리와 스케줄링을 제어할 수도 있다. 그러나 일반적으로 운영체계 제어는 잘 스케일링(scale)되지 않는다. 성능에 부정적 영향을 미치지 않고 스레드를 스케줄링하기 위한 운영체계 애플리케이션의 능력은 보통 상대적으로 적은 수의 스레드로 제한된다.
본 발명의 실시예는 유사한 구성요소를 유사한 번호로 나타내는 후속하는 도면을 참조하여 이해될 수 있다. 이러한 도면은 한정하려고 의도된 것이 아니라 다중-시퀀서(multi-sequencer) 시스템 상의 사용자-레벨 멀티스레딩을 실행하기 위한 장치, 시스템 그리고 방법의 선택된 실시예를 서술하기 위해 제공된 것으로, OS-격리형 시퀀스 상의 사용자-레벨 슈레드(shred) 제어는 OS-투명형(transparent) 추상화 계층(abstraction layer)을 통해 제공된다.
도 1은 다중-시퀀서 시스템을 위한 일반적인 병렬 프로그래밍 방식의 그래픽 표현을 제공하는 블록도,
도 2는 사용자-레벨 멀티스레딩의 적어도 일 실시예를 위한 슈레드와 스레드 사이에 공유된 메모리와 상태를 나타내는 블록도,
도 3은 다중-시퀀서 시스템의 다양한 실시예를 나타내는 블록도,
도 4는 다중-시퀀서 멀티스레딩 시스템에 대한 소프트웨어 메커니즘의 적어도 일 실시예를 나타내는 블록도,
도 5는 가상 머신 모니터의 일부로서 슈레딩 에뮬레이션 계층을 포함하는 다중-시퀀서 처리 시스템을 나타내는 블록도,
도 6은 하나 이상의 시퀀서의 격리를 보여주는 적어도 일 실시예를 나타내는 블록도,
도 7은 슈레딩 에뮬레이션 계층을 포함하는 소프트웨어 계층을 개시하는 방법의 적어도 일 실시예를 나타내는 흐름도,
도 8은 운영체계와 가상 머신 모니터의 개시 후 예시적인 다중-시퀀서 시스템의 OS-가시형(visible) 시퀀서 및 격리형 시퀀서의 상태를 나타내는 블록도,
도 9는 시퀀서 방향 재지정을 위한 방법의 적어도 일 실시예에 대한 방법 및 제어 흐름을 나타내는 제어 흐름도,
도 10은 슈레드 생성을 위한 방법의 적어도 일 실시예에 대한 방법 및 제어 흐름을 나타내는 제어 흐름도,
도 11은 링 전환에 기인한 슈레드 일시 정지의 적어도 일 실시예를 나타내는 제어 흐름도,
도 12는 링 전환이 핸들링된 후 슈레드 재개의 적어도 일 실시예를 나타내는 제어 흐름도,
도 13은 프록시 실행 메커니즘의 적어도 일 실시예를 나타내는 제어 흐름도,
도 14는 프록시 실행 방법의 적어도 일 실시예를 나타내는 흐름도,
도 15는 기재된 기법을 수행할 수 있는 시스템의 적어도 일 실시예를 나타내는 블록도.
후속하는 논의는 사용자-레벨 애플리케이션 프로그램이 다중-시퀀스 멀티스레딩 시스템에서 OS-독립형 스레드("슈레드"라 칭함)의 실행을 생성하고 제어하도록 하는 방법, 시스템 그리고 메커니즘의 선택된 실시예를 서술한다. 사용자-레벨 슈레드는 생성되고 스케줄링되고 충분한 운영체계 투명성(transparency)을 가지고 실행된다. 기재된 기법이 수행되는 다중-시퀀서 시스템의 하드웨어는 구조적인(architectural) 슈레드 제어 명령어를 필히 지원하지는 않는다. 대신, 그러한 기능성은 OS-투명형 소프트웨어 또는 하드웨어 에뮬레이션(emulation) 계층을 통해 제공될 것이다.
여기에 도시한 메커니즘은 단일-코어 또는 다중-코어 멀티스레딩 시스템과 함께 활용될 것이다. 다음의 서술에서, 프로세서 타입, 멀티스레딩 환경, 시스템 구성, 다중-시퀀서 시스템 내의 시퀀서의 개수 및 토폴로지, 마이크로아키텍처 구조 그리고 명령어 명명법 및 파라미터와 같은 많은 특정한 세부항목이 본 발명을 보다 철저히 이해하도록 설명되었다. 그러나 본 발명이 그러한 특정한 세부항목 없이도 실행될 수도 있음을 당업자는 인식할 것이다. 추가적으로, 본 발명을 쓸데없이 이해하기 어렵게 만드는 것을 피하기 위해 몇몇 잘 알려진 구조, 회로 등은 상세히 기술하지 않았다.
이하에서 논의되는 도 1 및 2는 공유 메모리 멀티프로세싱 패러다임을 도시하고 있다. 이 패러다임은 사용자-제어형 "슈레드"를 포함하는데 이는 운영체계 시야(view) 및 제어로부터 격리된 시퀀서 상에서 실행되는 명령어 시퀀스이다. 이러한 OS-격리형 시퀀스는 때로 "OS-비가시형(invisible)" 시퀀서로 불린다. 도 3 및 15는 상기 패러다임이 구현될 수 있는 프로세서 및/또는 시스템의 샘플 실시예를 나타낸다. 일반적으로 도 4는 슈레딩 에뮬레이션 계층이라 불리는 추상화 계층의 적어도 일 실시예를 나타내는데, 이러한 계층은 시퀀서 하드웨어가 구조적 슈레딩 명령어를 지원하지 않는 다중-시퀀서 시스템 상에 사용자-레벨 슈레딩 기능을 제공할 수도 있다. 마지막으로 도 5 내지 14는 슈레딩 에뮬레이션 계층에 대한 특정 방법 및 시스템 실시예를 보여준다.
공유 메모리 멀티프로세싱 패러다임은 병렬 프로그래밍이라 불리는 방식에서 사용될 수 있다. 이러한 방식에 따르면, 애플리케이션 프로그래머는 때로 "애플리케이션" 또는 "프로세스"라 불리는 소프트웨어 프로그램을 다수의 과업(task)으로 분리하는데 이들 과업은 소프트웨어 프로그램에 대한 병렬성(parallelism)을 표현하기 위해 동시에 실행된다. 동일한 소프트웨어 프로그램("프로세스")의 모든 스레드는 메모리의 공통 논리 시야를 공유한다.
도 1은 다중-시퀀서 멀티스레딩 시스템 상의 병렬 프로그래밍 방식의 그래픽 표현을 나타내는 블록도이다. 도 1은 운영체계(140)에 가시적인 프로세스(100, 120)를 도시하고 있다. 이들 프로세스(100, 120)는 예를 들어 워드 프로세싱 프로그램과 이메일 관리 프로그램과 같은 상이한 소프트웨어 애플리케이션 프로그램일 수 있다. 일반적으로, 각각의 프로세스는 상이한 어드레스 공간에서 수행된다.
운영체계("OS")(140)는 공통적으로 도 1에 도시된 프로세스(120)와 같은 프로세스에 대한 사용자-생성 과업을 관리할 책임이 있다. 따라서 운영체계(140)는 프로세스(120)와 연관된 사용자-정의 과업 각각에 대해 구별되는 스레드(125, 126)를 생성하고 스레드(125, 126)를 스레드 실행 자원에 매핑시킬 수 있다.(도 1이 스레드 실행 자원을 도시하고 있지 않으며 이하에서 상세히 논의한다.) OS(140)는 일반적으로 실행 자원 상에서의 실행을 위해 이들 스레드(125, 126)를 스케줄링할 책임이 있다. 단일 프로세스와 연관된 스레드는 전형적으로 동일한 메모리 뷰(view)를 가지며 동일한 가시적 어드레스 공간을 공유한다.
OS(140)가 스레드를 생성하고 매핑하고 스케줄링할 책임이 있기 때문에, 스레드(125, 126)는 OS(140)에게는 "가시적"이다. 추가적으로, 본 발명의 실시예는 OS(140)에 가시적이지 않은 추가 스레드(130-136)를 포함한다. 즉, OS(140)는 이들 추가 스레드(130-136)를 생성하거나 관리하거나 달리 인식하거나 제어하지 않는다. 이들 추가 스레드는 OS(140)에 의해 생성되지도 제어되지도 않으며 본 명세서에서 OS-가시형 스레드와 구분하기 위해 때로 "슈레드"(131-136)로 불린다. 슈레드는 사용자-레벨 프로그램에 의해 생성되고 관리되며 운영체계로부터 격리된 시퀀서 상에서 실행되도록 스케줄링된다. OS-격리형 시퀀서는 OS-가시형 시퀀서와 동 일한 링 0 상태를 공유한다. 그래서 슈레드(130-136)는 동일한 실행 환경(어드레스 맵)을 공유하는데, 이 환경은 동일한 프로세스(126)와 연관된 스레드(125, 126)에 대해 생성된다.
본 명세서에서 사용된 바와 같이, 용어 "스레드"와 "슈레드"는 적어도 프로세스의 다른 스레드 및/또는 슈레드와 동시에 실행되는 명령어 스트림의 독립적 실행의 개념을 포함한다. 스레드와 "슈레드" 용어는 모두 관련된 프로세서 상태와 함께 소프트웨어 명령어 스트림을 실행하는 아이디어를 포함하고 있다. 본 명세서에서 사용된 바와 같이, 명령어 스트림인 (OS-제어된) 스레드와 (운영체계에 비가시적이고 대신 사용자-제어된) 슈레드를 구별하는 기준이 되는 인자는 스레드와 슈레드 명령어 스트림의 실행을 관리하는 방법의 차이에 있다. 스레드는 OS에 대한 시스템 콜에 반응하여 생성된다. OS는 스레드를 생성하고 스레드를 운영하기 위해 자원을 배치한다. 스레드를 위해 배치된 자원은 스레드를 제어하고 스케줄링하기 위해 운영체계가 사용하는 데이터 구조를 포함할 수도 있다.
반면에, 슈레드의 적어도 일 실시예는 사용자-레벨 소프트웨어 명령어를 통해 생성되는데, 이 명령어는 OS가 인지하지 못하는 슈레드를 생성하는 다른 OS-독립형 메커니즘 또는 소프트웨어 라이브러리를 생성한다. 따라서 슈레드는 사용자-레벨 소프트웨어 라이브러리 콜에 반응하여 생성되기도 한다. 소프트웨어 라이브러리 콜은 소프트웨어 라이브러리에 의해 유지되는 슈레드 작업 대기열(work queue)(도시 안 됨) 내의 엔트리(entry)를 생성할 수도 있다. 그러한 슈레드 작업 대기열은 OS-격리형 시퀀서 상에서 실행되도록 스케줄링된 각각의 슈레드에 대한 엔트리를 홀딩할 수도 있다. 슈레드 작업 대기열의 적어도 일 실시예에 대한 추가 논의에 대해서는 발명의 명칭이 "Mechanism to Schedule Threads on OS-Sequestered Sequencers without Operating System Intervention"인 동시 계류중인 미국 특허 출원____(대리인 서류 번호: 42390.P20205)을 참조하기 바란다.
도 2는 동일한 소프트웨어 프로그램 또는 프로세스의 모든 스레드가 메모리의 공통 논리 뷰(view)를 공유하는 상기 진술에 대한 추가적인 상세화를 그래픽 형태로 보여주는 블록도이다. 본 발명의 실시예에 있어서, 이러한 진술은 또한 프로세스(100, 120)와 연관된 스레드에 대해서도 사실이다. 즉, 다수의 슈레드(130-136)는 단일 OS-관리형 스레드(125)와 연관될 수도 있다. 스레드(125)와 연관된 슈레드를 실행하기 위해 스레드(125)에 의해 초기화된 모든 시퀀서(seq. 1 - seq. 4)는 스레드에 대해 운영체계에 의해 구성된 가상 메모리의 동일한 뷰를 공유한다.
본 명세서에서는 도 1을 참조하여 도 2를 설명한다. 도 2는 도 1에 도시된 슈레드(130-136), 스레드(125, 126) 그리고 프로세스(120)의 그래픽 표현을 가정한다. 그러나 그러한 표현은 한정을 위한 목적으로 사용되어서는 안 된다. 본 발명의 실시예는 프로세스와 관련된 슈레드 또는 스레드의 개수에 대한 상한선 또는 하한선을 필히 정하지는 않는다. 하한선에 대해, 도 1은 소정 시간에 실행되는 모든 프로세스가 임의의 스레드 또는 슈레드와 필히 연관될 필요는 없음을 보여준다. 예를 들어, 도 1에 도시된 프로세스 0(100)은 도 1에 도시된 특정 시간에 스레드 또는 슈레드 없이 실행되도록 도시되어 있다.
그러나, 다른 프로세스(120)는 도 1에 도시된 바와 같이 하나 이상의 스레 드(125, 126)와 연관될 수도 있다. 또한, 프로세스(120)는 마찬가지로 하나 이상의 슈레드(130-136)와 추가적으로 연관될 수도 있다. 프로세스(120)에 대한 네 개의 슈레드(130-136)와 두 개의 스레드(125, 126)의 표현은 단지 실례를 든 것이므로 한정적으로 사용되어서는 안 된다. 프로세스와 연관된 OS-가시형 스레드의 개수는 OS 프로그램에 의해 한정되기도 한다. 그러나 프로세스와 연관된 슈레드의 누적 개수에 대한 상한선은, 적어도 일 실시예에서는, 실행되는 동안의 특정 시간에 사용가능한 스레드 실행 자원의 개수에 의해서만 제한된다. 도 2는 프로세스(120)와 연관된 제 2 스레드(126)가 제 1 스레드(125)와는 다른 스레드 개수(n)를 가질 수도 있음을 보여준다.(N은 스레드(125, 126) 중 하나 또는 모두에 대해 0이 될 수도 있다.)
도 2는 특정 프로세스(120)와 연관된 모든 스레드(125, 126)에 의해 공유된 메모리의 특정 논리 뷰(200)를 보여준다. 도 2는 각각의 스레드(125, 126)가 각각의 자체 애플리케이션 및 시스템 상태(202A, 202B)를 가지고 있음을 보여준다. 도 2는 스레드(125, 126)에 대한 애플리케이션 및 시스템 상태(202)를 특정 스레드와 연관된 모든 슈레드(예를 들어, 슈레드(130-136))가 공유함을 보여준다.
따라서, 도 2는 본 발명의 적어도 일 실시예에서의 시스템이 스레드(125)와 같은 OS-가시형 스레드와, 스레드와 연관된 (OS에 가시적이지 않은) 슈레드(130-136) 간의 1-대-다 관계를 지원할 수도 있음을 보여준다. OS가 아니라 애플리케이션 프로그래머가 슈레드를 생성하고 동기화하고 그렇지 않으면 그 동작을 관리하고 제어하기 위해 사용자-레벨 기법들을 채용할 수도 있다는 뜻에서 슈레드는 OS(도 1 의 140 참조)에 "가시적"이지 않다. OS(140)가 스레드(125, 126)를 인지하고 관리하는 반면에 OS(140)는 슈레드를 인지하지 못하고 관리하거나 제어하지 않는다.
그래서 스레드 유닛 하드웨어와 슈레드 간의 매핑을 관리하기 위해 운영체계에 의존하는 대신에, 그러한 매핑을 직접 제어하고 슈레드 실행과 연관된 제어 및 상태 전달을 직접 조작하기 위해 사용자-레벨 애플리케이션이 바람직할 것이다. 그러한 직접 제어 및 조작을 촉진시키기 위해, 스레드 유닛 구조의 사용자-가시형 특징은 적어도 표준 명령어 세트를 포함하기도 하는데, 이 세트는 사용자-레벨 애플리케이션 프로그램 직접 조작과 스레드 유닛 하드웨어의 조작을 가능케한다.
적어도 일 실시예에서, 다중-슈레딩 시스템 내의 후속하는 능력 중의 어느 것 또는 모든 것을 구현하는 것이 바람직할 것이다. 그러한 각각의 능력은 해당 능력을 달성하기 위한 별개의 구조적 명령어에 의해 지원될 것이다. 대안으로, 그러한 능력은 작은 슈레드 생성 및 제어 명령어 세트에 기초한 소프트웨어 라이브러리 기능 또는 더 높은 레벨의 프리미티브(primitive)에 의해 구현될 수도 있다. 추가 논의를 위해, 표준 구조적 사용자-레벨 슈레딩 명령어의 하드웨어 구현예는 발명의 명칭이 "A Mechanism For Instructions Set-Based Thread Execution on a Plurality of Instruction Sequencers"인 동시 계류중인 미국 특허 출원____(대리인 서류 번호: 42390.P19770)에서 알 수 있을 것이다.
사용자-레벨 슈레딩 프로그래밍 패러다임의 일부로소 프로그래머에게 제공될 수도 있는 그러한 능력은 다음의 능력 중의 어느 것 또는 모두 중의 하나 이상을 포함할 수도 있다.
1. OS 제어로부터 시퀀서의 격리
2. 인터-시퀀서 제어 전달을 달성하기 위한 시퀀서 연산
3. 링 전환 검출 및 사용자-레벨 예외 처리
4. 격리된 시퀀서에 대한 특권 동작의 처리를 지원하기 위한 OS-가시형 시퀀서에 의한 "프록시 실행"
이러한 각각의 능력은 이하에서 보다 상세히 논의한다.
사용자-레벨 슈레드 생성을 제공하고 앞서 열거한 사용자-레벨 슈레딩 능력이 하드웨어에서 구조적으로 지원되지 않는 시스템 상의 능력을 제어하는 것이 바람직할 것이다. 따라서 슈레드 생성, 제어 및 동기화 명령어의 기능성은 대신 추상화 계층에 의해 에뮬레이션될 것이다. 그것이 많은 후속의 논의와 클레임 그 자체가 말하는 사용자-레벨 슈레딩의 에뮬레이션이다. 그러한 에뮬레이션은 전술한 바와 같이 내재된(underlying) 스레드 유닛이 사용자-레벨 슈레드 생성, 매핑, 제어 및 동기화를 위한 구조적 명령어를 지원하지 않는 시스템에서 실행될 수도 있다. 그러나 본 명세서에서 논의된 소프트웨어 에뮬레이션 메커니즘의 실시예는 그러한 시스템에 한정되지는 않는다. 실시예는 하나 이상의 스레드 유닛이 구조적 슈레드 명령어를 지원하지 않는 시스템 상에서 실행될 수도 있다.
본 명세서에서 사용된 바와 같이, 본 명세서에서 "시퀀서"로 번갈아 지칭되기도 하는 스레드 유닛은 스레드 또는 슈레드를 실행시킬 수 있는 임의의 물리적 또는 논리적 유닛이 될 수도 있다. 그것은 소정의 스레드 또는 슈레드에 대해 실행될 다음 명령어를 결정하기 위한 다음 명령어 포인터 로직(pointer logic)을 포 함할 수도 있다. 예를 들어, 도 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의 완전한 세트를 유지한다. 적어도 일 실시예에서 구조적 상태는 데이터 레지스터, 세그먼트 레지스터, 제어 레지스터, 디버그(debug) 레지스터 그리고 대부분의 모델 전용 레지스터를 포함한다. 논리적 프로세서 LP1 - LPn는 캐쉬, 실행 유닛, 브랜치 예측기(branch predictor), 제어 로직 그리고 버스와 같은 물리적 프로세서(304)의 대부분의 다른 자원을 공유한다. 그러한 특징이 공유될 수 있다 하더라도, 멀티스레딩 환경(310) 내의 각각의 스레드 콘텍스트(context)는 독립 적으로 다음 명령어 어드레스를 생성할 수 있다(그리고 예를 들어 명령어 캐쉬로부터의 페치(fetch), 실행 명령어 캐쉬 또는 트레이스(trace) 캐쉬를 실행할 수 있다).
그래서, 다수의 논리적 시퀀서가 단일 물리적 페치/디코드 유닛(322)에서 구현될 수 있다 하더라도 프로세서(304)는 논리적으로 독립적인 다음-명령어-포인터 및 페치 로직(320)을 포함하여 각각의 스레드 콘텍스트에 대한 명령어를 페치한다. SMT 또는 실시예에서, 용어 "시퀀서"는 적어도 그러한 스레드 콘텍스트에 대한 다음-명령어-포인터 및 페치 로직(320)과 그러한 스레드 콘텍스트에 대해 연관된 구조적 상태, AS의 적어도 일부를 포함한다. SMT 시스템(310)의 시퀀스가 대칭일 필요는 없음을 알아야 한다. 예를 들어, 동일한 물리적 코어에 대한 두 개의 SMT 시퀀서는 서로 다른 분량의 구조적 상태 정보를 유지할 수도 있다.
그래서, 적어도 일 실시예에서, 다중-시퀀서 시스템(310)은 공동의 멀티스레딩을 지원하는 단일-코어 프로세서(304)이다. 이러한 실시예에서, 비록 동일한 물리적 프로세서 코어(304)가 모든 스레드 명령어를 실행한다 하더라도 각각의 시퀀서는 자체적으로 명령어 다음-명령어-포인터 및 페치 로직(320)과 구조적 상태 정보 AS를 갖는 논리적 프로세서이다. 이러한 실시예에서, 비록 단일 프로세서 코어의 실행 자원이 동시에 실행되는 스레드에 의해 공유될 수 있다 하더라도 논리적 프로세서는 그 자체의 구조적 상태 버전을 유지한다.
도 3은 또한 다중-코어 멀티스레딩 환경(350)의 적어도 일 실시예를 나타낸다. 그러한 환경(350)은 두 개 이상의 별개의 물리적 프로세서(304a-304n)를 포함 하며, 각각의 프로세서는 서로 다른 스레드/슈레드를 실행할 수 있으며, 그 결과 서로 다른 스레드/슈레드의 적어도 일부의 실행이 동시에 진행될 수도 있다. 스레드(304a 내지 304n) 각각은 물리적으로 독립적인 페치 유닛(322)을 포함하여 각각의 스레드 또는 슈레드에 대한 명령어 정보를 페치한다. 프로세서(304a-304n) 각각이 단일 스레드/슈레드를 실행하는 실시예에서, 페치/디코드 유닛(322)은 단일 다음-명령어-포인터 및 페치 로직(320)을 수행한다. 그러나 프로세서(304a-304n) 각각이 다수의 스레드 콘텍스트를 지원하는 실시예에서는, 페치/디코드 유닛(322)은 각각의 지원된 스레드 콘텍스트에 대해 구별되는 다음-명령어-포인터 및 페치 로직(320)을 수행한다. 다중프로세서 환경(350) 내의 추가적인 다음-명령어-포인터 및 페치 로직(320)의 선택적 특성은 도 3에서 점선으로 표시되어 있다.
그래서, 도 3에 도시된 다중-코어 시스템(350)의 적어도 일 실시예에서, 각각의 시퀀서는 단일 칩 패키지(360)에 속하는 다수의 코어(304a-304n)를 갖는 프로세서 코어(304)일 수 있다. 각각의 코어(304a-304n)는 단일 스레드된 또는 다중-스레드된 프로세서 코어일 수 있다. 칩 패키지(360)는 도 3에서 파선으로 표시되며, 다중-코어 시스템(350)의 단일-칩 실시예만을 보여준다. 다른 실시예에서는, 다중-코어 시스템(350)의 프로세서 코어(304a-304n)는 별개의 칩에 속할 수도 있다.
적어도 일 실시예에서는, 도 3에 도시한 바와 같이, 내재된 시퀀서 하드웨어의 구조적 명령어 세트는 앞서 열거한 사용자-레벨 슈레드 생성, 제어 및 동기화 능력을 제공하지 않는다. 그럼에도 불구하고, 프로그래머가 사용자-레벨 슈레딩 기능이 생기게 하는 코드를 기록할 수 있도록 하는 것이 바람직할 것이다. 그러한 시스템에 대해, 사용자-레벨 슈레딩 기능은 펌웨어 또는 소프트웨어 추상화 계층을 통해 에뮬레이션될 수 있으며, 그 결과 프로그래머는 내재된 하드웨어가 슈레드 명령어를 지원한 것처럼 투명하게 코드를 기록할 수도 있다. 소프트웨어 또는 펌웨어 계층은 추상화 계층을 제공할 수도 있으며, 그에 따라 OS-격리형 시퀀서의 OS-독립형 슈레드의 사용자-레벨 생성, 제어 및 동기화가 달성된다.
도 4는 운영체계(140)의 뷰 및 제어로부터 격리될 수 있는 하나 이상의 시퀀서를 포함하는 다중-시퀀서 멀티스레딩 시스템(400)에 대한 추상화 계층(402)의 적어도 일 실시예를 나타내는 블록도이다. 추상화 계층(402)은 사용자-레벨 슈레딩에 대한 구조적 명령어가 격리된 시퀀서 상에서 지원되지 않는 시스템에 대한 사용자-레벨 스레드 제어를 달성하기 위한 메커니즘을 제공한다. 따라서 도 4에 도시된 실시예에서, 다수의 시퀀서(432a-432n) 중의 하나 이상이 OS-독립형 슈레드의 실행을 제어하고 사용자-레벨 생성을 위한 구조적 하드웨어 지원을 제공하지 않고 동일한 시퀀서가 OS 시야 및 제어로부터 격리될 수도 있음을 가정한다.
도 4는 추상화 계층(402)이 논리적으로 다중-시퀀서 하드웨어(430)의 상부에 놓여진 추상화 계층인 것을 보여준다. 운영체계(140)는 추상화 계층보다 적어도 한 레벨 높은 곳에서 동작할 수 있으며, 이 계층은 여기서 때로 슈레딩 에뮬레이션 계층(shredding emulation layer : SEL)으로 불린다.
도 4는 SEL(420)이 다양한 슈레드 기능을 수행할 모듈을 포함할 수도 있음을 보여준다. 도 4는 SEL(420)이 시퀀서 격리 모듈(404), 프록시 실행 모듈(406), 시 퀀서 연산 모듈(408) 그리고 전환 검출 모듈(410)을 포함할 수도 있음을 보여준다. SEL(420)의 그러한 기능 모듈(404, 406, 408, 410)의 논리적 표현은 한정적인 것으로 사용되어서는 안 된다. 당업자는 모듈들이 특정 기능을 수행하기 위한 로직을 나타내려는 의도임을 알 것이다. 그러한 로직은 소프트웨어, 하드웨어, 펌웨어 또는 그들의 조합이 될 수도 있다. 추가적으로, 다수의 모듈(404, 406, 408, 410)에 대한 기능성은 더 많은 기능 또는 로직 모듈과 함께 실행될 수도 있다. 양자택일적으로, 하나 이상의 특정 모듈에 대한 로직은 더 작은 서브-모듈로 나누어질 수도 있다. 또한, 하나 이상의 모듈은 여분의 로직 카피(copy)를 포함하기보다는 공유 기능 콜 또는 다른 공유 로직과 같은 하나 이상의 다른 모듈과 로직을 공유할 수도 있다.
적어도 일 실시예에서는, SEL(402)는 독립형 로직 모듈이 될 수도 있다. 적어도 일 실시예에서는, SEL(402)는 기존의 로직 모듈에 변경을 가하여 구현될 수도 있다. 예를 들어, SEL(402)는 기존의 소프트웨어 추상화 계층에 대한 변형물 세트로 구현되기도 한다. 이하에서 논의되는 소정의 실시예는 가상 머신 모니터(virtual machine monitor : VMM)에 대한 변형물 세트로서 SEL(402)를 포함한다. 다시, 그러한 실시예는 특정한 구현 환경의 콘텍스트에서 SEL(402)의 선택된 특성을 보다 상세히 기술하기 위한 목적으로서만 제공된다. 그러나 VMM 실시예와 관련된 그러한 상세화의 후속 논의는 한정적으로 사용되어서는 안 된다. SEL(402)는 독립적으로 또는 다른 임의의 추상화 계층의 부분으로서 구현될 수도 있는데, 이런 다른 임의의 추상화 계층은 운영체계와 시퀀서 하드웨어 사이에 인터페이스를 제공 한다. 그럼에도 불구하고, 기존의 VVM에 대한 변형물로서 구현되기도 하는 SEL(402)의 그러한 실시예를 설명하기 위해, 도 5의 후속 논의는 예시적인 VMM 실시예에 관한 추가적인 정보를 제공한다.
도 5는 VMM(506)의 일부로서 SEL(402)를 포함하는 다중-시퀀서 프로세싱 시스템(500)을 나타내는 블록이다. 시스템(500)은 프로세서 자원(530)을 구비한 하드웨어 자원(520)을 포함한다. 프로세서 자원(530)은 다수의 시퀀서(532a-532n)를 포함한다. 시퀀서(532a-532n)는 비대칭일 수 있다.
도 5에 도시된 예시적 시스템(500)은 또한 여기서 논의된 다른 특성을 불명료하게 만들지 않기 위해 개별적으로 생략되어 왔던 다른 하드웨어 자원(526)을 포함할 수도 있다. 그러한 다른 하드웨어 자원(526)은 한정하지 않는 예로서 메모리, 주변 기기, 칩셋, 여러 메모리 등을 포함할 수도 있다.
도 5는 앞서 논의한 하드웨어 자원(520)에 더하여 시스템(500)이 소프트웨어 자원도 포함할 수 있음을 보여준다. 그러한 소프트웨어 자원은 가상 머신 모니터(506)를 포함한다. VMM(506)은 하나 이상의 운영체계(503a-503n)가 동일한 시스템(500) 상에서 동시에 실행될 수 있도록 프로세싱 시스템(500)의 하드웨어 자원을 분할하고 관리한다. OS(503a-503n) 각각은 파티션(partition) 또는 가상 머신(VM)(510a-510n)이라 불리는 상당히 독립적인 소프트웨어 환경 내에서 동작한다. 도 5에 도시한 예시적인 실시예에서, VMM(506)은 다수의 가상 머신(510a-510n)을 지원하며, 각각의 가상 머신은 그 자체의 독립적인 게스트 OS(503a-503n)를 각각 운영한다. 당업자는 여기서 논의된 실시예가 단일 VM(510)을 지원하는 시스템에도 채용될 수 있음을 알 것이다. 추가적인 VM(510)은 그들이 선택적으로 채용됨을 나타내기 위해 도 5에서 점선으로 표시한다.
적어도 일 실시예에서, VMM(506)은 마이크로-커널(micro-kernel)(512)과 서비스 OS(513)와 같은 소프트웨어 또는 펌웨어 성분의 실행을 통해 구현된다. 마이크로-커널(512)은 명령어 스케줄링과 같은 시스템 관리 과업을 위한 명령어의 더 작은 중심점을 포함하기도 한다. 서비스 OS(513)는 가상 머신을 생성하고 관리하기 위한 환경 가상화 소프트웨어와 장치 드라이버를 포함하기도 한다.
따라서, 도 5에 도시한 시스템(500)의 적어도 일 실시예에서, VMM 소프트웨어(506)는 하드웨어 자원(520)을 계속적으로 제어할 수 있고 VMM(506)에 대한 게스트로서의 게스트 OS(503a-503n)을 비특권화된 모드에서 실행할 수 있다. 소정의 게스트 이벤트, 명령어 그리고 시추에이션(situation)은 VMM(506)에 트랩될 수도 있고, VMM(506)은 이후 그러한 이벤트, 명령어 및/또는 시츄에이션을 조종할 수도 있다. 그에 따라 VMM(506)은 게스트 OS 소프트웨어(503a-503n)에 프로세서 추상화를 제공한다.
여기서 사용된 바와 같이, 게스트 OS(503a-503n)로부터 VMM(506)으로의 트랩은 여기서 VMEXIT으로 지칭한다. VMM(506) 제어로부터 게스트 OS(503a-503n)로 다시 전환하는 것을 여기서는 VMENTER로 지칭한다. VMM(506)과 게스트 OS 소프트웨어(503a-503n) 간의 전환은 가상 머신 제어 구조(Virtual Machine Control Structure : VMCS)(560)라 불리는 하드웨어 구조에 의해 제어되기도 한다. VMCS(560)은 게스트(예를 들어 503a-503n) 상태, VMM(506) 상태 그리고 다양한 제 어 레지스터의 상태를 VMM(506) 제어로 또는 그로부터의 전환에 따라 저장할 수 있다. 제어 레지스터 값은 어떤 게스트 이벤트가 VMM(506)에 트랩되고 어떤 상태가 VMEXIT와 VMENTER 전환 시에 로딩되고 저장되는지를 나타낼 수 있다.
적어도 일 실시예에서, VMM(506)은 VMEXIT와 VMENTER 전환을 위해 후속하는 처리를 수행한다. VMEXIT에 대해, 전환 이벤트를 생성한 게스트 OS(503)에 대한 상태 정보는 VMCS(560)의 게스트 상태 영역에 저장된다. VMENTER에 대해, 게스트 상태는 VMCS(560)의 게스트 상태 영역으로부터 복원된다. 적어도 일 실시예에서, VMM(506)은 특화된 리드(read) 및 라이트(write) 명령어를 사용하는 VMCS(560)의 필드를 판독하고 기록하기도 하는데, 이러한 명령어를 여기서는 각각 VMREAD 및 VMWRITE라고 한다.
VMCS(560)과 VMM(506)의 기본 기능은 SEL(402)를 VMM(506)의 일부로 구현하는 시스템의 적어도 일 실시예에서 사용될 수도 있다. 특정한 사용자-레벨 슈레드 생성, 제어 및 동기화 능력을 에뮬레이션하기 위해 VMM(506)을 사용하는 방법의 특정 예를 하기에서 설명한다.
시퀀서 격리
여기서 사용한 바와 같이, 다중-시퀀서 멀티스레딩 시스템의 하나 이상의 시퀀서가 격리 상태 또는 상황으로 전환했다는 것을 의미하기 위해 시퀀서 격리라는 용어를 사용한다. 그러한 격리 상태 또는 상황의 특징은 OS가 그러한 상태 또는 상황에서는 시퀀스에 대한 명령어를 스케줄링하지 않는다는 것이다. 따라서 소정 시간에 격리 상태에 있는 시퀀서를 하나 이상 가지는 시스템에서, 비격리된 시퀀스만이 OS에 "가시적"이라고 말한다. 임의의 소정 시간에, 하나 이상의 시퀀서가 격리되었는지에 따라, OS는 실제적으로 플랫폼에서 사용가능한 것보다 적은 수의 시퀀스에 대해 가시성을 가질 것이다. "가시적" 비격리된 시퀀서만이 OS-제어 스레드 실행에 사용가능하다. 슈레드는 격리된 (즉, "OS-비가시형") 시퀀서 상에서 사용자-레벨 명령어에 반응하여 실행될 것이다.
도 6은 시퀀서 격리의 적어도 일 실시예를 나타내는 블록도이다. 격리된 시퀀서들은 그럴 필요까지는 없지만 서로 대칭적이거나 OS-가시형 시퀀서와 대칭적일 수도 있음을 알아야 한다. 적어도 일 실시예에서, 하나 이상의 시퀀서(622, 624, 626)의 격리는 가상 머신에서의 게스트 OS와 같이 운영체계(603)의 부트(boot) 동안에 달성되기도 한다. 그러한 실시예에서, OS(603)에 대한 부트 파라미터(650)는 시스템(600)의 전체 시퀀서의 서브세트(예를 들어, 시퀀서(620))가 OS(603)에 가시적이 되도록 부트 전에 형성될 것이다.(적어도 일 실시예에서, 부트 파라미터는 운영체계 셋-업을 재구성하기 위해 루트(root) 특권을 갖는 시스템 운영자에 의해 형성될 것이다.) 적어도 일 실시예에서, VMM(506)은 OS(603)가 자신의 부트 프로세스를 완료한 후에 개시될 것이다.
양자택일적으로, 일 실시예에서 하나 이상의 시퀀서(622, 624, 626)의 격리가 달성될 수도 있는데, 여기서 VMM(506)은 OS(603) 이전에 개시된다. 그러한 실시예는 예를 들어 BIOS(basic input/output system) 또는 EFI(extensible firmware interface) 또는 하드웨어와 운영체계(603) 간의 인터페이스로서 작동하는 다른 펌 웨어를 통해 VMM(506)을 개시할 것이다. VMM(506)은 OS(603)에 대한 핸드오프(handoff) 전에 그러한 펌웨어에 의해 개시될 것이다. 격리를 달성하기 위해 OS의 부트 파라미터 파일을 사용하기보다는, OS(603)에 노출될 시퀀서의 개수는 운영체계(603)가 사용할 ACPI(advanced configuration and power interface) 테이블 내의 값에 의해 제어될 것이다.(다시, ACPI는 시스템 운영자 또는 부트 관리자(BIOS, EFI 등)의 벤더에 의해 프로그램될 것이다.)
단지 하나의 OS-가시형 시퀀서(620)만이 도 6에 도시되어 있는 있지만 이는 단지 예시적인 목적으로 도시한 것으로 한정적으로 사용되어서는 안 된다. 시스템(600)의 임의의 개수의 시퀀서가 운영체계(603)에 가시적일 수 있다. 많은 수의 공동 스레드를 효과적으로 관리하기 위한 운영체계(603) 능력의 한계는 시스템(600) 내의 전체 시퀀서 중의 얼마나 많은 수가 OS(603)에 가시적이어야 하느냐와 얼마나 많은 수가 격리되어야 하느냐에 대한 결정을 알려줄 것이다.
도 6은 VMM(506)이 OS(603)에 가시적인 시퀀서(620)를 포함하는 시스템(600)의 모든 시퀀서(620, 622, 624, 626)를 제어할 수도 있음을 보여준다. 격리된 시퀀서(622, 624, 626)가 운영체계(603)에 가시적이지 않다하더라도 그들은 VMM(506)의 직접 제어 하에서 동작한다. VMM(506)은 가시적 시퀀서(620)에 대한 게스트 모드에서 OS(603)을 운영할 것이다.
시퀀서 격리 모듈(404)은 사용자-레벨 명령어에 의해 정해진 바대로 스레드를 실행하도록 준비하기 위해 격리된 시퀀서(622, 624, 626)를 초기화하는 프로세싱을 수행할 것이다. VMM 개시 후에, 시퀀서 격리 모듈(404)은 격리된 시퀀 서(622, 624, 626) 각각에 초기화 명령어를 전달할 것이다.
격리된 시퀀서가 OS(603)에 가시적이지 않기 때문에, 그들 시퀀서는 운영체계(603)의 특권화된 링에 의한 서비스를 요구하는 특권화된 코드를 실행하지 않는다. 적어도 일 실시예에서, 특권화된 명령어(예를 들어, 시스템 콜 및 페이지 폴트 프로세싱(page fault processing))을 실행하기 위한 특정 시퀀서의 무능력은 이하에서 보다 상세히 논의될 투명 프록시 메커니즘에 의해 프로그래머로부터 마스킹(masking)될 것이다.
도 7은 도 4에 도시된 SEL(402)과 같이 슈레딩 에뮬레이션 계층을 포함하는 소프트웨어 계층을 개시하는 방법(700)의 적어도 일 실시예를 나타내는 흐름도이다. 적어도 일 실시예에서, SEL(402)은 VMM과 같이 보다 광범위한 소프트웨어 모듈의 일부로서 개시될 것이다. 방법(700)은 OS-가시형 시퀀서 상의 개시 드라이버에 의해 초기화될 것이다.
도 7은 블록(702)에서 시작해서 블록(704)으로 진행하는 방법(700)을 도시하고 있다. 블록(704)에서, 소프트웨어 계층의 이미지는 시스템의 메모리로 로딩(load)된다. 적어도 일 실시예에서, 이미지는 개시 드라이버에 의해 로딩될 것이다. 이후 프로세싱은 블록(706)으로 진행된다. 블록(706)에서, 소프트웨어 계층이 인보크(invoke)된다. 그 결과 제어는 개시 드라이버로부터 블록(704)에서 로딩된 SEL 이미지로 전달된다.
도 7은 블록(706)에서의 인보케이션(invocation)에 반응하여 SEL이 소정의 프로세싱(724-732)을 수행할 것임을 보여준다. 물론 프로세싱(724-732)이 필수적 으로 기술된 순서대로 실행될 필요는 없으며 몇몇 블록은 합쳐져서 보다 더 큰 매크로-블록으로 실행되거나, 양자택일적으로 더 작은 서브-블록으로 쪼개질 수도 있음을 알 것이다.
적어도 일 실시예에서, 도 7에 도시된 프로세싱(724-732)은 VMM과 같이 SEL(420)을 포함하도록 변형된 소프트웨어 계층에 의해 실행될 수도 있다. 도 7은 블록(724)에서 방법(700)이 초기화를 수행함을 보여준다. 초기화(724)는 VMXON 명령어의 실행을 포함할 수 있으며, 이 명령어는 시퀀서에서 사용가능한 VMX(Virtual Machine Extension) 특성을 턴-온시킨다. 초기화(724)는 또한 그 내부에서 VMM이 실행될 별도의 가상 어드레스 스페이스를 셋-업하는 것을 포함하기도 한다. 블록(724)으로부터 프로세싱은 블록(726)으로 진행된다.
블록(726)에서, 방법(700)은 OS로부터 격리된 시퀀서를 제어한다. 적어도 일 실시예에서, 그러한 제어는 스타트업(startup) 인터프로세서 인터럽트(또는 SIPI)를 격리된 시퀀스 각각에 전달함으로써 명백해진다. 이어서 프로세싱은 블록(726)으로부터 블록(728)으로 진행된다.
블록(728)에서, 격리된 시퀀스 각각은 스케줄러로부터의 업무를 기다리기 위해 대기 상태에 놓여진다. 그에 따라 업무는 슈레드 스케줄러(도시 안 됨)에 의해 격리된 시퀀서 상에서 스케줄링될 것이다. 슈레드 스케줄러는 예를 들어 런-타임 라이브러리(도시 안 됨)의 일부로서 동작할 것이다. 양자택일적으로, 슈레드 스케줄러는 SEL(도 4의 도면부호 420 참조)의 일부로서 동작할 것이다. 슈레드 스케줄러의 적어도 일 실시예에 대한 추가적인 상세화는 발명의 명칭이 "Mechanism to Schedule Threads on OS-Sequestered Sequencers without Operating System Intervention"인 동시 계류중인 미국 특허 출원____(대리인 서류 번호: 42390.P20205)에서 알 수 있을 것이다.
블록(728)으로부터, 프로세싱은 블록(730)으로 진행될 것이다. 블록(730)에서, 방법(700)은 OS-가시형 시퀀서에 대한 가상 메모리 제어 구조(VMCS)를 셋-업한다. 블록(730)에서 정해진 VMCS 값은 OS-가시형 시퀀스 상에서 예외가 발생할 때마다 VMM에 트랩을 일으키도록 조작될 것이다. 이어서 프로세싱은 블록(732)으로 진행된다.
블록(732)에서, 방법(700)은 초기에 SEL을 개시한(블록(706) 참조) 드라이버로 제어를 되돌리기 위해 VMENTER를 실행할 것이다. 전달(732)은 OS-가시형 시퀀서에 대한 OS에 효과적으로 제어를 부여한다. 적어도 일 실시예에서, 이러한 제 1 VMENTER가 개시에서 수행된 후에, OS-가시형 시퀀서에 대한 운영체계는 VMM의 상부에서 게스트로서 비특권화된 모드(이하에서 논의될 "0D")로 운영될 것이다. 이후 게스트 OS는 블록(708)에서 정상적인 프로세싱을 수행하도록 진행될 것이다. 방법(700)에 대한 프로세싱은 이어서 블록(710)에서 종료할 것이다.
당업자는 도 7의 블록들이 여기서 기술한 일반적인 기능을 유지하는 다양한 순서로 수행될 것임을 인식할 것이다. 예를 들어, 블록(726) 이후에 블록(728)이 실행되기 전에 블록(730 및 732)이 실행될 수도 있다.
도 8은 VMM(806)과 OS(803)가 개시된 이후에 예시적인 다중-시퀀서 시스템(800)의 OS-가시형 시퀀서(S0)와 격리된 시퀀서(S1)의 상태를 나타내는 블록도이 다. 도 8에 도시된 샘플은 두 개의 시퀀스(S0 및 S1)를 포함한다. 적어도 일 실시예에서, 시퀀스(S0, S1) 각각은 SMT 멀티스레딩된 프로세서(800)의 논리적 프로세서이다. 적어도 일 실시예에서, 시퀀서(S0, S1)는 다중-코어 멀티스레딩 시스템(800)에 대한 스레드를 동시에 실행할 수 있는 독립적인 프로세서 코어가 될 수도 있다. 여기서 기술한 모든 실시예에서, 기술된 기법은 도면에 기술된 것보다 더 많은 혹은 더 적은 수의 시퀀서를 포함하는 시스템 상에서도 실행될 수 있을 것이다.
도 8은 제 1 시퀀서(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 상에서 비특권화된 모드로 운영된다. 그러한 애플리케이션에 대한 비특권화된 링3 동작 모드는 명칭"3D"로 도 8에 도시되어 있다. 게스트 OS(803)의 커널 및 드라이버(812)는 운영체계(803)의 링 0에서 동작하지만 비특권화된 모드로 동작한다. 운영체계(803)에 대한 비특권화된 링 0 동작 모드는 명칭 "0D"로 도 8에 도시되어 있 다.
도 8은 OS(803)로부터 격리되어 VMM(806) 제어 하에 동작하는 시퀀서(S1)를 도시하고 있다. 도 8은 또한 VMM(806)이 특권화된 링 0 모드(P0)에서 동작함을 나타낸다. 소정의 특권화된 동작들은 그들이 OS-가시형 시퀀서(S0)에 의해 실행되려는 시도가 있으면 VMM(806)에 VMEXIT을 일으킬 수 있다. SEL(802)가 그러한 VMEXIT 프로세싱을 처리하는 것에 대한 추가 설명은 도 9 내지 도 13을 관련지어 이하에서 보다 상세히 기술한다.
시퀀서 연산
여기서 사용한 바와 같이, 시퀀서 연산이라는 용어는 두 개의 격리된 시퀀서 간의 제어의 사용자-레벨 전달을 지칭하기 위해 사용된다. SEL(도 4의 도면부호 402 참조)의 적어도 일 실시예에서, 동기식 및 비동기식 인터-시퀀서 제어 전달 능력 모두가 제공된다. 양자택일적인 실시예에서, 물론, 동기식 및 비동기식 인터-시퀀서 제어 전달 능력 중의 하나만이 제공될 수도 있다. 내재된 시퀀서 하드웨어가 그러한 능력에 대해 구조적 지원을 제공하는지에 상관없이 동기식 및/또는 비동기식 사용자-레벨 인터-시퀀서 제어 전달 능력이 SEL에 의해 제공될 수도 있다.
일반적으로, SEL의 동기식 제어 전달 특성은, 제 1 시퀀서에 의해 실행될 때 제 2 시퀀서로 전달될 신호를 생성하는 사용자-레벨 명령어에 의해 인보크될 것이다. 적어도 일 실시예에서, 여기서 VMCALL로 지칭되는 새로운 사용자-레벨 명령어는 SEL의 시퀀서 연산 능력을 인보크하기 위해 프로그래머에 의해 사용될 것이다. VMCALL 명령어의 파라미터는 다양한 종류의 시퀀서 제어 전달 시나리오를 달성하기 위해 사용자-레벨 애플리케이션에 의해 조작될 것이다.(그러한 인터-시퀀서 제어 전달 시나리오의 예시적인 샘플링이 이하의 표 1에서 설명된다.) 새로운 VMCALL 명령어를 사용하는 사용자-레벨 애플리케이션은 여기서 "슈레드-인지" 애플리케이션으로 지칭된다.
새로운 VMCALL 명령어의 적어도 일 실시예는 슈레드-인지 게스트 소프트웨어가 게스트 소프트웨어로부터의 VMEXIT을 VMM에 강요하는 것을 허락한다. 이어서 VMM은 격리된 시퀀서로의 신호전달을 관리한다. 표 1은 VMCALL 명령어의 사용자-레벨 애플리케이션의 사용에 의해 초기화되고 VMM에 의해 관리되는 신호전달 시나리오의 다양한 샘플 실시예를 설명하고 있다. VMCALL은 게스트 소프트웨어 제어로부터의 엑시트(exit)를 일으키기 때문에 표 1에 도시된 시나리오는 여기서 "이그레스(egress) 시나리오"로 지칭된다. 다른 실시예에서, 추가적인 또는 다른 이그레스 시나리오가 구현될 수도 있다.
표 1 - OS- 가시형 시퀀서로부터 격리된 시퀀스로 전달하기 위한 동기식 인터 -시퀀서 제어 전달용 이그레스 시나리오
Figure 112007055708130-PCT00001
여기서 슈레드 전달(SXFR) 능력으로 지칭되는 시퀀서 연산의 동기식 인터-시퀀서 제어 전달 특성은 시퀀서 간의 서비스에 대해 인터-슈레드 신호전달을 실행하기 위한 메커니즘을 제공한다. SXFR 능력은, 애플리케이션 프로그래머가 제어할 수 있다는 점에서, SXFR 능력을 인보크하기 위해 명령어를 슈레드-인지 코드에 신중히 위치시킴으로써 동기식이 되며, 제어 전달의 실행 타이밍은 신호를 생성하는 시퀀서의 슈레드 명령어 스트림 내의 다른 명령어의 실행과 관련된다. 여기서 사 용한 바와 같이, SXFR 능력에 대한 신호를 생성하는 시퀀서는 서번트(servant) 시퀀서로 지칭되고 생성된 신호의 수신자는 여기서 클라이언트 시퀀서로 지칭된다.
SXFR 능력은 새로운 VMCALL 명령어를 변형함으로써 사용자-레벨 애플리케이션에 의해 인보크될 것이다. VMCALL 명령어를 처리함에 있어서, VMM은 새로운 사용자-레벨 명령어를 관리하여 명령어들이 격리된 시퀀서에 의해 받아들여질 비동기식 제어 전달을 야기토록 할 것이다. VMM은 사용자-생성된 VMCALL 명령어의 결과로써 격리된 시퀀서에 전달될 제어 메시지를 생성할 것이다. 그러한 제어 메시지는 서번트 시퀀스가 VMM에 의해 관리되는 바와 같이 제어를 비동기식으로 받아들이게 만들 수도 있다. 그러한 비동기식 인그레스(ingress) 이벤트는 인터럽트 프로세싱과 유사하게 슈레드가 인커밍 이벤트를 처리하도록 만든다. 따라서 서번트 시퀀서는 인그레스 신호가 수신될 때 유휴 상태가 될 필요가 없다. 격리된 시퀀서에 의해 인그레스 시나리오 신호가 수신되는 시간에 슈레드가 격리된 시퀀서 상에서 현재 실행되고 있다면, VMM은 슈레드의 실행을 새로운 명령어 포인터 어드레스(EIP)로 다시 안내할 것이다. 상술한 바와 같이, 그러한 프로세싱은 슈레드 상의 실행을 새로운 EIP로 다시 안내하기 위해 실행되는 슈레드에 사용자-레벨 인터럽트를 전달하는 것과 유사하다.
신호가 슈레드로 하여금 VMM 제어 하에서 실행을 시작하도록 하기 때문에, 표 2에 기재된 시나리오는 여기서 "인그레스 시나리오"로 지칭된다. 다른 실시예에서, 추가적인 또는 다른 인그레스 시나리오가 구현될 수도 있다.
표 2 - OS- 가시형 시퀀서로부터 격리된 시퀀서로 전달하기 위한 비동기식 인터 -시퀀서 제어 전달용 인그레스 시나리오
Figure 112007055708130-PCT00002
그에 따라 VMM은 OS-가시형 및 OS-격리형 시퀀서 간의 슈레드 실행을 시작 및 정지하기 위해 표 1 및 2에 기술된 이그레스 및 인그레스 시나리오를 구현할 인터페이스를 제공한다. VMM이 OS-가시형 시퀀서 상에서 실행되는 슈레드-인지 프로그램으로부터 격리된 시퀀서로 인터-시퀀서 신호전달을 촉진하도록 VMCALL 명령어를 사용하는 방법(900, 1000)의 예시적인 실시예가 도 9 및 도 10에 기재되어 있다. 도 9는 새로운 어드레스에서 실행을 계속하도록 시퀀서를 안내하는 VMCALL 명령어의 변형을 처리하는 방법(900)의 적어도 일 실시예를 도시하고 있다. 도 10은 포크 동작을 실행하는 VMCALL 명령어의 변형을 처리하는 방법(1000)의 적어도 일 실시예를 도시하고 있다.
도 9는 SEL(950)을 통해 격리된 시퀀서로의 신호전달을 구현하기 위해 VMCALL 명령어의 변형을 실행하는 제어 흐름과 방법(900)의 적어도 일 실시예를 나타내는 흐름도이다. 그러한 변형은 예를 들어 이전에 일시 정지되고 그 다음 명령어의 것과는 다른 EIP에서 이제 재기되어야 하는 슈레드에 대해 사용될 것이다. 그러한 사용을 위해, 신호전달 변형은 도 12와 연관지어 이하에서 논의할 재기 메 커니즘의 변형으로써 개념화될 수도 있다. 그러한 변형은 또한 시퀀서 간의 임의의 다른 신호전달에 대해서도 사용될 수도 있다. 그와 같이, 도 9에 도시된 신호전달 변형은 표 1에 기술된 하나 이상의 이그레스 시나리오를 구현하기 위한 기본적인 메커니즘으로 사용될 수 있다. 도 9에 도시한 방법(900)은 SEL의 시퀀서 연산 모듈(예를 들어 도 4에 도시된 SEL(402)의 시퀀서 연산 모듈(408) 참조)에 의해 실행될 것이다.
도 9는 방법(900)이 격리된 시퀀서(n)의 실행을 하나의 명령어 포인터 어드레스(a)로부터 다른 어드레스(j)로 다시 안내할 것이다. 적어도 일 실시예에서, 방법(900)의 동작은 (VMM의 일부로 포함되었던 그렇지 않던) SEL(950)에 의해 실행될 것이다. 적어도 일 실시예에서, 방법(900)은 SEL(950)의 시퀀서 연산 모듈(도 4의 도면부호 408 참조)에 의해 실행될 것이다.
도 9는 VMCALL 명령어 실행방법(900)이 OS-가시형 시퀀서(m)가 VMCALL 명령어가 SXFR 능력을 수행하는 명령어임을 나타내기 위해 설정된 파라미터를 갖는 VMCALL 명령어를 실행(902)할 때 트리거될 것임을 보여준다. 특히, 도 9는 VMCALL 명령어가 동기식 제어 전달 명령어 종류인 "재 안내"를 나타냄을 보여주는데, 이 명령어는 별개의 격리된 시퀀서(n) 상의 슈레드가 새로운 EIP에서 다시 실행되도록 재 안내하는 것이다.
도 9는 시퀀서(n) 상의 VMCALL 명령어의 실행(902)이 VMEXIT을 생성하는 것을 보여주는데, VMEXIT은 시퀀서(m) 상에서 실행되는 게스트 OS(도시 안 됨)로부터 SEL(950)으로 트랩을 야기한다. 그러한 트랩에 반응하여, SEL(950)은 블록(910)에 서 방법(900)을 실행시키기 시작하고 프로세싱은 블록(912)으로 진행된다.
블록(912)은 실시예에서 실행되는데, 여기서 SEL(950)은 비동기식 인터럽트 이벤트를 격리된 시퀀서로 즉시 전달하지는 않을 것이다. 다른 실시예에서는 물론 비동기식 인터럽트는 즉시 전달될 것이며, 블록(912, 914 또는 916)을 실행하지 않고 블록(918)에서 시작할 것이다. 도 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)은 시퀀서(n) 상의 슈레드에 대한 "call" 명령어를 기능적으로 자극하여 명령어(j)에서 실행을 시작하도록 슈레드 스택을 조작한다. 그에 따라 VMM(950)은 시퀀서(n) 상의 슈레드가 새로운 EIP(j)에서 다시 시작하도록 만든다. 이어서 방법(900)에 대한 프로세싱은 블록(921)으로 진행된다. 블 록(921)에서 SEL(950)은 제어를 OS-가시형 시퀀서(m)로 리턴한다. 이어서 프로세싱은 블록(922)에서 종료한다.
도 9는 새로운 EIP(j)에서 실행을 시작하는 슈레드가 신호 서비스 루틴(970)에서 고려될 것임을 보여준다. 신호 서비스 루틴(970)은 리턴 명령어(972)와 함께 종료할 것이다. 리턴 명령어(972)의 시퀀서(n)에 의한 실행은 시퀀서(n) 상에서 인터럽트 되었던 EIP(a)의 재개로 끝날 것이다. 다양한 실시예에서 그러한 동작은 다양한 메커니즘에 의해 달성될 것이다. 예를 들어, 적어도 일 실시예에서 다음 동작이 리턴 명령어(972)에 반응하여 실행될 것이다. 리턴 명령어(972)의 실행에 따라 시퀀서(n)는 EIP 값의 스택을 팝-오프(pop off)할 것인데, 이 값은 블록(918)에서 SEL(950)에 의해 스택 상으로 강요되었다. 시퀀서(n)는 이어서 인터럽트 되었던 EIP(a)에서 프로세스를 재개할 것이다.
양자택일적으로, 다른 메커니즘이 인터럽트 되었던 EIP(a)에서 시퀀서(a)의 프로세스 재개를 위해 사용될 수도 있다. 적어도 하나의 대안적인 실시예에서, 스택을 팝핑(popping)하는 것은 포함되지 않는다. 대신, 또 다른 콜링 컨벤션(calling convention)이 사용될 것이다. 예를 들어, 그러한 하나의 대안적인 콜링 인벤션은 스택이 아닌 레지스터를 사용하는 리턴 메커니즘의 브랜치 및 링크 스타일(branch-and-link style)이다.
도 10은 SEL(1050)에 의해 제공될 수도 있는 시퀀서 연산 능력의 또 다른 실시예를 나타내는 제어 흐름도이다. 도 10은 포크 이그레스 시나리오를 구현하기 위해 VMCALL 명령어를 실행하는 것을 보여준다. VMM은 OS-가시형 시퀀서가 (새로 운 슈레드를 시작하기 위한) 신호를 격리된 시퀀서에 전달하도록 VMCALL 명령어의 이러한 특정한 변형을 처리한다. 다시, 도 10에 도시된 방법(1000)은 SEL의 시퀀서 연산 모듈(예를 들어 도 4에 도시한 바와 같은 SEL(402)의 시퀀서 연산 모듈(408) 참조)에 의해 수행될 것이다.
도 10은 VMM이 격리된 시퀀서와 연관된 새로운 명령어 포인터 어드레스에서 실행을 시작하도록 새로운 스레드의 실행을 안내할 것이다. 비록 도 10이 슈레드-인지 슈레드가 포크 명령어를 생성하는 실시예를 도시하고 있지만, 그러한 예는 한정적으로 여겨져서는 안 된다. 포크 명령어가 하나의 격리된 시퀀서에 의해 실행되어 또 다른 격리된 시퀀서 상에 슈레드를 야기시킬 수도 있음을 본 발명의 실시예들은 의도하고 있다.
도 10은 도 9에 도시된 재 안내(redirection) 대신에 또는 그에 추가하여 SEL(1050)이 인터-시퀀서 신호전달을 사용하여 포크 동작을 수행함으로써 OS-가시형 시퀀서(x) 상의 사용자-생성 명령어가 격리된 시퀀서(y) 상에 슈레드를 야기시킬 수도 있음을 보여준다. 앞서, 표 1에 기술한 바와 같이, 애플리케이션 프로그래머는 포크 이그레스 시나리오를 위한 VMCALL명령어를 OS-가시형 시퀀서(x) 상에서 실행되는 슈레드-인지 애플리케이션 내로 배치시킬 것이다.
OS-가시형 시퀀서(x) 상에서 동작하는 슈레드-인지 프로그램이 VMCALL 명령어(도 10에서 EIP "t"에서의 명령어로서 도시되어 있음)의 "포크" 변형을 실행시킬 때, 그 명령어에 특화된 "포크" 이그레스 시나리오는 SEL(1050)으로 제어를 전달한다. 도 10의 1002에서 포크 명령어의 실행을 초기화한다. 도 10은 VMCALL 명령어 에 대한 포크 변형의 적어도 일 실시예가, 야기된 스레드가 실행(u)을 시작해야하는 EIP와 새로운 슈레드를 위해 예약된 스택 스페이스를 나타내는 지정자(스택)를 알려준다. 선택적인 파라미터로서, 애플리케이션 프로그래머는 새로운 슈레드가 실행될 격리된 시퀀서(y)를 지정한다. 양자택일적으로, 애플리케이션 프로그래머는 그러한 배치 기능을 SEL(1050)에게 맡긴다. SEL(1050)은 예를 들어 순차 실행(round-robin) 배치 정책에 따라 새로운 슈레드를 위해 격리된 시퀀서를 배치할 것이다.
OS-가시형 시퀀서(x)가 VMCALL 명령어를 포크 가변 실행한 결과로써 제어의 결과적인 전달을 도 10에서는 VMEXIT이라고 지칭한다. VMEXIT에 반응하여, SEL(1050)은 포크 동작을 수행하기 위해 방법(1000)의 실행을 시작한다.
도 10은 블록(1010)에서 시작해서 블록(1012)으로 진행되는 방법(1000)을 도시하고 있다. 블록(1012)에서, SEL(1050)은 슈레드에 대해 격리된 시퀀서(y)를 배치하고 할당된 시퀀서(y)에 대해 실행(1002) 환경을 생성한다. 적어도 일 실시예에서 실행 환경은 다음과 같은 방법으로 블록(1012)에서 생성된다. 이하에서 제공되는 예는 단순히 WINDOWS 운영체계의 특징을 예시적인 목적으로 사용하는 하나의 실시예라는 것을 이해해야 한다. 그러나 다른 실시예는 다른 또는 추가적인 구조를 사용하는 새로운 슈레드에 대한 실행 환경을 생성할 수도 있다.
시퀀서(x)에 대한 VMCS(1080)로부터의 게스트 상태 면적은 시퀀서(x) 상에서 슈레드-인지 애플리케이션을 실행하기 위해 운영체계에 의해 셋업된 상태의 스냅 샷(snap shot)을 포함한다. 그러한 게스트 상태는 CR3과 같은 제어 레지스터에 대 한 값뿐만 아니라 글로벌 디스크립터(descriptor) 테이블 레지스터("GDTR")와 세그먼트 레지스터에 대한 값을 포함할 수도 있다. 블록(1012)에서 VMCS(1080)에 반영된 같은 시퀀서(x)에 대한 게스트 상태는 SEL(1050)에 의해 복사되어 격리된 시퀀서(y)와 연관된 VMCS(1082) 내의 상태를 셋업시키는데, 이 격리된 시퀀서는 VMCALL 포크 명령어에서 확인된 바와 같이 새로운 슈레드를 실행시키기 위해 SEL(1050)에 의해 배치되었다.
따라서 SEL(1050)은 시퀀서(x)를 야기하는 게스트 상태를 사용하여 시퀀서(y)에 대한 게스트 상태를 증가, 즉, 새로운 슈레드를 실행시킨다. 그에 따라, 블록(1012)에서, SEL(1050)은 격리된 시퀀스를 위한 실행 환경을 생성하는 목적을 달성할 수 있을 것이다. 이 환경은 시퀀서(x) 상에서 슈레드-인지 애플리케이션을 실행시키기 위해 운영체계에 의해 세팅된 실행 환경을 모방한 것이다.
이어서 SEL(1050)은 VMCALL 포크 명령어의 파라미터를 사용하여 격리된 시퀀서(y)를 위해 VMCS(1082) 내의 격리된 시퀀서 상태를 수정한다. 블록(1012)에서 격리된 시퀀서(y)에 대한 게스트 EIP는 VMCS(1082)에서 수정되어 VMCALL 포크 명령어에서 지정된 EIP(u)를 반영할 수도 있다. 유사하게, 블록(1012)에서 SEL(1050)은 또한 VMCS(1082) 내의 게스트 스택 포인터를 수정하여 VMCALL 포크 명령어에서 지정된 스택 포인터 값 "스택(stack)"을 반영할 수도 있다. 블록(1012)에서, SEL(1050)은 또한 격리된 시퀀서(y)를 위한 VMCS(1082) 내의 플래그(flag)를 수정하여 모든 마스크가능 인터럽트가 슈레드 실행 동안에 블로킹될 것임을 나타낼 것이다.
(EIP, 스택 포인터 그리고 인터럽트 플래그와 같은) 이러한 수정된 값을 제외하고, OS-가시형 슈레드-인지 시퀀서(x)를 위한 VMCS(1080) 내의 게스트 상태는 격리된 시퀀서(y)를 위해 블록(1012)에서 생성된 (VMCS(1082) 내에 반영된 바와 같은) 게스트 상태와 동일하다. 이어서 프로세싱은 블록(1014)으로 진행된다.
블록(1014)에서, SEL(1050)은 슈레드가 실행될 콘텍스트에 스레드를 기록한다. 적어도 하나의 WINDOWS-기반 실시예에서, SEL(1050)은 그렇게 하기 위해 OS-할당 슈레드 id를 사용한다. 적어도 일 실시예에서 (x와 같은) OS-가시형 시퀀서에 의해 생성된 모든 슈레드가 OS-가시형 시퀀서와 같은 가상 메모리의 뷰에서 공유되기 때문에 OS-가시형 시퀀서에 대한 스레드 id 값은 블록(1014)에서 기록되어 (y와 같은) 격리된 시퀀서에 대한 새로운 슈레드가 실행될 콘텍스트에서의 프로세스를 확인한다. 이어서 프로세싱은 블록(1016)으로 진행된다.
블록(1016)에서, SEL(1050)은 OS-가시형 시퀀서(x)에 대한 게스트 OS가 OS-가시형 시퀀서(x) 상에서 슈레드-인지 애플리케이션의 실행을 재개하도록 하며, 적어도 일 실시예에서, 이는 VMRESUME 명령어를 실행시킴으로써 달성되는데 이로써 제어는 OS-가시형 시퀀서(x)에 대한 게스트 OS로 다시 전달된다. 또한, SEL(1050)은 VMENTER 동작을 수행하여, 블록(1012)에서 생성된 실행 환경에서 격리된 시퀀서(y) 상에서 슈레드의 코드의 실행을 시작한다.
VMENTER에 따라, 메모리의 격리된 시퀀서(y)의 뷰는 시퀀서(x)의 것과 동일한데, 이는 두 시퀀서가 각각의 대응하는 VMCS(1080, 1082)에서의 게스트 모드 실행을 위해 동일한 GDT 및 CR3 레지스터 값과 연관되어 있기 때문이다. 당업자는 GDT 및 CR3 레지스터 값이 대응하는 시퀀서(x, y)에 의한 실행 동안에 가상 어드레스가 물리적 어드레스로 변환되는 방법에 영향을 미친다는 것을 알게 될 것이다.
도 10은, 방법(1000)을 수행함으로써, SEL(1050)이 상기 표 2에 기술된 고_슈레드 인그레스 시나리오와 유사한 비동기식 인그레스 시나리오를 효과적으로 구현함을 보여준다. 격리된 시퀀서(x)에 대한 인그레스 시나리오는 슈레드-인지 애플리케이션 내의 사용자-공급 VMCALL 포크 명령어에 반응하여 수행될 것이다. 도 10은, 방법(1000)의 다른 블록(1010-1014)을 수행한 후, SEL(1050)이 블록(1016)에서 슈레드 코드의 실행을 시작하고 격리된 시퀀서(y)를 위해 셋업된 실행 환경이 OS-제어된 시퀀서(x)를 위해 운영체계에 의해 셋업된 것과 가상적으로 동일하다는 것을 보여준다. 이러한 방식으로, SEL(1050)에 의한 방법(1000)의 실행은, 포크 동작을 위해, 도 1 및 2와 관련지어 앞서 논의한 공유 메모리 병렬 다중-프로세싱 패러다임을 효과적으로 달성한다.
도 9 및 10은 소프트웨어 에뮬레이션 계층의 적어도 일 실시예에 대한 시퀀서 연산 능력의 특정한 예를 보여주기 위해 제공된다. 그러한 예는 한정적으로 여겨져서는 안 되며, SEL(1050)은 많은 다른 시퀀서 연산 능력을 제공할 수 있다.
사용자-레벨 예외 핸들링
여기서 기술한 메커니즘의 적어도 일 실시예에서, 격리된 시퀀서 상에서의 사용자-레벨 슈레드 명령어의 실행은 OS-가시형 시퀀서 또는 격리된 시퀀서 상에서의 슈레드 실행 동안에 링 전환에 따라 잠시 중지되어야 한다. 링 전환은 OS-가시 형 시퀀스 또는 격리된 시퀀서 상에서 생성된 예외, 인터럽트 또는 시스템 콜에 반응하여 종종 생성된다. OS-가시형 시퀀서 상에서의 링 전환을 위해, 잠시 중지된 슈레드의 실행은 인터럽트/예외/시스템 콜이 OS에 의해 핸들링된 후에 재개될 것이며, 이어서 OS는 계속된 실행을 위해 슈레드-인지 애플리케이션을 스케줄링한다. 적어도 일 실시예에서, 도 10 및 11과 연결지어 이하에서 논의되는 슈레드 중지 및 재개 방법은 전환 검출 모듈에 의해 실행될 것이다(예를 들어, 도 4에 도시한 바와 같은 SEL(402)의 전환 검출 모듈(410)을 참조하라).
도 11은 링 전환에 기인한 슈레드 일시 정지에 대한 메커니즘의 적어도 일 실시예를 나타내는 제어 흐름도이다. 도 11에 도시된 메커니즘은 링 3에서 링 0으로의 전환이 OS-가시형 시퀀서(c) 상에서 일어날 때 격리된 시퀀서(d) 상에서 슈레드 실행을 일시 정지하는 특정 예와 관련지어 제공된다. 물론, 당업자는 링 3에서 링 0으로의 전환이 OS-격리형 시퀀서 상에서 일어날 때에 유사한 일시 정지 로직이 사용될 수 있음을 알게 될 것이다(이하의 프록시 메커니즘의 설명을 참조하라).
도 11에 도시된 일시 정지 메커니즘의 적어도 일 실시예에서, 3 단계의 동작을 보여준다. 첫 번째 단계(1110)에서 초기화가 수행된다. 그러한 초기화(1110)는 SEL(1150)에 의해 실행될 것이다. 적어도 일 실시예에서, 예외에 기인한 링 3으로부터 링 0으로의 전환이 예외로 기록될 것이고 그에 따라 VMEXIT이 생성될 것임을 알려주기 위해 초기화(1110)가 수행된다. 그러한 초기화(1110) 동안에, OS-가시형 시퀀서(c) 상에서의 스레드 실행 동안에 링 3에서 링 0으로의 전환에 기인한 예외가 발생할 때마다 SEL(1150) 제어에 대한 전환이 발생하도록 제어 구조가 형성된다.
적어도 일 실시예에서, OS-가시형 시퀀서(c)에 대한 VMCS(1180)의 예외 비트맵에서 원하는 시스템 이벤트(시퀀서(c) 상에서의 예외에 기인한 링 3으로부터 링 0으로의 전환)에 대한 예외 비트를 세팅함으로써 초기화(1110)가 수행될 것이다. 단지 하나의 OS-가시형 시퀀서(c)와 그와 연관된 VMCS(1180)이 도 11에 도시되어 있다 하더라도 초기화(1110)가 다수의 OS-가시형 시퀀서에 대해서도 수행될 수 있음을 알아야 한다.
SEL(1150)이 VMM의 일부분인 실시예에서, 초기화(1110)는, 시퀀서(c) 상의 예외에 의해 링 전환이 발생하는 것에 반응하여 VMEXIT(VMM으로 제어 전달)을 생성하도록 VMCS(1180)의 예외 비트맵을 사용하는 메커니즘을 발효시킨다.
물론, 인터럽트나 시스템 콜과 같은 다른 종류의 시스템 이벤트가 OS-가시형 시퀀서(c)에 대한 슈레드 프로세싱 동안에 발생할 수도 있다. 또한 초기화(1110)는 OS-가시형 시퀀서(c) 상에서의 OS 핸들링을 필요로 하는 인터럽트 또는 시스템 콜 또는 다른 시스템 이벤트의 발생에 반응하여 VMEXIT을 발생시킨다. 적어도 일 실시예에서, 인터럽트, 시스템 콜 등에 대한 초기화(1110)는 트램폴린(trampoline) 메커니즘을 통해 구현될 수도 있다. 트램폴린 메커니즘은 게스트 OS로부터 제 1 "바운스(bounce)" 상의 제어를 간단히 받아들여 "바운싱"제어가 게스트 OS로 되돌아가기 전에 소정의 슈레드 일시 정지 동작을 수행한다.
인터럽트를 위한 트램폴린 메커니즘의 실시예에서, 게스트 OS가 동작할 때에 인터럽트가 발생하기만 하면 SEL(1150)이 제어를 갖도록 인터럽트의 호스트 제어에 대한 메커니즘을 구성할 수도 있다. 적어도 일 실시예에서, SEL(1150)은 초기화(1110) 동안에 특정한 드라이버를 인보크할 것이다. 이러한 드라이버는 인터럽트와 시스템 콜을 핸들링하기 위해 OS-가시형 시퀀서의 게스트 OS에 의해 사용된 소정의 세팅을 변경할 수도 있다.
범용성을 잃지 않고도, 트램폴린 메커니즘을 구성하는 특정 예가 제공된다. 그러나 그러한 예는 어떠한 점에서도 한정적으로 사용되어서는 안 되는데, 이는 그러한 구성이 여러 가지 다른 방식 중의 어떠한 것으로도 달성될 수 있기 때문이다. 적어도 일 실시예에서, 드라이버는 초기화(1110) 동안에 인터럽트 디스크립터 테이블(IDT)을 변경할 수도 있다. 그러한 변경은 시스템 콜 및 인터럽트와 연관된 하나 이상의 인터럽트 서비스 루틴(ISR)과 연관된 IDT 내의 오프셋을 변경할 것이다. 변경된 오프셋은 인터럽트 또는 시스템 콜과 연관된 ISR이 실행되기 전에 VMCALL이 생성되도록 만들 것이다. 따라서 초기화(1110) 동안에 IDT에 가해진 변경은 인터럽트 또는 시스템 콜이 OS-가시형 시퀀서(c) 상에서 발생할 때 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의 변경)으로 SEL(1150)에 제어를 "바운스"하게 될 것이다. 달리 말하면, 그러한 초기화(1110)는 SEL(1150)에 시스템 콜이 트랩되도록 만들 것이다.
마지막으로, 블록(1110)에서의 초기화는 또한 시퀀서(d)와 같은 OS-격리형 시퀀서의 초기화를 포함할 수도 있으며, 그 결과 그러한 시퀀서는 마스크불가능 인터럽트(non-maskable interrupt : NMI)를 수신할 때는 언제든지 SEL(1150)에 트랩될 것이다(블록(1104)과 연결된 하기 추가 논의를 참조하라). 그러한 초기화는 격리된 시퀀서(d)와 연관된 VMCS(1182)에 대한 예외 비트맵을 수정함으로써 실행될 것이며, 이는 NMI가 수신될 때 SEL(1150) 제어에 대한 전환이 일어나야함을 나타낸다.
도 11은 두 번째 단계(1120)가 OS-가시형 시퀀서(c)에 의해 실행될 수도 있음을 보여준다. OS-가시형 시퀀서(c) 상에서의 스레드의 실행 동안에, 시퀀서는 링 3으로부터 링 0으로의 전환에 기인한 예외를 생성하거나 OS 서비스를 필요로 하는 시스템 콜, 인터럽트 또는 다른 시스템 이벤트에 직면할 것이다. 앞서 논의한 초기화(1110)로 인해, 그러한 이벤트의 생성은 시퀀서(c)에 대한 게스트 OS가 해당 이벤트를 즉시 핸들링하도록 허락하기보다는 SEL(1150) 제어에 대한 VMEXIT-타입 전환을 일으킬 것이다. SEL(1150)이 VMM의 일부가 되는 실시예에서, 두 번째 단계(1120) 동안에 생성된 전환(1101)은 VMEXIT로 불릴 수도 있다.
도 11은 VMEXIT-타입 전환에 따라, 제어가 SEL(1150)로 전달됨을 보여준다. 세 번째 단계(1130) 동안에, SEL(1150)은 슈레드 일시 정지를 위한 방법(1100)을 수행한다. SEL(1250) 로직이 VMM에 포함되는 실시예에서, 방법(1100)은 VMM에 의해 실행될 것이다.
도 11은 게스트 OS가 OS-가시형 시퀀서(c) 상의 이벤트를 핸들링하도록 허락하기 전에 OS-가시형 시퀀서(c) 상의 시스템 이벤트에 의해 트리거된 VMEXIT(1101)에 반응하여 SEL(1150)이 방법(1100)을 실행함을 보여준다. 이러한 메커니즘은 적어도 하기와 같은 이유로 도입될 수 있다. 그 이유는 게스트 OS가 격리된 슈레드를 인지하지 못하여 게스트 OS의 임의의 커널 모드 코드가 OS-가시형 시퀀서 상에서 실행되는 동안에 슈레드가 계속적으로 실행되지 말아야 한다는 것이다.
도 11은 방법(1100)이 블록(1102)에서 시작하여 블록(1104)으로 진행함으로 보여준다. 블록(1104)에서 SEL(1150)은 인터럽트를 하나 이상의 OS-격리형 시퀀서(d)에 전달하며, 이때 이러한 시퀀서는 OS-가시형 시퀀서(c)에 의해 실행된 슈레드-인지 코드와 연관된 코드를 운영하고 있다. 도 11은 단지 하나의 격리된 시퀀 서(d)를 도시하고 있다. 그러나 당업자는 블록(1104)에서 인터럽트가 다수의 격리된 시퀀서에 발행될 수도 있음을 알게 될 것이다. 적어도 일 실시예에서, 블록(1104)에서 발행된 인터럽트는 마스크불가능 인터럽트이고, 이러한 인터럽트는 수신 시퀀서에 의해 무시될 수 없다. 하나의 예에서 SEL(1150)은 어드밴스 프로그래머블 인터럽트 제어기(Advanced Programmable Interrupt Controller : APIC)를 프로그래밍 함으로써 인터럽트가 블록(1104)에서 발행될 수 있도록 한다.
블록(1104)에서 인터럽트가 전달되도록 함으로써, SEL(1150)은 효과적으로 격리된 시퀀서(d) 상에서 슈레드 실행의 비동기식 일시 정지를 트리거하고 그에 따라 "일시 정지" 슈레드 제어 명령어를 에뮬레이션한다. 블록(1104)에서의 인터럽트의 트리거링은 표 2에 기재한 바와 유사한 격리된 시퀀서(d)에 대한 홀트_슈레드 인그레스 시나리오를 달성한다. SEL(1150)은 블록(1104)에서 발행된 인터럽트에 기초하여 블록(1106)에서 격리된 시퀀서(d)로부터의 제어 전환을 기다린다.
도 11은 블록(1104)에서 생성된 인터럽트가 OS-비가시형 시퀀서(d)에 의해 수신될 수 있으며, 이어서 격리된 시퀀서(d)에 대해 SEL(1150) 제어로의 전환(1105)을 일으킬 것이다. 다시, SEL(1150) 로직이 VMM에 포함되는 실시예에서, 그러한 전환(1105)은 VMEXIT으로 지칭될 수도 있다(블록(1104)에서 더 많은 격리된 시퀀서에 인터럽트가 발행되었다면, 다수의 시퀀서 각각은 VMEXIT을 생성할 것이며, 후속 블록(1108 및 1110)은 다수의 격리된 시퀀서 각각에 대해 실행될 것이다).
블록(1104)에서 발행된 인터럽트에 의해 야기된 OS-격리형 시퀀서(d)로부터 의 VMEXIT(1105)에 반응하여, SEL(1150)은 블록(1106)에서 전환을 검출한 후 블록(1108)을 실행한다. 블록(1108)에서, SEL(1150)은, 시스템 이벤트가 OS-가시형 시퀀서(c)의 게스트 OS의 이벤트 핸들러 루틴에 의해 핸들링된 후에 슈레드의 재개를 준비하도록 프로세싱을 실행한다. 그렇게 하기 위해, SEL(1150)의 적어도 일 실시예는 코드 정지점(breakpoint)을 활용한다.
따라서 블록(1108)에서, SEL(1150)은, 원래 시스템 이벤트가 트리거된 명령어에 대한 EIP 명령어 어드레스(t)에서 OS-가시형 시퀀서(c)에 대한 코드 정지점을 셋업하기 위해 하나 이상의 디버그(debug) 레지스터(DR)에서 코드 정지점을 세팅할 것이다. OS-가시형 시퀀서(c)에 대한 게스트 OS가 시스템 이벤트를 핸들링한 후, EIP(t)에서 슈레드-인지 스레드의 실행을 시작하고 그에 따라 시스템 이벤트가 핸들링된 후에 정지점을 트리거할 것이라고 가정한다(정지점 프로세싱의 추가 논의는 이하에서 도 12와 슈레드 재개 메커니즘의 논의를 연결지어 설명될 것이다). 적어도 일 실시예에서, 정지점 메커니즘은 정지점이 게스트 OS에 가시적이 않은 OS-가시형 시퀀서(c)의 게스트 OS에 대해 투명한 방법으로 SEL(1150)이 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)가 도 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)을 생성하는 스레드와 연관된 스레드 식별자가 일시 정지된 슈레드와 연관된 스레드에 대한 스레드 식별자와 일치함을 승인한다. 적어도 일 실시예에서, 그러한 인증(1204)은 OS-가시형 시퀀서(c)에 대한 VMCS(1280)의 게스트 영역에서의 스레드 식별자(예를 들어, CR3 레지스터 값)와 격리된 시퀀서(d)에 대한 VMCS(1282)의 게스트 영역에서의 스레드 식별자 값(예를 들어 CR3 레지스터 값)을 비교함으로써 수행된다. 그 값들이 일치하면, 프로세싱은 블록(1206)으로 진행된다. 그렇지 않으면, 전환(1201)은 "폴스 히트(false hit)"에 기인하여 생성되고 프로세싱은 블록(1210)으로 진행된다.
블록(1206)에서, SEL(1250)은 이전에 도 11의 블록(1108)에서 디버그 레지스터 내에 세팅된 정지점 값을 제거(clear)한다. 이어서 프로세싱은 블록(1208 및 1209)으로 진행되고, SEL(1250)은 OS-가시형 스레드와 OS-비가시형 슈레드 모두에 대한 제어를 내준다(반드시 도시된 순서대로는 아님). 이어서 프로세싱은 블록(1214)에서 종료한다.
블록(1210)에서, EIP(t)에서의 명령어는 싱글-스텝(single-step)으로 처리된다(시퀀서(c)에 의해 다음 명령어가 실행된 후에 예외가 생성되어야 함을 명확히 하기 위해 EFLAGS 지정자와 같은 예외 지정자의 변형을 포함할 수도 있다.). 이어서 프로세싱은 블록(1212)으로 진행된다. 블록(1212)에서, 도 11의 블록(1108)에서 생성된 디버그 레지스터의 정지점 세팅이 제거된다. 이어서 프로세싱은 블록(1213)으로 진행되고, 여기서 OS-가시형 시퀀서에 대한 게스트 OS에 제어를 내 준다. 다음으로 방법(1200)의 프로세싱은 블록(1214)에서 종료한다.
적어도 일 실시예에서, 재개 메커니즘의 추가 단계(도시 안 됨)는 "폴스 히트"에 대한 프로세싱 동안에 블록(1213)에서 OS-가시형 시퀀서에 제어를 내준 후에 실행될 수도 있다. 즉, 게스트 OS가 블록(1213)의 결과로서 제어를 취한 후에, 그 다음 명령어를 실행할 것이다. 블록(1210)에서 셋업된 단일-스테핑(single-stepping)에 의해 게스트 OS는 다시 하나의 명령어가 실행된 후에 예외를 경험할 것이다. 이러한 예외를 처리하는 동안에 SEL(1210)은 디버그 레지스터를 다시 세팅하여, OS-가시형 시퀀서 상의 슈레드에 의해 지정된 EIP가 실행되는 다음 시간에 슈레드 처리를 재개하려는 시도를 행하는 방법(1200)을 실행할 수 있다.
프록시 실행
여기서 사용한 바와 같이 프록시 실행이라는 용어는 인터-시퀀서 슈레드 이동-격리된 시퀀서로부터 OS-가시형 시퀀서로의 상태 정보 및 제어의 전달-을 지칭하며, 그 결과 OS-가시형 시퀀서는 격리된 시퀀서를 위해 특권화된 동작을 수행하기 위해 운영체계를 트리거할 수도 있다. 프록시 실행은 그로 인해 OS-가시형 시퀀서가 격리된 시퀀서 상의 슈레드를 실행하는 동안에 일어나는 시스템 이벤트를 핸들링하기 위해 운영체계의 관심을 얻을 수도 있는 수단이다. 비대칭적인 시퀀서를 포함하는 시스템 상에서 애플리케이션 프로그래머에게는 구조적으로 대칭인 것처럼 보이게 하는데 프록시 실행을 활용할 수도 있다. 프록시 실행을 추가적으로 설명하기 위해 도 13을 참고한다.
도 13은 하나 이상의 격리된 시퀀서(b)와 하나 이상의 OS-가시형 시퀀서(a)를 포함하는 다중-시퀀서 시스템에서의 프록시 실행 메커니즘의 적어도 일 실시예를 나타내는 제어 흐름도이다. 도 13에 도시한 바와 같은 프록시 실행의 적어도 일 실시예에서, OS-가시형 시퀀서(a)를 위한 게스트 OS가 격리된 시퀀서(b) 상에서 실행되는 슈레드를 인지하지 못한다고 가정한다. 또한 격리된 시퀀서(b) 상에서 행해지는 슈레드가 OS 서비스를 요구하는 특권화된 명령어를 실행할 수 없다고 가정한다. 적어도 일 실시예에서, 도 13에 도시한 방법(1300)은 SEL의 프록시 실행 모듈에 의해 수행될 수도 있다(도 4에 도시한 바와 같은 SEL(402)의 모듈(406)을 참고하라).
일반적으로, 도 13은 OS-가시형 시퀀서(a)가 페이지 폴트, 시스템 콜 등과 같은 운영체계로부터의 소정의 서비스 형태를 요구하는 이벤트를 핸들링하기 위해 슈레드를 구현하는 것에 관한 실시예를 도시하고 있다. 이러한 방식으로, 운영체계는 슈레드 실행 동안에 발생한 시스템 이벤트를 서비스하기 위해 트리거된다.
설명을 위해, 도 13은 슈레드에 의해 생성된 페이지 폴트를 핸들링하기 위해 프록시 실행을 활용하는 방법을 보여준다. 그러나 당업자는 도 13에 도시된 방법(1300)의 대안적 실시예가 슈레드를 대신하여 임의의 예외, 인터럽트, 시스템 콜 또는 다른 특권화된 이벤트 및/또는 시스템 이벤트를 핸들링하기 위해 활용될 수도 있음을 알게 될 것이다.
도 13에 도시한 프록시 메커니즘의 적어도 일 실시예에서, 3 단계의 동작을 예시한다. 제 1 단계(1310)에서 초기화가 실행된다. 초기화(1310)는 SEL(1350)에 의해 수행될 것이다. 초기화(1310) 동안에, 격리된 시퀀서(b) 상에서 운영되는 슈레드가 선택된 형태의 시스템 이벤트에 직면하는 어느 시기에든 SEL(1350) 제어로의 전환이 발생할 수 있도록 제어 구조가 구성될 것이다. 초기화(1310)는 프록시 실행이 요구되는 페이지 폴트, 시스템 콜 등과 같은 여러 형태의 시스템 이벤트에 대해 실행될 수도 있다. 초기화(1310)의 결과, 선택된 이벤트 형태 중의 하나가 격리된 시퀀서(b) 상의 슈레드 실행 동안에 발행할 때마다, SEL(1350)은 제어를 가질 것이다. SEL(1350)이 VMM의 일부인 실시예에서, 초기화(1310)는 메커니즘으로 하여금 어떠한 선택된 시스템 이벤트가 발생할 때 VMEXIT(VMM으로의 제어의 전달)을 발생시키도록 만든다.
적어도 일 실시예에서, 초기화(1310)는 격리된 시퀀서(b)에 대한 VMCS(1382) 내에 각각의 필요한 시스템 이벤트에 대한 예외 비트를 세팅함으로써 실행될 수도 있다. 도 13에 단지 하나의 격리된 시퀀서(b)와 그와 연관된 VMCS(1382)만이 도시되어 있지만, 다수 개의 격리된 시퀀서에 대해서 초기화(1310)가 실행될 수도 있음을 알아야 한다.
도 13은 제 2 단계(1320)가 격리된 시퀀서(b)에 의해 실행될 수도 있음을 보여준다. 격리된 시퀀서(b) 상에서 슈레드를 실행하는 동안에, 시퀀서는 선택된 시스템 이벤트 중의 하나를 생성할 것이다. 시스템 콜에 응답하여, 슈레드에 대한 이벤트 핸들러(도시 안 됨)는 슈레드의 현재 상태를 획득한다. 이 현재 상태는 슈레드에 대한 현재 EIP와 시퀀서에 의해 생성되며 이벤트 핸들링 또는 식별을 촉진하는 임의의 에러 코드를 포함한다.(게스트 OS로서 WINDOWS 운영체계를 포함하는 실시예에서, 슈레드 상태를 획득하는 것은 시스템 이벤트를 발생시키는 명령어의 어드레스를 획득하기 위해 CR2 제어 레지스터의 값을 획득하는 것을 포함할 수도 있다.) 이벤트 핸들러는 이어서 SEL(1350) 제어에 대한 전환(1301)을 일으킬 수도 있다. SEL(1350)이 VMM의 일부인 실시예에서, 제 2 단계(1320) 동안에 생성된 전환(1301)을 VMEXIT으로 지칭할 수도 있다.
다음으로 제 2 단계(1320) 동안에, (VMEXIT과 같은) SEL(1350) 제어에 대한 전환은 선택된 시스템 이벤트 중의 하나가 발생할 때 트리거된다. 이러한 전환(1301)은 시퀀서의 VMCS(1382) 내의 시퀀서(b)에 대한 초기화(1310) 동안에 예외 비트 세트에 따라 트리거될 것이다.
도 13은 VMEXIT-타입 전환(1301)에 따라 제어가 SEL(1350)으로 전달되는 것을 보여준다. 제 3 단계(1330) 동안에, SEL(1350)은 프록시 실행 방법(1300)을 수행한다. 일반적으로, 방법(1300)은 a) OS-가시형 시퀀서 상에서 운영되는 OS-가시형 스레드의 상태를 획득하는 단계, b) 이벤트-생성 슈레드로부터의 상태를 OS-가시형 시퀀서로 전달하는 단계, c) 격리된 시퀀서 상에서 발생한 이벤트를 (가능하다면) OS-가시형 시퀀서 상에서 재생할 수 있도록 OS-가시형 시퀀서에 제어를 전달하는 단계, 그 결과 d) 운영체계가 이벤트를 서비스하는 단계, e) SEL 제어를 재개하고 OS-가시형 시퀀서의 원래 상태를 복원하는 단계, 그리고 f) OS-가시형 및 격리된 시퀀서 모두에 대해 원래 실행 스트림을 계속하는 단계를 포함한다. 방법(1300)의 이러한 각각의 요소는 이하에서 보다 구체적으로 논의한다.
양자택일적인 실시예에서, SEL(1350)은 방법(1300)을 수행하기보다는 사용자 -생성 에러-핸들링 루틴을 수행하기 위해 단순히 이벤트를 트랩한 후 이전에 할당된 어드레스로 점프하게 될 것이다. 그러한 양자택일적인 실시예에서, 방법(1300)의 기능들은 SEL(1350)에 의해서가 아니라 사용자-생성 에러-핸들링 루틴에 의해 실행될 것이다.
도 13은 방법(1300)이 블록(1302)에서 시작하여 블록(1304)으로 진행되는 것을 보여준다. 블록(1304)에서, SEL(1350)은 격리된 시퀀서(b)로부터 OS-가시형 시퀀서(a)로의 슈레드 상태 전달을 준비한다. 적어도 일 실시예에서, 그러한 준비 단계(1304)는 OS-가시형 시퀀서(a)도 액세스할 수 있는 상태 저장 영역(1315)(영역 "b" 참조)에 이벤트-생성 격리된 시퀀서(b)의 상태를 저장하는 것을 포함한다. 저어도 일 실시예에서, 그러한 동작은 SEL(1350)에 의해 실행된 VMCALL 명령어의 특정 콘텍스트 상태 스토리지 변형에 반응하여 실행될 수도 있다. 적어도 일 실시예에서, 여기서 SSAVE라 지칭되는 샘플 콘텍스트 상태 스토리지 변형은 시퀀서 식별자 및 포인터를 저장 영역(1315)에 지정한다.
슈레드 상태 전달을 위한 준비 단계(1304)는, 적어도 일 실시예에서, OS-가시형 시퀀서(a)의 상태를 저장하는 것을 더 포함하는데, 이 저장 동작은 이러한 시퀀서가 격리된 시퀀서의 상태를 채택하기 전에 이루어진다. 이러한 방식으로, OS-가시형 시퀀서(a)의 상태가 저장되고 이후에 OS-가시형 시퀀서(a)가 자체 스레드를 재개할 때 복원될 것이다. 다시, OS-가시형 시퀀서(a)에 대한 상태는 포인터를 저장 영역(1315)에 지정하는 콘텍스트 저장 명령어에 반응하여 저장 영역(1315)(영역 "a" 참조)에 저장될 것이다. 이어서 프로세싱은 블록(1304)으로부터 블록(1306)으 로 진행된다.
블록(1306)에서, 이벤트-생성 슈레드에 대한 제어는 격리된 시퀀서(b)로부터 OS-가시형 시퀀서(a)로 전달된다. 적어도 일 실시예에서, 전달 단계(1306)는 SEL이 VMCALL 명령어의 프록시 변형을 실행함으로써 트리거될 OS-가시형 슈레드에 대한 인그레스 시나리오의 수행을 통해 달성된다.(전술한 양자택일적인 실시예에서, 전달 단계(1306)는 격리된 시퀀서(b) 상의 에러 핸들링 루틴(도시 안 됨)에 의해 생성되는 VMCALL 프록시 명령어에 의해 달성될 것이다.)
VMCALL 명령어의 프록시 변형은 다음의 파라미터, 즉, 목적지 시퀀서 식별자, 인그레스 시나리오 식별자 및 대기/비대기 지정자를 나타낼 수 있다. 도 13의 블록(1306)은 도 13에 도시된 예에 대한 샘플 프록시 명령어에 대한 파라미터가 다음의 파라미터 값, 즉, a, 시작_프록시, 대기를 포함할 수도 있음을 보여준다. 따라서 제어는 시퀀서(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)은 일드 명령어로 구현될 수도 있으며, 그 결과 OS-가시형 시퀀서(a)는 그 현재 스레드의 실행을 일시 정지하고 프록시 실행 루틴(1400)이 시작되는 EIP 시작_프록시에서 실행을 시작한다.
OS-가시형 시퀀서(a)가 프록시 실행 루틴(1400)을 수행한 후(도 14와 연결지어 이하에서 논의함), 제어는 블록(1308)에서 SEL(1350)로 되돌아간다. 블록(1308)에서, SEL(1350)은 상태 저장 영역(1315)으로부터 (블록(1304)에서 저장된) OS-가시형 시퀀서의 원래 상태를 복원한다. 그러한 상태 복원은 표 1에 목록화 되어 있는 RSTOR 시나리오와 유사한 VMCALL 명령어의 RSTOR 변형에 의해 구현될 수도 있다. 유사하게, 블록(1308)에서, SEL(1350)은 상태 저장 영역(1315)의 연관된 포션(b)으로부터 (블록(1304)에서 저장된) 격리된 시퀀서의 원래 상태를 복원한다. 이어서 VMM(1350)은 격리된 시퀀서(b) 상의 슈레드와 OS-가시형 시퀀서(a) 상의 스레드를 모두 재개한다. 이후 방법(1300)은 블록(1310)에서 종료한다.
도 14는 프록시 실행 방법(1400)을 나타내는 흐름도이다. 적어도 일 실시예에서, 방법(1400)은 격리된 시퀀서와 같은 다른 시퀀서 대신에 OS-가시형 시퀀서와 같은 하나의 시퀀서에 의해 수행될 것이다. 도 14는 블록(1402)에서 시작하여 블록(1404)으로 진행하는 방법(1400)을 보여준다.
블록(1404)에서, OS-가시형 시퀀서는 격리된 시퀀서 상에서 트리거된 시스템 이벤트의 재생을 시도한다. 적어도 일 실시예에서, 시스템 이벤트의 재생은 OS-가시형 시퀀서(a)용 OS에 SEL(1350)이 시스템 이벤트를 주입함으로써 달성될 수도 있다(상기 블록(1306)의 설명을 참조). 적어도 일 실시예에서, 그러한 이벤트는 "엔트리 상의 벡터"특성을 사용하여 주입될 수도 있는데, 이 특성은 VMM이 예외를 주입하고 이후 게스트 OS를 재개하도록 한다. 이러한 방식으로, SEL(1350)은 프록시 시퀀서(a) 상에서 시스템 이벤트를 구체화할 것이다. 도 14는 이벤트의 구체화가 OS-가시형 시퀀서 상에서 링 3에서 링 0으로의 전환을 발생시킬 수도 있음을 보여준다.
이어서 프로세싱은 블록(1406)으로 진행된다. 블록(1406)에서, 프록시 시퀀서용 OS는 링 0 특권 레벨에서 시스템 이벤트를 핸들링한다(상기에서 도 8과 연관된 비특권화된 링 0 레벨 "OD"의 설명 참조). 예를 들어, 이벤트가 페이지 폴트이면, 이벤트는 필요하다면 디스크로부터의 페이징에 의해 핸들링될 것이다(1406). 게스트 OS의 이벤트 핸들러는 페이지 테이블 수정 등과 같은 추가적인 업무를 수행할 수도 있다. 이어서 방법(1400)은 블록(1408)으로 진행한다.
블록(1408)에서, 프록시 시퀀서는, 현재 EIP 값에 의해 지적된 바와 같이, 명령어 스트림 내의 다음 명령어를 실행하려고 시도한다. 적어도 일 실시예에서, 프록시 시퀀서에 대한 EIP가 프록시-관련 상태 전달로 인해 수정될 수도 있었음을 알 것이다(도 13의 블록(1306) 참조). 따라서 블록(1408)에서, 프록시 시퀀서는 제 1 위치에서 프록시 실행을 트리거한 이벤트를 발생시킨 명령어를 실행하려는 시도를 할 것이다(예를 들어, 도 13의 EIP(t)에서의 명령어 참조). 적어도 일 실시예에서, 특권화된 명령어를 실행하려는 시도는 링 3에서 링 0으로의 전환을 일으킬 것이다.
따라서, OS-가시형 시퀀서용 게스트 OS가 블록(1406)에서 예외를 서비스한 후에, 링 0으로부터 링 3으로의 전환은 블록(1408)에서 시퀀서가 이벤트-트리거링 명령어를 실행하려고 시도할 때 발생할 것이다. 그러한 전환은 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 동작을 수행할 수 없을 수도 있다. 그러나 이는 기능적 대칭의 한 예일 뿐이다. 다중-시퀀서 시스템의 시퀀서들은 또한 수치, 워드 및/또는 데이터 경로 크기, 토폴로지, 메모리, 전력 소모, 기능적 유닛의 개수, 통신 아키텍처(다중-드롭 대 포인터-대-포인터 상호연결), 또는 기능성, 수행, 발자국(footprint) 등과 관련된 임의의 다른 메트릭(metric)과 같은 임의의 다른 방식에서 다를 수도 있다.
예를 들어, 하나의 시퀀서가 정수 및 부동점 명령어를 실행할 수도 있지만, 스트리밍 SIMD 확장 3("SSE3")과 같은 명령어 확장의 단일 명령어 다수 데이터("SIMD")세트를 실행할 수는 없다. 반면에, 또 다른 시퀀서는 제 1 시퀀서가 실행할 수 있는 모든 명령어를 수행할 수도 있고 또한 SSE3 명령어를 실행할 수 있 다. 그러한 실시예에서, 도 13에 도시된 프록시 메커니즘의 양자택일적인 실시예는 SSE3 명령어를 수행할 수 있는 시퀀서와 같은 하나의 OS-격리형 시퀀서가 SSE3 명령어를 실행할 수 없는 시퀀서와 같은 또 다른 OS-격리형 시퀀서에 대한 코드를 실행하기 위한 프록시로서 동작할 수도 있도록 활용되기도 한다. 유사하게, 프록시 실행 메커니즘의 실시예는 예를 들어 격리된 시퀀서에 의해 지지되지 않는 특정한 부동점 명령어의 실행을 달성하도록 행사될 것이다. 이러한 방식으로, 비대칭은 애플리케이션 프로그래머에게 명백해질 것이다.
여기서 논의된 슈레딩 에뮬레이션 계층과 그와 연관된 기법은 단일-코어 SMT 시스템(예를 들어, 도 3의 도면 부호(310) 참조)과 다중-코어 시스템(예를 들어, 도 3의 도면 부호(350) 참조)을 포함하는 임의의 다중-시퀀서 시스템 상에서 구현될 것이다. 그러한 시스템에 대한 추가적인 논의는 도 15와 연관지어 이하에서 설명한다.
도 15는 기술된 기법을 수행할 수 있는 컴퓨팅 시스템(1500)의 적어도 하나의 샘플 실시예를 도시하고 있다. 컴퓨팅 시스템(1500)은 적어도 하나의 프로세서 코어(1504)와 메모리 시스템(1540)을 포함하고 있다. 메모리 시스템(1540)은 더 크고 상대적으로 더 느린 메모리 스토리지(1502)뿐만 아니라 명령어 캐쉬(1544) 및/또는 데이터 캐쉬(1542)와 같은 하나 이상의 더 작고 상대적으로 더 빠른 캐쉬를 포함할 수도 있다. 메모리 스토리지(1502)는 프로세서 코어(1504)의 동작을 제어하는 데이터(1512)와 명령어(1510)를 저장할 것이다.
메모리 시스템(1540)은 메모리의 일반화된 표현으로 의도된 것으로 하드 드 라이브, CD-ROM, 랜덤 액세스 메모리(RAM), 다이나믹 랜덤 액세스 메모리(DRAM), 스테틱 랜덤 액세스 메모리(SRAM), 플래시 메모리 그리고 관련된 회로와 같은 다양한 형태의 메모리를 포함할 것이다. 메모리 시스템(1540)은 프로세서(1504)에 의해 실행될 데이터 신호로 표현되는 데이터(1512) 및/또는 명령어(1510)를 저장할 것이다. 명령어(1510) 및/또는 데이터(1512)는 여기서 논의된 임의의 또는 모든 기법을 수행하는 데이터 및/또는 코드를 포함할 수 있다. 예를 들어, 명령어(1510)는 슈레딩 에뮬레이션 계층(402)을 구현할 명령어를 포함할 수도 있다.
프로세서(1504)는 실행 코어(1530)에 명령어 정보를 제공하는 프론트 엔드(1520)를 포함할 수도 있다. 페치(fetch)된 명령어 정보는 실행 코어(1530)에 의한 실행을 기다리기 위해 캐쉬(1525)에서 버퍼링될 것이다. 프론트 엔드(1520)는 프로그램 순서대로 실행 코어(1530)에 명령어 정보를 공급한다. 적어도 일 실시예에서, 프론트 엔드(1520)는 실행될 다음 명령어를 결정하는 페치/디코드 유닛(322)을 포함한다. 시스템(1500)의 적어도 일 실시예에서, 페치/디코드 유닛(322)은 단일 다음-명령어-포인터 및 페치 로직(320)을 포함할 수도 있다. 그러나 각각의 프로세서(1504)가 다수의 스레드 콘텍스트를 지원하는 실시예에서는, 페치/디코드 유닛(322)은 각각의 지원된 스레드 콘텍스트에 대해 별도의 다음-명령어-포인터 및 페치 로직(320)을 구현한다. 다중 프로세서 환경에서의 추가적인 다음-명령어-포인터 및 페치 로직(320)의 선택적 특성은 도 15에서 점선으로 표시되어 있다.
여기서 기술한 방법의 실시예들은 하드웨어, 하드웨어 에뮬레이션 소프트웨 어 또는 다른 소프트웨어, 펌웨어, 또는 그러한 구현 방안의 조합으로 구현될 수 있다. 본 발명의 실시예는 적어도 하나의 프로세서, (휘발성 및 비휘발성 메모리 및/또는 스토리지 성분을 포함하는) 데이터 스토리지 시스템, 적어도 하나의 입력 장치 및 적어도 하나의 출력 장치를 포함하는 프로그램가능한 시스템에 대해서도 구현될 수 있다. 이러한 애플리케이션을 위해, 프로세싱 시스템은 예를 들어, 디지털 신호 프로세서(DSP), 마이크로콘트롤러, 주문형 집적회로(ASIC), 또는 마이크로프로세서와 같은 프로세서를 구비한 임의의 시스템을 포함한다.
프로그램은 일반적으로 또는 특정 목적으로 프로그램가능한 프로세싱 시스템에 의해 판독 가능한 스토리지 매체 또는 장치(예를 들어, 하드 디스크 드라이브, 플로피 디스크 드라이브, ROM, CD-ROM 장치, 플래시 메모리 장치, DVD, 또는 다른 저장 장치)에 저장될 수 있다. 프로세싱 시스템 내의 프로세서에 액세스 가능한 명령어는 스토리지 매체 또는 장치가 여기서 기술한 절차를 수행하기 위해 프로세싱 시스템에 의해 판독될 때 프로세싱 시스템을 구성하고 동작시키도록 제공된다. 본 발명의 실시예들은 또한 프로세싱 시스템과 함께 사용되도록 구성된 머신-판독가능형 스토리지 매체로서 구현되는 것이 고려될 수도 있으며, 그렇게 구성된 스토리지 매체는 프로세싱 시스템이 특정한 소정의 방식으로 동작하여 여기서 기술한 기능을 수행하도록 만든다.
비록 (다른 마이크로프로세서, 엔지니어링 워크스테이션, 개인휴대정보단말기 및 다른 휴대용 장치, 셋-탑 박스 등을 구비한 개인 컴퓨터(PC)를 포함하는) 다른 시스템도 사용될 수 있지만, 샘플 시스템(1400)은 인텔사로부터 구할 수 있는 펜티엄®, 펜티엄® 프로, 펜티엄® II, 펜티엄®III, 펜티엄®4, 그리고 아이테니엄(itanium)®및 아이테니엄® 2 마이크로프로세서에 기초한 프로세싱 시스템을 대표하고 있다. 일 실시예에서, 비록 예를 들어, 다른 운영체계와 그래픽 사용자 인터페이스도 사용할 수 있지만, 샘플 시스템은 마이크로소프트사로부터 구할 수 있는 Windows™ 운영체계 버전을 실행할 것이다.
본 발명의 특정 실시예를 도시하고 기술하였지만, 더 넓은 측면에서 후속하는 청구항의 범주에서 출발하지 않고도 변경이나 수정이 이루어질 수 있음이 당업자에게는 명백할 것이다. 후속하는 청구항은 본 발명의 진정한 범주 내에 속하는 모든 그러한 변경 및 수정을 관련 범주 내에 포함한다.

Claims (39)

  1. 운영체계(OS)로부터 격리된 시퀀서에 하나 이상의 스레드 제어 신호를 발행하는 단계를 포함하며, 상기 발행 단계는 사용자-생성 명령어에 반응하여 추상화 계층에 의해 실행되는
    사용자-레벨 멀티스레딩 방법.
  2. 제 1 항에 있어서,
    상기 발행 단계는
    OS-가시형 스레드 내의 상기 사용자-생성 명령어를 OS-가시형 시퀀서 상에서 실행하는 것에 반응하여 상기 추상화 계층에 의해 추가적으로 실행되는
    사용자-레벨 멀티스레딩 방법.
  3. 제 1 항에 있어서,
    상기 하나 이상의 스레드 제어 신호는 상기 격리된 시퀀서로 하여금 명령어 시퀀스의 실행을 시작하도록 하는 신호를 더 포함하는
    사용자-레벨 멀티스레딩 방법.
  4. 제 3 항에 있어서,
    상기 하나 이상의 스레드 제어 신호는 상기 격리된 시퀀서로 하여금 변경된 명령어 포인터 어드레스에서 명령어 시퀀스의 실행을 시작하도록 하는 신호를 더 포함하는
    사용자-레벨 멀티스레딩 방법.
  5. 제 1 항에 있어서,
    상기 운영체계에 의해 스케줄링되고 상기 사용자-생성 명령어를 포함하는 제 1 명령어 시퀀스를 제 1 시퀀스 상에서 실행하는 동시에,
    상기 격리된 시퀀서 상에서 제 2 명령서 시퀀스를 실행하는 단계를 더 포함하는
    사용자-레벨 멀티스레딩 방법.
  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-가시형 시퀀서 상의 정지점(breakpoint)을 제거하는 단계를 더 포함하는
    사용자-레벨 멀티스레딩 방법.
  15. 다수 개의 명령어 스트림을 동시에 실행하는 다수 개의 시퀀서와,
    상기 시퀀서에 연결된 메모리와,
    상기 시퀀서에 연결되며, 운영체계로부터 상기 시퀀서 중의 하나 이상을 격리시키는 추상화 계층을 포함하며,
    상기 추상화 계층이 추가적으로 상기 하나 이상의 격리된 시퀀서 상에서 상기 하나 이상의 명령어 스트림의 실행을 제어하는
    사용자-레벨 멀티스레딩 시스템.
  16. 제 15 항에 있어서,
    상기 다수 개의 시퀀서 중에서 적어도 하나가 하나 이상의 다른 시퀀서와 계산적으로 비대칭인
    사용자-레벨 멀티스레딩 시스템.
  17. 제 15 항에 있어서,
    상기 메모리가 DRAM인
    사용자-레벨 멀티스레딩 시스템.
  18. 제 15 항에 있어서,
    상기 추상화 계층이 상기 하나 이상의 시퀀서를 격리시키기 위한 시퀀서 격리 모듈을 더 포함하는
    사용자-레벨 멀티스레딩 시스템.
  19. 제 15 항에 있어서,
    상기 추상화 계층이 상기 격리된 시퀀서에 대해 운영체계 서비스를 인보크(invoke)하기 위한 프록시 실행 모듈을 더 포함하는
    사용자-레벨 멀티스레딩 시스템.
  20. 제 15 항에 있어서,
    상기 추상화 계층이 적어도 두 개의 시퀀서 사이에 신호를 전달하기 위한 시퀀서 연산 모듈을 더 포함하는
    사용자-레벨 멀티스레딩 시스템.
  21. 제 15 항에 있어서,
    상기 추상화 계층이
    적어도 하나의 격리된 시퀀서가 상기 운영체계의 링 0 동작 동안에 동작을 일시 정지시키도록 하기 위한 전환 검출 모듈을 더 포함하는
    사용자-레벨 멀티스레딩 시스템.
  22. 제 21 항에 있어서,
    상기 추상화 계층이 적어도 하나의 격리된 시퀀서가 상기 운영체계의 링 0 동작 후에 동작을 재개하도록 하기 위한 전환 검출 모듈을 더 포함하는
    사용자-레벨 멀티스레딩 시스템.
  23. 제 15 항에 있어서,
    상기 추상화 계층을 위한 명령어가 상기 메모리에 포함되어 있는
    사용자-레벨 멀티스레딩 시스템.
  24. 제 15 항에 있어서,
    상기 메모리가 상기 추상화 계층의 게스트로서 상기 운영체계를 운영하기 위한 명령어를 포함하는
    사용자-레벨 멀티스레딩 시스템.
  25. 추상화 계층을 위한 다수 개의 머신 액세스가능 명령어를 구비한 머신-액세스가능 매체를 포함하는 물품(article)에 있어서,
    상기 명령어가 프로세서에 의해 실행되고, 상기 명령어가 운영체계(OS)로부터 격리된 시퀀서에 하나 이상의 스레드 제어 신호를 발행하는 단계를 제공하며,
    상기 발행 단계를 위한 상기 명령어가 사용자-생성 명령어에 반응하여 상기 추상화 계층에 의해 수행되는
    머신-액세스가능 매체를 포함하는 물품.
  26. 제 25 항에 있어서,
    상기 발행 단계를 위한 상기 명령어가 OS-가시형 스레드 내의 상기 사용자-생성 명령어를 OS-가시형 시퀀서 상에서 실행하는 것에 반응하여 상기 추상화 계층에 의해 추가적으로 실행되는
    머신-액세스가능 매체를 포함하는 물품.
  27. 제 25 항에 있어서,
    상기 하나 이상의 스레드 제어 신호는 상기 격리된 시퀀서로 하여금 명령어 시퀀스의 실행을 시작하도록 하는 신호를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  28. 제 27 항에 있어서,
    상기 하나 이상의 스레드 제어 신호는 상기 격리된 시퀀서로 하여금 변경된 명령어 포인터 어드레스에서 명령어 시퀀스의 실행을 시작하도록 하는 신호를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  29. 제 25 항에 있어서,
    상기 프로세서가,
    상기 운영체계에 의해 스케줄링되고 상기 사용자-생성 명령어를 포함하는 제 1 명령어 시퀀스를 제 1 시퀀스 상에서 실행하는 동시에,
    상기 격리된 시퀀서 상에서 제 2 명령서 시퀀스를 실행하는 단계를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  30. 제 25 항에 있어서,
    상기 추상화 계층 명령어가,
    상기 프로세서에 의해 실행될 때, 상기 격리된 시퀀서에 대한 실행 환경을 생성하기 위한 명령어를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  31. 제 25 항에 있어서,
    상기 스레드 제어 신호가 상기 격리된 시퀀서 상의 실행을 인터럽트 하는 신호를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  32. 제 31 항에 있어서,
    상기 스레드 제어 신호가 인터럽트 신호를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  33. 제 25 항에 있어서,
    상기 추상화 계층 명령어가,
    상기 프로세서에 의해 실행될 때, 동작 세트를 수행하여 OS-가시형 시퀀서가 상기 격리된 시퀀서를 위해 이벤트 핸들링 루틴의 실행을 트리거하도록 하기 위한 명령어를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  34. 제 33 항에 있어서,
    상기 동작 세트가,
    상기 격리된 시퀀서에 대한 상태를 상기 OS-가시형 시퀀서에 전달하는 단계를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  35. 제 25 항에 있어서,
    상기 추상화 계층 명령어가,
    상기 프로세서에 의해 실행될 때, 상기 격리된 시퀀서 상에서의 실행을 일시 정지시키는 동작 세트를 수행하기 위한 명령어를 더 포함하며,
    상기 동작 세트가 OS-가시형 시퀀서 상에서의 링 전환에 반응하여 상기 추상화 계층에 의해 수행되고,
    상기 동작 세트가 상기 하나 이상의 제어 신호를 발행하는 단계를 더 포함하며, 상기 제어 신호가 상기 격리된 시퀀서를 대기 상태로 만드는 신호를 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  36. 제 35 항에 있어서,
    상기 동작 세트가,
    상기 OS-가시형 시퀀서 상의 정지점을 셋-업하는 단계를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  37. 제 25 항에 있어서,
    상기 추상화 계층 명령어가,
    상기 프로세서에 의해 실행될 때, 상기 격리된 시퀀서 상에서의 실행을 재개시키는 동작 세트를 수행하기 위한 명령어를 더 포함하며,
    상기 동작 세트가 OS-가시형 시퀀서 상에서의 예외-핸들링 루틴의 완료에 따라 상기 추상화 계층에 의해 수행되고,
    상기 동작 세트가 상기 하나 이상의 제어 신호를 발행하는 단계를 더 포함하며, 상기 제어 신호가 상기 격리된 시퀀서 상에서의 실행을 재개하는 신호를 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  38. 제 37 항에 있어서,
    상기 동작 세트가,
    상기 OS-가시형 시퀀서 상의 정지점(breakpoint)을 제거하는 단계를 더 포함하는
    머신-액세스가능 매체를 포함하는 물품.
  39. 제 12 항에 있어서,
    상기 추적 단계가,
    상기 OS-가시형 시퀀서를 위한 정지점을 셋-업하는 단계를 더 포함하는
    사용자-레벨 멀티스레딩 방법.
KR1020077017661A 2004-12-30 2005-12-28 사용자-레벨 멀티스레딩 방법 및 시스템과 컴퓨터 판독가능 저장 매체 KR100951734B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/026,597 US7810083B2 (en) 2004-12-30 2004-12-30 Mechanism to emulate user-level multithreading on an OS-sequestered sequencer
US11/026,597 2004-12-30

Publications (2)

Publication Number Publication Date
KR20070095382A true KR20070095382A (ko) 2007-09-28
KR100951734B1 KR100951734B1 (ko) 2010-04-08

Family

ID=36642183

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020077017661A KR100951734B1 (ko) 2004-12-30 2005-12-28 사용자-레벨 멀티스레딩 방법 및 시스템과 컴퓨터 판독가능 저장 매체

Country Status (6)

Country Link
US (1) US7810083B2 (ko)
EP (1) EP1834239A2 (ko)
JP (2) JP2008527506A (ko)
KR (1) KR100951734B1 (ko)
CN (2) CN101095112B (ko)
WO (1) WO2006074059A2 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200034572A (ko) * 2018-09-21 2020-03-31 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. 요청 처리 방법 및 장치

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10331202A1 (de) * 2003-07-10 2005-03-31 S.K. Enterprise Gmbh Verwendung von Molkenpermeat zur Behandlung des Metabolischen Syndroms
US8079034B2 (en) * 2003-09-15 2011-12-13 Intel Corporation Optimizing processor-managed resources based on the behavior of a virtual machine monitor
US7810083B2 (en) 2004-12-30 2010-10-05 Intel Corporation Mechanism to emulate user-level multithreading on an OS-sequestered sequencer
US7886126B2 (en) * 2005-01-14 2011-02-08 Intel Corporation Extended paging tables to map guest physical memory addresses from virtual memory page tables to host physical memory addresses in a virtual machine system
US8214830B2 (en) * 2005-01-19 2012-07-03 Intel Corporation Performance in a virtualization architecture with a processor abstraction layer
US20060212840A1 (en) * 2005-03-16 2006-09-21 Danny Kumamoto Method and system for efficient use of secondary threads in a multiple execution path processor
US8010969B2 (en) 2005-06-13 2011-08-30 Intel Corporation Mechanism for monitoring instruction set based thread execution on a plurality of instruction sequencers
US7516336B2 (en) * 2005-09-29 2009-04-07 Intel Corporation System and method for power reduction by sequestering at least one device or partition in a platform from operating system access
US7823153B1 (en) 2005-09-30 2010-10-26 Symantec Corporation System and method for detecting and logging in-line synchronization primitives in application program code
US7930684B2 (en) * 2005-10-12 2011-04-19 Symantec Operating Corporation System and method for logging and replaying asynchronous events
US8914618B2 (en) * 2005-12-29 2014-12-16 Intel Corporation Instruction set architecture-based inter-sequencer communications with a heterogeneous resource
US8117600B1 (en) 2005-12-29 2012-02-14 Symantec Operating Corporation System and method for detecting in-line synchronization primitives in binary applications
US8689215B2 (en) * 2006-12-19 2014-04-01 Intel Corporation Structured exception handling for application-managed thread units
US20080320475A1 (en) * 2007-06-19 2008-12-25 Microsoft Corporation Switching user mode thread context
US8122452B2 (en) * 2007-06-29 2012-02-21 Oracle America, Inc. Swap cap resource control for use in virtualization
US8763115B2 (en) * 2007-08-08 2014-06-24 Vmware, Inc. Impeding progress of malicious guest software
JP4678396B2 (ja) * 2007-09-25 2011-04-27 日本電気株式会社 仮想マシンモニタをモニタするコンピュータとその方法、および仮想マシンモニタモニタプログラム
US20090083766A1 (en) * 2007-09-26 2009-03-26 Towson University Systems for performing bare machine computer applications
US8447962B2 (en) * 2009-12-22 2013-05-21 Intel Corporation Gathering and scattering multiple data elements
US8245212B2 (en) * 2008-02-22 2012-08-14 Microsoft Corporation Building call tree branches and utilizing break points
US9672019B2 (en) 2008-11-24 2017-06-06 Intel Corporation Systems, apparatuses, and methods for a hardware and software system to automatically decompose a program to multiple parallel threads
US10621092B2 (en) 2008-11-24 2020-04-14 Intel Corporation Merging level cache and data cache units having indicator bits related to speculative execution
US8464035B2 (en) * 2009-12-18 2013-06-11 Intel Corporation Instruction for enabling a processor wait state
US8671400B2 (en) * 2009-12-23 2014-03-11 Intel Corporation Performance analysis of software executing in different sessions
US8775153B2 (en) * 2009-12-23 2014-07-08 Intel Corporation Transitioning from source instruction set architecture (ISA) code to translated code in a partial emulation environment
US9058183B2 (en) * 2009-12-29 2015-06-16 Advanced Micro Devices, Inc. Hypervisor isolation of processor cores to enable computing accelerator cores
US8813083B2 (en) * 2011-07-01 2014-08-19 Intel Corporation Method and system for safe enqueuing of events
US8924986B2 (en) * 2011-09-01 2014-12-30 American Megatrends, Inc. Methods, devices and computer program products for confluence of multiple operating systems
WO2013048468A1 (en) 2011-09-30 2013-04-04 Intel Corporation Instruction and logic to perform dynamic binary translation
AR088996A1 (es) * 2011-11-28 2014-07-23 Evogene Ltd Polinucleotidos y polipeptidos aislados, sus metodos de utilizacion para mejorar la eficacia en el uso del nitrogeno, rendimiento, tasa de crecimiento, vigor, biomasa, contenido de aceite y/o tolerancia al estres abiotico
CN103136047B (zh) * 2011-11-30 2016-08-17 大唐联诚信息系统技术有限公司 一种多线程管理方法及架构
US20150134932A1 (en) * 2011-12-30 2015-05-14 Cameron B. McNairy Structure access processors, methods, systems, and instructions
US9069598B2 (en) 2012-01-06 2015-06-30 International Business Machines Corporation Providing logical partions with hardware-thread specific information reflective of exclusive use of a processor core
US20140075163A1 (en) * 2012-09-07 2014-03-13 Paul N. Loewenstein Load-monitor mwait
US9417886B2 (en) * 2013-01-21 2016-08-16 Dell Products, Lp System and method for dynamically changing system behavior by modifying boot configuration data and registry entries
US9858097B2 (en) 2013-06-07 2018-01-02 American Megatrends, Inc. Methods, devices and computer readable storage devices for emulating rotation events in a guest operating system from a host operating system
US9378038B2 (en) 2013-06-07 2016-06-28 American Megatrends, Inc. Methods, devices and computer readable storage devices for emulating a gyroscope in a guest operating system from a host operating system
US9891936B2 (en) 2013-09-27 2018-02-13 Intel Corporation Method and apparatus for page-level monitoring
US9436503B2 (en) * 2013-10-31 2016-09-06 Emu Solutions, Inc. Concurrency control mechanisms for highly multi-threaded systems
US9430182B2 (en) 2014-03-06 2016-08-30 American Megatrends, Inc. Methods, systems and computer readable storage devices for presenting screen content
US10162655B2 (en) 2014-06-23 2018-12-25 Vmware, Inc. Hypervisor context switching using TLB tags in processors having more than two hierarchical privilege levels
US10019275B2 (en) * 2014-06-23 2018-07-10 Vmware, Inc. Hypervisor context switching using a trampoline scheme in processors having more than two hierarchical privilege levels
US10255090B2 (en) 2014-06-23 2019-04-09 Vmware, Inc. Hypervisor context switching using a redirection exception vector in processors having more than two hierarchical privilege levels
EP3161657B1 (en) * 2014-06-24 2020-07-22 Intel Corporation Firmware sensor layer
US10430234B2 (en) * 2016-02-16 2019-10-01 Red Hat, Inc. Thread coordination in a rule engine using a state machine
GB2569098B (en) * 2017-10-20 2020-01-08 Graphcore Ltd Combining states of multiple threads in a multi-threaded processor
US10606641B2 (en) 2017-10-20 2020-03-31 Graphcore Limited Scheduling tasks in a multi-threaded processor
GB201717303D0 (en) * 2017-10-20 2017-12-06 Graphcore Ltd Scheduling tasks in a multi-threaded processor
US10917409B2 (en) * 2018-04-19 2021-02-09 Microsoft Technology Licensing, Llc System and method to securely execute datacenter management operations remotely
CN109491780B (zh) * 2018-11-23 2022-04-12 鲍金龙 多任务调度方法及装置

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2692609B2 (ja) * 1994-09-26 1997-12-17 日本電気株式会社 マルチタスクのプログラムデバッグ方法とその装置
US6006320A (en) * 1996-07-01 1999-12-21 Sun Microsystems, Inc. Processor architecture with independent OS resources
JPH10326205A (ja) * 1997-03-27 1998-12-08 Mitsubishi Electric Corp システムコール発行方法
US6493599B2 (en) * 1998-03-19 2002-12-10 Dell Usa, L.P. Automated system and method for generating data to drive a manufacturing process
US6684323B2 (en) * 1998-10-27 2004-01-27 Stmicroelectronics, Inc. Virtual condition codes
US6349363B2 (en) * 1998-12-08 2002-02-19 Intel Corporation Multi-section cache with different attributes for each section
US6769122B1 (en) * 1999-07-02 2004-07-27 Silicon Graphics, Inc. Multithreaded layered-code processor
JP2001306356A (ja) * 2000-04-24 2001-11-02 Canon Inc タスクスケジューリング予測表示方法および装置
US20030191730A1 (en) * 2002-04-05 2003-10-09 Compaq Information Technologies Group, L.P. Unobtrusive rule-based computer usage enhancement system
US7337442B2 (en) * 2002-12-03 2008-02-26 Microsoft Corporation Methods and systems for cooperative scheduling of hardware resource elements
US7496915B2 (en) * 2003-04-24 2009-02-24 International Business Machines Corporation Dynamic switching of multithreaded processor between single threaded and simultaneous multithreaded modes
US7493435B2 (en) * 2003-10-06 2009-02-17 Intel Corporation Optimization of SMI handling and initialization
US7430737B2 (en) * 2003-12-04 2008-09-30 Sun Microsystems, Inc. Processor and method for supporting compiler directed multithreading management
US7631307B2 (en) * 2003-12-05 2009-12-08 Intel Corporation User-programmable low-overhead multithreading
US20050138333A1 (en) * 2003-12-19 2005-06-23 Samra Nicholas G. Thread switching mechanism
US7555753B2 (en) * 2004-02-26 2009-06-30 International Business Machines Corporation Measuring processor use in a hardware multithreading processor environment
US9189230B2 (en) * 2004-03-31 2015-11-17 Intel Corporation Method and system to provide concurrent user-level, non-privileged shared resource thread creation and execution
US20050251662A1 (en) * 2004-04-22 2005-11-10 Samra Nicholas G Secondary register file mechanism for virtual multithreading
US7748001B2 (en) * 2004-09-23 2010-06-29 Intel Corporation Multi-thread processing system for detecting and handling live-lock conditions by arbitrating livelock priority of logical processors based on a predertermined amount of time
US7426648B2 (en) * 2004-09-30 2008-09-16 Intel Corporation Global and pseudo power state management for multiple processing elements
US20060130062A1 (en) * 2004-12-14 2006-06-15 International Business Machines Corporation Scheduling threads in a multi-threaded computer
US7810083B2 (en) 2004-12-30 2010-10-05 Intel Corporation Mechanism to emulate user-level multithreading on an OS-sequestered sequencer

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200034572A (ko) * 2018-09-21 2020-03-31 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. 요청 처리 방법 및 장치

Also Published As

Publication number Publication date
KR100951734B1 (ko) 2010-04-08
JP2011103132A (ja) 2011-05-26
CN101095112A (zh) 2007-12-26
WO2006074059A2 (en) 2006-07-13
CN101095112B (zh) 2011-05-25
CN102147749A (zh) 2011-08-10
US7810083B2 (en) 2010-10-05
JP2008527506A (ja) 2008-07-24
EP1834239A2 (en) 2007-09-19
CN102147749B (zh) 2014-01-15
US20060150183A1 (en) 2006-07-06
WO2006074059A3 (en) 2006-10-12

Similar Documents

Publication Publication Date Title
KR100951734B1 (ko) 사용자-레벨 멀티스레딩 방법 및 시스템과 컴퓨터 판독가능 저장 매체
US8024742B2 (en) Common program for switching between operation systems is executed in context of the high priority operating system when invoked by the high priority OS
Landau et al. {SplitX}: Split {Guest/Hypervisor} Execution on {Multi-Core}
US5511217A (en) Computer system of virtual machines sharing a vector processor
US8612992B2 (en) Operating systems
US9619279B2 (en) Operating systems sharing supervisor address space with same virtual to physical mapping for supervisor address space using same translation formula with different translation tree
Uhlig et al. Intel virtualization technology
Varanasi Implementing Hardware-supported Virtualization in OKL4 on ARM
US20150169346A1 (en) Method for controlling a virtual machine and a virtual machine system
US9164784B2 (en) Signalizing an external event using a dedicated virtual central processing unit
US20070022421A1 (en) Operating systems
JP6530723B2 (ja) コンピュータシステム内における複数のハイパーバイザーの共同運用を容易にするためのシステムおよび方法
US11301283B1 (en) Virtualization extension modules
WO2018040845A1 (zh) 一种计算资源调度方法及装置
US11169837B2 (en) Fast thread execution transition
Amit et al. Bare-metal performance for virtual machines with exitless interrupts
JP2007507779A (ja) オペレーティングシステム
Cicero et al. Reconciling security with virtualization: A dual-hypervisor design for ARM TrustZone
Qaralleh et al. HcM-FreeRTOS: hardware-centric FreeRTOS for ARM multicore
EP1673697B1 (en) Operating systems
US11726811B2 (en) Parallel context switching for interrupt handling
EP1673693B1 (en) Operating systems
Tian Dynamic FPGA Management: contribution to IP accelerators virtualization and pre-emption mechanisms
Mitake et al. Light-weighted virtualization layer for multicore processor-based embedded systems

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130228

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20140303

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20150227

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20160304

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20170302

Year of fee payment: 8

LAPS Lapse due to unpaid annual fee