KR20060047639A - 가상 환경으로부터 하드웨어로의 직접적인 액세스를제공하는 컴퓨터 판독가능 매체 - Google Patents

Abstract

확장물 또는 다른 소프트웨어 애플리케이션은 가상 기기 환경 안에서부터 하드웨어로의 직접적인 액세스를 가질 수 있다. 하드웨어의 물리적 주소는 가상 기기 환경의 프로세스 공간에 매핑될 수 있다. 이와 마찬가지로, I/O 포트는 가상 환경으로 패스-스루(pass-through)될 수 있다. 필요한 메모리가 피닝(pin)될 수 있을 때 가상 기기는 다가오는 DMA(Direct Memory Access)를 탐지할 수 있고, 올바른 DMA의 주소를 제공할 수 있다. 하드웨어 인터럽트가 도착할 때 가상 기기가 실행되고 있다면, 이 기기의 프로세스 내부의 인터럽트 라인을 에뮬레이팅 할 수 있다. 이와는 다르게, 호스트 오퍼레이팅 시스템이 수행되고 있다면, 인터럽트를 비활성화시키고 임시 인터럽트를 추적하여, 계속하여 가상 기기 프로세스에 제어를 전송하고, 그 임시 인터럽트를 에뮬레이팅하고 인터럽트를 다시 활성화시킬 수 있다. 대안으로, 호스트 오퍼레이팅 시스템은 즉시 제어를 전송하거나, 자신의 프로세스에서 인터럽스 서비스 루틴을 직접 실행시킬 수 있다.

가상 기기, 인터럽트, 호스트 오퍼레이팅 시스템, DMA

Description

가상 환경으로부터 하드웨어로의 직접적인 액세스를 제공하는 컴퓨터 판독가능 매체{PROVIDING DIRECT ACCESS TO HARDWARE FROM A VIRTUAL ENVIRONMENT}

도 1은 본 발명의 실시예가 구현될 수 있는 예시적인 장치 아키텍처를 일반적으로 도시하는 블록도.

도 2는 본 발명의 실시예에 따른 확장물을 고립시키기 위한 예시적인 환경을 일반적으로 도시하는 블록도.

도 3은 본 발명의 실시예에 따른 사용자 모드 컨텍스트(context)로의 액세스를 일반적으로 도시하는 블록도.

도 4는 본 발명의 실시예에 따른 사용자 모드 컨텍스트로의 다른 액세스를 일반적으로 도시하는 블록도.

도 5는 본 발명의 실시예에 따른 코히어런트(coherent) 상태의 생성을 일반적으로 도시하는 흐름도.

도 6은 본 발명의 실시예에 따른 코히어런트 상태의 다른 생성을 일반적으로 도시하는 흐름도.

도 7은 본 발명의 실시예에 따라 가상 기기 내에서 호스팅된 확장물에 물리적 하드웨어로의 직접적 액세스를 제공하기 위한 예시적인 환경을 일반적으로 도시하는 블록도.

<도면의 주요 부분에 대한 부호의 설명>

120: 프로세싱 유닛

130: 시스템 메모리

201: 호스트 프로세스

211: 가상 프로세스

215, 315: 확장물

613: 하이퍼바이저

[문헌 1] 계류중인 US 출원 "VEX - 가상 확장물 프레임워크(VEX - VIRTUAL EXTENSION FRAMEWORK)" 대리인 사건 번호 225654

본 발명은 일반적으로 가상 기기에 관한 것으로, 보다 상세히는, 가상 기기 환경 안에서 실행되는 확장물 및 다른 소프트웨어 애플리케이션에게 기본적인 호스트 컴퓨팅 장치에 접속된 하드웨어 장치로의 직접적인 액세스를 제공하는 시스템 및 방법에 관한 것이다.

컴퓨팅 하드웨어의 성능이 증가함에 따라, 추가적인 하드웨어의 구입의 대안인 가상 기기 기술은 실용적이고 비용-효율적인 대안이 되었다. 일반적으로, 가상 기기는 코드가 동일하거나 다른 하드웨어 및 소프트웨어 상에서 실행될 때 하드웨 어 또는 소프트웨어 환경의 한 유형을 에뮬레이팅하고자 하는 코드의 컬렉션일 수 있다. 가상 기기는 컴퓨터 사용자가 특정 하드웨어 또는 소프트웨어 구성에서 이용될 수 없는 소프트웨어 또는 다른 자원으로의 액세스를 원할 때 특히 유용할 수 있다. 예를 들면, 한 유형의 컴퓨팅 하드웨어 및 오퍼레이팅 시스템에서 실행되는 가상 기기는 다른 유형의 하드웨어 및 오퍼레이팅 시스템을 가지는 컴퓨팅 장치에서 볼 수 있는 것처럼 환경을 에뮬레이팅할 수 있다. 결과적으로, 가상 기기는 제1 유형의 하드웨어 및 오퍼레이팅 시스템의 사용자가 제2 유형의 하드웨어 및 오퍼레이팅 시스템에 대하여 작성된 소프트웨어 애플리케이션 등을 임의의 추가적인 하드웨어를 구매할 필요 없이 이용하도록 할 수 있다.

가상 기기는 후향 호환되는 크로스-플랫폼(cross-platform) 해결책 또는 소프트웨어의 개발에 유용할 수 있다. 예를 들면, 최근의 하드웨어 소프트웨어를 이용하는 소프트웨어 개발자는 단순히 가상 기기를 실행시키고 이전 하드웨어 또는 소프트웨어에 대응하는 가상 환경을 생성함으로써 임의의 이전의 하드웨어 또는 소프트웨어 상에서 자신의 코드를 테스트할 수 있다. 마찬가지로, 웹 싸이트와 같은 크로스-플랫폼 호환성을 요구할 수 있는 물질의 개발자는 가상 기기를 실행하고 브라우저가 설계되었던 플랫폼에 대응하는 가상 환경을 생성함으로써 다양한 플랫폼에 대하여 설계된 웹 브라우저를 통하여 이 웹 싸이트를 테스트할 수 있다.

일반적으로, 가상 기기는 "하이퍼바이저"라 종종 칭하여지는 코드의 컬렉션을 통하여 하드웨어 및 소프트웨어 추상화를 수행한다. 하이퍼바이저는 가상 기기 환경으로부터의 실행 명령 및 요청을 가상 기기 애플리케이션이 실행되고 있는 물 리적 컴퓨팅 환경에 적절한 요청 및 명령으로 변환한다. 일반적으로 이러한 변환은 하이퍼바이저에 의해 수행되는 다양한 추상화를 이용할 수 있다. 예를 들면, 하이퍼바이저는 복수의 서로 다른 물리적 오디오 인터페이스를 가상 환경에서 소프트웨어에 나타날 수 있는 하나의 일반적인 오디오 인터페이스로 추상화할 수 있다. 그 다음 가상 환경 내의 소프트웨어는 이 일반적인 오디오 인터페이스를 이용할 수 있고 하이퍼바이저는 일반적인 오디오 인터페이스로의 요청과 가상 기기가 현재 실행하고 있는 호스트 컴퓨팅 장치에 접속되게 된 특정한 기본적인 물리적 오디오 인터페이스에 송신될 수 있는 하드웨어에-특정된 요청들 사이에서 이행을 할 수 있다.

불행하게도, 가상 기기 환경은 에뮬레이팅되고 추상화된 하드웨어를 사용하기 때문에, 독점적인 하드웨어, 일반적이지 않은 하드웨어, 또는 레가시 하드웨어와 인터페이스하는 확장물 또는 소프트웨어를 호스팅할 수 없을 수 있다. 예를 들면, 현대 오퍼레이팅 시스템은 랩 장비, 로보트 인터페이스, 및 종종 업데이트될 가능성이 없는 유사한 장치와 같은, 레가시 장치에 대한 장치 드라이버와 더이상 호환되지 않을 수 있다. 이러한 경우에서, 사용자는 가상 기기 환경에서 레가시 장치에 대한 장치 드라이버를 사용하기를 시도할 수 있다. 그러나, 가상 기기가 에뮬레이팅된 하드웨어에 의존하기 때문에, 가상 환경에서의 장치 드라이버가 레가시 하드웨어와 적절하게 통신하는 것은 불가능할 수 있다. 마찬가지로, 일반적이지 않는 하드웨어는 단지 이러한 추상화의 시도가 정당할 정도로 충분한 수요가 존재하지 않을 수 있기 때문에 하이퍼바이저에 의해 적절히 추상화되지 않을 수 있 다. 그러므로, 이러한 일반적이지 않는 하드웨어의 사용자는 가상 기기의 편리성에 의존할 수 없을 수 있다.

게다가, 하이퍼바이저가 하드웨어를 에뮬레이팅하고 추상화하기 때문에, 가상 기기 기술의 개발자 및 작성자가 자신의 가상 기기가 존재하는 하드웨어와 가능한 호환성 있도록 하기 위하여 증가하는 하드웨어의 영역을 에뮬레이팅하고 추상화하는 것을 계속하는 것에 대한 부담을 가질 수 있다. 이러한 부담은 종종 성능을 향상시키거나 프로그래밍 에러를 감소시키는 것에 대한 것과 같은, 보다 중요한 가상 기기 기술을 더 개발하는 것을 혼란스럽게 할 수 있다. 그러므로 확장물 또는 다른 소프트웨어 애플리케이션이 가상 기기가 실행되고 있는 기본적인 하드웨어와 직접적으로 통신하도록 할 수 있는 가상 기기 환경을 생성하는 것이 바람직할 수 있다.

본 발명의 실시예는 가상 기기 환경 내의 확장물 및 다른 소프트웨어 애플리케이션이 호스트 컴퓨팅 장치에 접속된 하나 이상의 하드웨어 장치를 직접적으로 액세스하도록 한다.

일 실시예에서, 하이퍼바이저 또는 기본적인 하드웨어는 하드웨어 장치의 물리적 주소를 가상 기기 프로세스로 매핑시켜 가상 기기 프로세스에서 실행되는 확장물 및 다른 소프트웨어 애플리케이션이 하드웨어 장치로의 직접적인 액세스를 가지도록 할 수 있다.

다른 실시예에서, 하이퍼바이저 또는 기본적인 하드웨어는 하나 이상의 I/O 포트가 가상 환경에 적절하게 나타나도록 I/O 보호 비트맵과 같은 구조를 수정하여, 가상 기기 프로세스에서 실행되는 확장물 및 다른 소프트웨어 애플리케이션이 I/O 명령을 하드웨어 장치에 접속된 물리적 I/O 포트에 송신할 수 있도록 할 수 있다.

다른 실시예에서, 하이퍼바이저, 가상 오퍼레이팅 시스템, 또는 기본적인 하드웨어는 가상 기기 프로세스에서 실행되는 확장물 또는 다른 소프트웨어 애플리케이션에 의해 이루어진 함수 호출을 모니터링하여 다가오는 DMA(Direct Memory Access)를 탐지할 수 있다. 다가오는 DMA를 탐지하는 중에, 하이퍼바이저, 또는 가상 오퍼레이팅 시스템은 적절한 DMA 주소가 가상 기기 환경 내로부터에서도 이용될 수 있는 방식으로 DMA를 수정할 수 있다. 이용될 물리적 메모리가 피닝되어 메모리 충돌을 방지할 수도 있다.

또 다른 실시예에서, 하이퍼바이저는 가상 기기 환경에서 물리적 하드웨어 인터럽트 라인과 하드웨어 인터럽트 라인 사이에서 이행을 함으로써 하드웨어 인터럽트를 가상 기기 환경으로 전달할 수 있다. 인터럽트가 도착했을 때 호스트 오퍼레이팅 시스템 프로세스가 실행되고 있었다면, 인터럽트를 비활성화시키고 일시적인 인터럽트를 추적하여, 일시적인 인터럽트가 에뮬레이팅될 수 있는 시점에서, 가상 기기 프로세스로 제어를 전송하기 이전에 하나 이상의 태스크를 완료할 수 있고, 인터럽트는 재활성화 될 수 있다. 대안으로, 호스트 오퍼레이팅 시스템은 지연 없이 인터럽트를 수신할 수 있는 적어도 하나의 CPU를 가지기 위하여 복수의-CPU 시스템을 에뮬레이팅 할 수 있는 가상 기기 프로세스로 제어를 즉시 전송할 수 있다. 다른 대안은 호스트 오퍼레이팅 시스템이 가상 기기 프로세스로부터 인터럽트 서비스 코드를 복사하고 호스트 오퍼레이팅 시스템 프로세스에서 이 코드를 실행하며 알려진 소프트웨어 장애 고립 기법을 이용하여 메모리 포인터를 가상 기기 프로세스로 되돌려주는 것일 수 있다. 복수의 물리적 CPU를 가지는 컴퓨팅 시스템에서, 가상 기기 환경이 실행되는 물리적 CPU에 하드웨어를 통하여 인터럽트가 지시될 수 있다.

본 발명의 추가적인 특징 및 이점은 첨부된 도면을 참조하여 이루어지는 예시적인 실시예의 이하의 상세한 설명으로부터 보다 명백해질 수 있다.

첨부된 청구범위는 특이성을 갖는 본 발명의 특징을 설명하지만, 본 발명은 그 목적 및 장점과 함께, 첨부 도면을 참조하여 설명되는 다음의 상세한 설명으로부터 잘 이해될 수 있다.

다수의 소프트웨어 애플리케이션 및 오퍼레이팅 시스템은 추가적 기능, 서비스 또는 능력을 최종 사용자에게 제공하는 확장물에 의존한다. 종종 사용되는 하나의 확장물은 장치 드라이버로서 알려져 있고, 이것은 일반적으로 오퍼레이팅 시스템인 호스트 소프트웨어 애플리케이션과 하드웨어 장치 간의 인터페이스를 제공할 수 있다. 다른 확장물으로는 웹 브라우저 소프트웨어 애플리케이션을 위한 애플릿 및 플러그-인, 필터, 이미지 편집 소프트웨어 애플리케이션을 위한 효과 및 플러그-인, 및 오디오/비디오 소프트웨어 애플리케이션을 위한 코덱이 있다.

확장물 및 다른 소프트웨어 애플리케이션에게 가상 기기 환경 내로부터 하드 웨어로의 직접적인 액세스를 제공하는 이하 기술된 실시예는 가상 기기 설계를 간소화하고, 가상 기기 환경 내로부터 사용자가 하드웨어 장치의 더 넓은 영역을 액세스할 수 있도록 하는 것을 포함하는 것을 이용할 수 있다. 가상 기기 환경 내로부터 하드웨어로의 직접적인 액세스를 제공하는 추가적인 이점은 오퍼레이팅 시스템 장치 드라이버를 포함하는 하나 이상의 확장물을 호스트 소프트웨어 애플리케이션 또는 오퍼레이팅 시스템으로부터 장애 고립시키는 능력이다. 이러한 경우에, 고립된 확장물은 가상 기기 환경 내에서 실행될 수 있는데, 이 환경은 장애 고립을 제공하지만 적절하게 동작하기 위하여 하나 이상의 하드웨어 장치로의 직접적인 액세스를 유지할 필요도 있다. 따라서, 상세한 설명은 확장물이 하나 이상의 가상 환경 내에서 실행됨으로써 자신의 호스트 프로세스로부터 장애 고립될 수 있는 실시예의 설명으로 시작한다. 계속하여, 상세한 설명은 확장물, 또는 다른 소프트웨어 애플리케이션이 가상 기기 환경에서 실행될 때 하나 이상의 하드웨어 장치를 직접적으로 액세스할 수 있는 실시예의 설명을 계속한다.

확장물은 자신의 호스트 소프트웨어 애플리케이션과 밀접하게 상호동작하기 때문에, 확장물에 의해 도입된 불안정성은 호스트 소프트웨어 애플리케이션 전체를 사용할 수 없게 할 수 있다. 일반적으로, 확장물은 호스트 소프트웨어 애플리케이션에 의해 사용될 수 있는 하나 이상의 애플리케이션 프로그램 인터페이스(API)를 통해 자신의 능력으로의 액세스를 제공한다. 확장물이 자신의 기능을 노출하는 API는 일반적으로 "서비스 API"로 지칭된다. 확장물은 추가 정보, 자원 등이 필요하면, 일반적으로 "지원 API"로 지칭되는 하나 이상의 API를 통해 호스트 소프트웨 어 애플리케이션으로부터 그것을 요구할 수 있다. 확장물 또는 호스트 소프트웨어 애플리케이션이 서비스 또는 지원 API를 부적절하게 사용하거나, 비문서화된 또는 비지원된 API에 액세스하기를 시도하면, 임의의 결과하는 에러 또는 의도하지 않은 결과가 불안정성을 초래할 수 있다. 확장물은 일반적으로 자신의 호스트 소프트웨어 애플리케이션과 동일한 프로세스 내에서 동작하기 때문에, 그 프로세스 내에서 실행 중인 하나 이상의 확장물이 불안정성을 도입할 때, 호스트 소프트웨어 애플리케이션이 적절하게 계속해서 동작하는 것은 매우 어려울 수 있다.

확장물이 별개의 프로세스에서 실행되어, 확장물에 의해 도입된 임의의 불안정성이 호스트 소프트웨어 애플리케이션의 프로세스로부터 독립적인 프로세스에 고립될 수 있다면, 호스트 소프트웨어 애플리케이션은 불안정한 확장물에도 불구하고 적절히 동작하도록 진행될 수 있다. 오퍼레이팅 시스템과 같은 다수의 확장물을 호스트할 수 있는 소프트웨어 애플리케이션에 있어서, 실패 확률은 사용되는 각각의 추가적 확장물에 따라 급격히 증가하기 때문에, 각각의 확장물을 고립하는 것은 오퍼레이팅 시스템의 전체 신뢰도를 매우 향상시킬 수 있다. 또한, 확장물을 고립시키는 것은 애플리케이션 제작자가 자신의 알고리즘 내의 불안정성의 원천을 식별하고 제거하는 데 집중하게 한다. 따라서, 본 발명의 실시예는 호스트 소프트웨어 애플리케이션으로부터 확장물을 고립시키면서, 계속해서 호스트 소프트웨어 애플리케이션에 확장물의 이점을 제공한다.

요구되는 것을 아니지만, 본 발명은 컴퓨팅 장치에 의해 실행되는 프로그램 모듈과 같은 컴퓨터-실행가능 명령어의 일반적 문맥에서 설명될 것이다. 일반적으 로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 분산 컴퓨팅 환경에서, 태스크는 통신 네트워크를 통해 링크되어 있는 원격 프로세싱 장치에 의해 수행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 컴퓨터 저장 장치 및/또는 매체 둘 다에 위치될 수 있다. 본 분야에 숙련된 기술자는, 본 발명이 다수의 상이한 컴퓨팅 장치와 함께 개별적으로 또는 분산 컴퓨팅 환경의 일부분으로서 실시될 수 있으며, 그러한 장치로는 핸드-헬드 장치, 멀티-프로세서 시스템, 마이크로프로세서 기반 또는 프로그램가능한 전자기기, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등이 있다는 것을 이해할 것이다.

도 1을 참조하면, 본 발명이 구현될 수 있는 예시적인 컴퓨팅 장치(100)가 도시되어 있다. 컴퓨팅 장치(100)는 적합한 컴퓨팅 장치의 일례일 뿐이며, 본 발명의 사용 또는 기능의 범주에 대해 어떠한 제한도 제시하지 않는다. 또한, 컴퓨팅 장치(100)는 도 1에 도시된 주변장치들 중 임의의 하나 또는 그 조합과 관련하여 어떠한 의존성 또는 요구사항을 갖는 것으로 해석되어서는 안된다.

컴퓨터 장치(100)의 컴포넌트는 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 프로세싱 유닛(120)에 연결하는 것을 포함하여 다양한 시스템 컴포넌트드를 연결시키는 시스템 버스(121)를 포함할 수 있지만, 이것으로 제한되는 것은 아니다. 시스템 버스(121)는 메모리 버스 또는 메모리 제어기, 주변장치 버스, 및 다양한 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스를 포함하는 몇몇 유형의 버스 구조 중 임의의 것일 수 있다. 예를 들어, 그러한 아키텍처로는, ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architechture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Associate) 로컬 버스, 및 메자닌 버스로도 알려진 PCI(Peripheral Component Interconnect) 버스가 있지만, 이것으로 제한되는 것은 아니다. 또한, 프로세싱 유닛(120)은 하나 이상의 물리적 프로세서를 포함할 수 있다.

컴퓨팅 장치(100)는 일반적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터 장치(100)에 의해 액세스될 수 있는 임의의 사용가능한 매체일 수 있고, 휘발성과 비휘발성 매체, 분리형과 비분형 매체 둘 다를 포함한다. 예를 들어, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성과 비휘발성, 분리형과 비분리형 매체 둘 다를 포함한다. 컴퓨터 저장 매체로는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 다른 광 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 다른 자기 저장 장치, 또는 요구된 정보를 저장하는 데 사용될 수 있고 컴퓨팅 장치(100)에 의해 액세스될 수 있는 임의의 다른 매체가 있지만, 이것으로 제한되는 것은 아니다. 통신 매체는 일반적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 반송파 또는 다른 전송 매커니즘과 같은 변조된 데이터 신호로 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 내의 정보를 인코딩하는 방 식으로 설정 또는 변경된 특징 중 하나 이상을 갖는 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크 또는 직접-유선 접속과 같은 유선 매체, 및 음향, RF, 적외선 및 다른 무선 매체와 같은 무선 매체를 포함한다. 상술된 것 중 임의의 것의 조합도 컴퓨터 판독가능 매체의 범주 내에 포함되어야 한다.

시스템 메모리(130)는 판독 전용 메모리(ROM; 131) 및 랜덤 액세스 메모리(RAM; 132)와 같은 휘발성 및/또는 비휘발성 메모리의 형태의 컴퓨터 저장 매체를 포함한다. 개시 구동 동안과 같은 컴퓨터(110) 내의 구성요소들 사이에서 정보를 전송하는 것을 돕는 기본 루틴을 포함한 기본 입/출력 시스템(133; BIOS)은, 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로, 즉시 액세스가능하고/액세스가능하거나 현재 프로세싱 유닛(120)에 의해 동작하고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예를 들어, 도 1은 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 다른 프로그램 모듈(136) 및 프로그램 데이터(137)를 도시하고 있지만, 이것으로 제한되는 것은 아니다.

컴퓨팅 장치(100)는 또한, 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 예를 들어, 도 1은 비분리형, 비휘발성 자기 매체로부터 판독하고 그곳에 기록하는 하드 디스크 드라이브(141), 분리형, 비휘발성 자기 디스크(152)로부터 판독하고 그곳에 기록하는 자기 디스크 드라이브(151), 및 CD ROM 또는 다른 광 매체와 같은 분리형, 비휘발성 광 디스크(156)로부터 판독하고 그곳에 기록하는 광 디스크 드라이브(155)를 도시한다. 예시적인 오퍼레이팅 환경에서 사용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매 체로는, 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고체 상태 RAM, 고체 상태 ROM 등이 있지만, 이것으로 제한되는 것은 아니다. 하드 디스크 드라이브(141)는 일반적으로, 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 일반적으로, 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

상술되고 도 1에 도시된 드라이브 및 그와 관련된 컴퓨터 저장 매체는 컴퓨팅 장치(100)를 위한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 다른 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로 도시되어 있다. 이러한 컴포넌트들은 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 다른 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일하거나 상이할 수 있음을 유의한다. 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146) 및 프로그램 데이터(147)는 적어도 그들이 상이한 복사본이라는 것을 나타내기 위해 여기에서 상이한 번호가 부여된다.

사용자는 키보드(162), 및 주로 마우스, 트랙볼 또는 터치패드로 지칭되는 포인팅 장치(161)와 같은 입력 장치를 통해 명령 및 정보를 컴퓨팅 장치(100)에 입력할 수 있다. 다른 입력 장치(도시되지 않음)로는 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너 등이 있다. 이러한 입력 장치 및 그 외 입력 장치는 시 스템 버스에 연결되어 있는 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)에 접속될 수도 있고, 병렬 포트, 게임 포트 또는 USB(universal serial bus)와 같은 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 접속될 수 있다. 모니터 외에, 컴퓨터는 출력 주변장치 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196)와 같은 다른 주변 출력 장치도 포함할 수 있다.

인터페이스 기술은 시간이 지남에 따라 개선될 수 있기 때문에, 몇몇 컴퓨팅 장치는 레가시 장치와의 역방향 호환성을 제공하기 위해 레가시 인터페이스를 포함할 수 있다. 도 1의 컴퓨팅 장치(100)는 직렬 포트, 병렬 포트, 모뎀 포트 등을 포함하는 다수의 인터페이스 중 임의의 것일 수 있는 레가시 인터페이스(198)로 도시된다. 레가시 인터페이스(198)는 컴퓨팅 장치(100)가 프린터, 스캐너, 오실로스코프, 함수 생성기, 또는 임의의 다른 유형의 입력 또는 출력 장치일 수 있는 레가시 장치(199)와 같은 레가시 장치와 통신할 수 있게 한다. 본 분야에 숙련된 기술자에 의해 알려진 바와 같이, 대부분의 최신 입력 또는 출력 장치는 USB 포트 또는 IEEE(1394) 포트와 같은 새로 개발된 표준에 의존하는 인터페이스를 통해 인터페이스한다. 그러나, 레가시 장치는 그러한 인터페이스를 가질 것 같지 않기 때문에, 컴퓨팅 장치(100)와 통신하기 위하여 레가시 인터페이스에 의존해야 한다.

컴퓨팅 장치(100)는 하나 이상의 원격 컴퓨터로의 논리 접속을 사용하여 네트워크 환경에서 동작할 수 있다. 도 1은 원격 컴퓨팅 장치(180)로의 일반적 네트 워크 접속(171)을 도시한다. 일반적 네트워크 접속(171)은 LAN(Local Area Network), WAN(Wide-Area Network), 무선 네트워크, 이더넷 프로토콜, 토큰-링 프로토콜 또는 다른 논리적, 물리적 프로토콜에 따르는 네트워크, 인터넷 또는 월드 와이드 웹을 포함하는 무선 네트워크를 포함하여, 매우 상이한 유형의 네트워크 및 네트워크 접속들 중 임의의 것일 수 있다.

네트워크 환경에서 사용될 때, 컴퓨팅 장치(100)는 유선 또는 무선 네트워크 인터페이스 카드, 모뎀 또는 유사한 네트워크 장치일 수 있는 네트워크 인터페이스 또는 어댑터(170)를 통해 일반 네트워크 접속(171)에 접속된다. 네트워크 환경에서, 컴퓨팅 장치(100)와 관련하여 설명된 프로그램 모듈, 또는 그 일부는 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며 컴퓨터들 간의 통신 링크를 설립하는 다른 수단이 사용될 수 있음을 이해할 것이다.

다음의 설명에서, 본 발명은 달리 표시되지 않는 경우, 하나 이상의 컴퓨팅 장치에 의해 수행되는 행위 및 동작의 기호 표현을 참조하여 설명될 것이다. 그러한 것으로서, 때때로 컴퓨터-실행가능한 것으로 지칭되는 그러한 행위 및 동작은 구조화된 형식의 데이터를 나타내는 전자 신호의 컴퓨팅 장치의 프로세싱 유닛에 의한 조작을 포함한다는 것을 이해할 것이다. 이 조작은 데이터를 변형하거나, 그것을 컴퓨팅 장치의 메모리 시스템 내의 위치에서 유지하는데, 이것은 본 분야에 숙련된 기술자가 잘 알고 있는 방식으로 컴퓨팅 장치의 동작을 재구성 또는 변경한다. 데이터가 유지되는 데이터 구조는 데이터의 포맷에 의해 정의된 특정 속성을 갖는 메모리의 물리적 위치이다. 그러나, 본 발명이 상술된 문맥에서 설명되고 있 지만, 본 분야에 숙련된 기술자는 이후에 설명되는 다양한 행위 및 동작이 하드웨어에서도 구현될 수 있음을 이해하는 것과 같이, 본 발명은 제한적인 것이 아니다.

도 2를 참조하면, 호스트 소프트웨어 애플리케이션으로부터 확장물을 고립하기 위해 본 발명의 실시예가 제시하는 하나의 메카니즘이 도시된다. 도 2에 도시된 바와 같이, 호스트 프로세스(201)는 확장물(215) 자체 대신에 프록시(205)를 호출할 수 있다. 확장물(215)은 호스트 프로세스(201)와는 별개인 가상 프로세스(211)에서 호스트될 수 있다. 가상 프로세스(211)는 적어도 호스트 소프트웨어 애플리케이션이 제공할 수 있는 지원 API(203)와 비슷한 가상 지원 API(213)를 제공할 수 있다는 점에서, 호스트 프로세스(201)를 에뮬레이트할 수 있다. 따라서, 가상 프로세스(211)에서 실행 중인 확장물(215)은 원래 지원 API(203)를 사용하는 것과 동일한 방식으로 가상 지원 API(213)를 사용할 수 있다.

본 발명의 실시예가 제시하는 프록시(205)에 대한 하나의 설계는, 적어도 프록시(205)가 확장물(215)에 의해 제공된 서비스 API와 비슷한 서비스 API를 제공할 수 있다는 점에서, 확장물(215)을 에뮬레이트하는 것일 수 있다. 호스트 프로세스(201)는 프록시(205)에 의해 제공된 API를 사용하여, 확장물(215) 자체에 의해 제공된 서비스 API를 사용하는 것과 동일한 방식으로 확장물의 기능에 액세스할 수 있다. 그러나, 도 2에 도시되는 바와 같이, 프록시(205)는 그러한 서비스 API를 사용하여 호스트 프로세스(201)로부터 요구를 수신할 때, 호스트로부터 관련 정보를 수집할 수 있고, 그 정보를 가상 프로세스(211) 내에서 실행하고 있는 확장물(215)에 전달할 수 있다.

본 발명의 실시예가 제시하는 프록시(205)에 대한 또 다른 설계는, 호스트 프로세스(201)와 인터페이스하고, 호스트 프로세스의 특정 기능을 번역 또는 가로채고, 확장물(215)을 사용하여 호스트 프로세스(201)의 기능을 확장하는 것이다. 예를 들어, 확장물(215)은 보기 드문 파일 시스템 포맷 또는 레가시 파일 시스템 포맷을 사용하는 파일 저장 장치와 같은 특정 유형의 파일 저장 장치로의 액세스를 제공할 수 있다. 그러한 경우에, 프록시(205)는 호스트 프로세스(201) 내에서 파일 액세스 명령어를 검출하고 그러한 명령어를 가로채도록 설계될 수 있다. 다음으로, 프록시(205)는 레가시 파일 시스템 포맷을 사용하는 파일 저장 장치 내의 파일에 액세스할 수 있는 확장물(215)에 적절한 정보를 전달할 수 있다. 다음으로, 정보는 확장물(215)로부터 프록시(205)로 리턴될 수 있고, 프록시(205)는 그 정보를 호스트 프로세스(201)에 제공할 수 있다. 이러한 방법으로, 프록시(205)는 그러한 확장된 기능을 가능하게 하도록 설계되지 않았더라도, 예를 들어, 호스트 프로세스(201)가 레가시 파일 시스템 포맷으로 저장된 데이터에 액세스할 수 있게 함으로써, 호스트 프로세스(201)의 기능을 확장할 수 있다. 따라서, 프록시(205)는 호스트 프로세스(201)와 인터페이스하도록 설계된 기존 확장물에 기초할 필요가 없으며, 오히려, 호스트 프로세스와 임의의 확장물 간의 개체(shim)로서 동작하도록 설계될 수 있다.

프록시(205)가 기존 확장물을 에뮬레이트하도록 설계되는지, 아니면 임의의 확장물에 대한 개체(shim)로서 동작하는지에 상관없이, 프록시(205)는 호스트 프로세스(201)에 대한 확장물 수행 작업을 위해 적절한 정보를 확장물(215)에 전달할 수 있다. 본 발명의 실시예가 제시하는 프록시(205)에서 확장물(215)로 정보를 전달하는 한가지 방법은, 프록시(205)가 확장물(215)과 집적 통신하는 것이다. 그러한 경우, 프록시(205) 자체는 확장물(215)의 적절한 서비스 API를 호출할 수 있다. 본 발명의 실시예가 제시하는 요구를 전달하는 다른 방법은, 프록시(205)가 가상 프로세스(211) 내에서 실행하는 스터브(217)와 통신하는 것이다. 스터브(217)는 확장물(215)의 적절한 서비스 API를 호출할 수 있다. 본 분야에 숙련된 기술자들에 의해 알려진 바와 같이, 몇몇 확장물은 인터-프로세스 통신을 통해 수신된 요구를 적절히 처리하지 못할 수 있다. 그러한 곤란성을 피하기 위해, 가상 프로세스(211) 내의 스터브(217)와 같은 스터브가, 확장물(215)이 인터-프로세스 통신 보다, 인트라-프로세스 통신을 통해 그 서비스 API를 통해 요구를 수신할 수 있는 메카니즘을 제공하는 데 사용될 수 있다.

확장물(215)은 호스트 프로세스(201)로부터 요구를 수신하면, 그 요구에 응답하도록 진행될 수 있다. 요구의 특성에 따라, 확장물(215)은, 주로 지원 API(203)를 통해 호스트 프로세스(201)에 의해 제공되지만, 이제는 가상 지원 API(213)를 통해 가상 프로세스(211)에 의해 제공될 수 있는 하나 이상의 함수에 액세스할 수 있다. 이하에서 더 상세히 설명되는 바와 같이, 호스트의 요구의 특성에 따라, 확장물(215)은 컴퓨팅 시스템(100)의 자원에 직접적으로 액세스하거나 컴퓨팅 시스템에 접속된 하드웨어 장치에 직접적인 방법으로 액세스해야 할 필요가 있을 수 있다. 그러한 경우, 이러한 자원으로의 액세스를 확장물(215)에 제공하는 설비가 이루어지면서, 여전히 호스트 프로세스(201)로부터 확장물(215)을 고립시킨 다.

의도된 고립을 성취하기 위해서는, 호스트 프로세스(201) 및 가상 프로세스(211)와 같은 2개의 별개의 프로세스를 갖는 것만으로는 충분하지 않다. 따라서, 본 발명의 실시예는, 프록시(205)가 확장물(215)로부터의 부정확한 응답, 또는 확장물의 일부분에 대한 부적절한 행위가 호스트 프로세스(201)에 영향을 미치는 것을 방지하기 위한 방법으로 설계될 수 있다는 것을 제시한다. 예를 들어, 본 발명의 실시예가 제시하는 하나의 메카니즘에서, 프록시(205)는 확장물(215)이 제공하는 서비스 API를 엄격하게 준수하도록 설계될 수 있다. 따라서, 확장물(215)이 호스트가 기대하는 형태 또는 타입이 아닌 호스트 프로세스(201)에 데이터를 리턴하려고 하면, 프록시(205)는 잠재적인 문제를 식별하여 그 데이터를 호스트 프로세스에 전달하지 않을 수 있다.

본 발명의 실시예가 제시하는 또 다른 메카니즘에서, 프록시(205)는 호스트 프로세스(201)에 불안정성을 도입하는 것을 방지하기 위하여, 리턴되는 데이터에 추가적인 지능을 적용할 수 있다. 예를 들어, 확장물(215)이 치명적인 에러 및 실패를 겪으면, 프록시(205)는 타임아웃 카운터 또는 유사한 메카니즘을 유지하여, 확장물의 실패를 검출하고, 예를 들어, 에러 응답을 제공함으로써 또는 호스트 프로세스가 예를 들어, 사용자의 작업 산출 손실없이 적절하게 퇴화(degrade)되게 함으로써, 호스트 프로세스(201)에게 그 에러를 알릴 수 있다. 프록시(205)는 또한, 호스트 프로세스(201)가 확장물(215)에 제공했던 임의의 제어를 리턴하여, 확장물의 실패가 호스트 프로세스의 실행을 방해하는 것을 방지할 수 있다. 예를 들어, 프록시(205)는 기저 오퍼레이팅 시스템이 가상 프로세스(211)를 종료하고 호스트 프로세스(201)에 제어를 리턴하기를 요구할 수 있다. 다르게는, 프록시(205)는 가상 프로세스(211)의 일부분인 전용 코드를 사용하여, 가상 프로세스에게 실패가 명백하게 발생했다는 것을 알리고, 가상 프로세스가 종료하고 호스트 프로세스(201)에게 제어를 리턴하기를 요구할 수 있다.

그러나, 확장물(215)은 태스크가 요구된 것이 무엇이든 그것을 적절히 완료하면, 서비스 API에 의해 지정된 방법으로 호스트 프로세스(201)에 의해 예상될 수 있는 임의의 결과를 리턴할 수 있다. 따라서, 예를 들어, 그 결과가 요구가 성공되었고 소정의 변수로 호출 프로그램에 다시 전달될 것임을 나타내면, 확장물(215)은 이 변수를 스터브(217)에, 또는 직접 프록시(205)에 다시 전달할 수 있다. 여기에서, 변수는, 원래 프록시(205)에 의한 호출이 생성된 호스트 프로세스에 리턴될 수 있다. 그러한 방법으로, 프록시(205)는 적어도 호스트 프로세스(201)에 관해서는, 확장물(215)로부터 구별할 수 없게 될 수 있다. 물론, 본 분야에 숙련된 기술자에 의해 알려진 바와 같이, 몇몇 확장물은 임의의 결과를 리턴할 필요가 없을 수 있고, 그러한 경우에는, 리턴된 값을 수용하기 위한 설비도 구현될 필요가 없다.

도 2에 도시되어 있는 바와 같이, 확장물(215)은 가상 프로세스(211)에서 동작한다. 따라서, 확장물(215)의 액션이 불안정성을 야기하면, 그 불안정성은 가상 프로세스(211) 내부에 포함되기 쉬울 것이다. 그러한 경우에, 오퍼레이팅 시스템, 또는 프록시(205)와 같은 몇몇 다른 코드는 가상 프로세스(211)에서 에러를 검출하 고 그것을 종료하거나 재시작을 시도할 수 있다. 어느 이벤트에서든, 불안정성은 호스트 프로세스(201)에 영향을 주지 않을 것이고, 따라서 사용자에게 해로운 실패가 되게하지 않을 것이다. 따라서, 상술된 메카니즘은, 호스트 프로세스(201)에 의해 사용되고 있는 확장물(215)이 실패하거나 불안정하게 되더라도 호스트 프로세서(201)가 계속해서 적절히 동작하게 한다.

상술된 바와 같이, 프록시(205)는 호스트 프로세스에서 실행되는 경우의 확장물(215)과 동일한 방법으로, 서비스 API를 호스트 프로세스(201)에 제공할 수 있다. 본 발명의 실시예가 제시하는 하나의 매커니즘에서, 프록시(205)는 확장물(215)에 의해 구현된 소정의 서비스 API에 기초하여 생성될 수 있다. 그러나, 본 분야에 숙련된 기술자에 의해 알려진 바와 같이, 확장물 및 호스트 소프트웨어 애플리케이션이 상호동작할 수 있는 서비스 API는, 소프트웨어 애플리케이션 제작자와 확장물 제작자가 종종 상이한 엔티티이기 때문에 일반적으로 미리 알려져 있다. 확장물은 설치될 때, 호스트 소프트웨어 애플리케이션, 또는 등록 데이터베이스(221)와 같은 적절한 정보 저장소에 자신을 등록하고, 자신이 지원하는 서비스 API를 나타낼 수 있다. 이 정보를 사용하여, 호스트 소프트웨어 애플리케이션 또는 기저 오퍼레이팅 시스템은 호스트 소프트웨어 애플리케이션이 그 서비스 API 중 하나를 사용하려 할 때 적절한 확장물의 위치를 알아낼 수 있다. 이 정보는 또한, 확장물(215)에 의해 지원된 서비스 API의 완전한 세트를 나타내기 때문에 프록시(205)를 생성하는 데 사용될 수 있다. 프록시(205)의 생성은 또한, 이하에 더 상세히 설명되는 방법으로, 예를 들어, 등록 데이터베이스(221) 내의 엔트리를 변경 할 수 있다.

본 발명의 실시예가 제시하는 또 다른 메카니즘은, 소정의 서비스 API의 전체 세트에 기초하는 요구를 수용할 수 있는 "수퍼 프록시(super proxy)"의 생성이다. 그러한 수퍼 프록시는 호스트 애플리케이션이 사용하려고 찾는 특정 서비스 API가 어느 것인지에 상관없이 호출될 수 있다. 그러한 경우에, 확장물(215)이 설치 시간에 수행할 수 있는 임의의 등록은 수퍼 프록시 또는 기저 지원 아키텍처의 등록을 포함할 수 있어서, 수퍼 프록시는 특정 서비스 API가 호스트 소프트웨어 애플리케이션에 의해 사용될 때 적절한 확장물(215)을 호출할 수 있다.

본 발명의 실시예가 제시하는 또 다른 추가 메카니즘은, 프록시(205)가 호스트 프로세스(201)에 제공하기 위해 찾는 확장된 기능에 기초하여 생성될 수 있다는 것이다. 따라서, 호스트 프로세스(201)에 의해 또는 그것 내에서 하나 이상의 함수를 검출하거나, 가로채거나 그것과 인터페이스하는 프록시(205)가 생성되어, 프록시는 확장물(215)의 기능의 이익을 호스트 프로세스에게 제공할 수 있다. 상술된 예를 이용하여, 프록시(205)는 호스트 프로세스(201)가 확장물(215)을 통해 레가시 파일 시스템에 액세스하도록 설계되면, 프록시는 호스트 프로세스에 의해 사용된 파일 액세스 및 유사 함수를 검출하고 가로채도록 설계될 수 있다. 프록시(205)는 또한, 확장물이 레가시 파일 시스템과 인터페이스할 수 있도록, 관련 정보를 그러한 파일 액세스 함수로부터 확장물(215)로 전송하도록 설계될 수 있다. 마찬가지로, 프록시(205)는 확장물(215)로부터 응답을 수용하고, 그것을 호스트 프로세스(201)가 호스트 프로세스의 채로챈 파일 액세스 함수에 관련된 적절한 응답으 로서 인식할 수 있는 포맷으로 변환하도록 설계될 수 있다.

몇몇 경우에, 지원 API(203)를 더 정확하게 반영하기 위해 가상 지원 API(213)를 수정하는 것이 바람직할 수 있다. 예를 들어, 가상 지원 API(213)는 프로세스의 식별자에 대해 질의되는 경우, 가상 프로세스(211)의 식별자를 리턴할 수 있다. 그러나, 가상 지원 API(213)가 호스트 프로세스(201)의 식별자를 리턴하는 것이 바람직할 수 있다. 그러한 경우에, 가상 지원 API(213)가 호스트 프로세스(201)로부터 정보를 액세스할 수 있게 하는 데에 "백 채널(back channel)", 또는 "사이드 채널(side channel)" 통신이 사용될 수 있다.

요구된 특정 확장물에 대해 적절한 프록시가 호출된 것을 확인하기 위해, 등록 데이터베이스 또는 유사 정보 저장소가 프록시(205)를 확장물(215)에 링크하는 데 사용될 수 있다. 상술된 바와 같이, 등록 데이터베이스(221) 또는 유사 정보 저장소는 확장물(215)을 호출하기 위한 파라미터를 결정하기 위해 호스트 프로세스(201) 또는 오퍼레이팅 시스템에 의해 참고될 수 있다. 그러나, 확장물(215) 자체를 식별하기 보다, 등록 데이터베이스(221)는 프록시(205)에 포인팅할 수 있다.

호스트 프로세스(201)가 프록시(205)를 호출하면, 프록시(205)는 가상 프로세스(211) 내에서 확장물(215)의 호출을 호출하거나 조정하도록 진행할 수 있다. 이하에 설명되는 바와 같이, 가상 프로세스(211)는 이미 동작가능할 수도 있고, 다양한 준비 상태에 있을 수도 있다. 가상 프로세스(211)가 이미 동작가능하지 않으면, 프록시(205)는 가상 프로세스(211)가 동작가능한 상태에 이르는 데 필요할 수 있는 단계의 완성을 조합할 수 있다. 가상 프로세스(211)가 동작가능하면, 프록시 (205)는 가상 프로세스(211)에게 확장물(215)을 호출할 것을 지시할 수 있다. 예를 들어, 프록시(205)는 확장물(215)의 위치에 대한 포인터를 제공하고, 호스트 프로세스(201)에 의해 사용된 동일하거나 유사한 파라미터를 전달할 수 있다. 또한, 확장물(215)이 백 채널 또는 사이드 채널 통신을 사용하는 것으로 결정되면, 확장물에 의해 사용된 임의의 추가 자원도 가상 프로세스(211) 내에서 호출될 수 있다.

가상 프로세스(211)가 확장물(215), 및 확장물에 의해 사용된 임의의 다른 코드를 호출하면, 프록시(205)는 필요시, 스터브(217)의 호출을 조정할 수 있다. 다르게는, 프록시(205)는 확장물(215)과의 통신 링크를 직접 설정할 수 있다. 스터브(217)가 사용되면, 프록시(205)는 가상 프로세스(211)에게 스터브(217)의 위치, 및 스터브를 호출하는 데 사용될 파라미터를 제공할 수 있다. 스터브(217)가 호출되면, 스터브 자체는 확장물(215)과의 통신 링크를 설정할 뿐만 아니라, 프록시(205)와의 통신 링크도 설정할 수 있다. 프록시(205)와 스터브(217) 또는 확장물(215) 간의 통신은 예를 들어, 알려진 원격 프로시저 호출(Remote Procedure Call; RPC) 메카니즘을 포함하는 임의의 유형의 인터-프로세스 또는 인트라-프로세스 통신 프로토콜을 사용할 수 있다. 사용되는 통신 프로토콜이 미리 결정될 수 있지만, 프록시(205)와 스터브(217) 또는 확장물(215)이 적절하게 통신할 수 있음을 보장하는 핸드쉐이킹 프로시저(handshaking procedure)가 구현될 수 있다.

몇몇 확장물은 호스트 프로세스에 의한 그들의 요구된 함수를 수행하는 사용자 모드 컨텍스트에 의존할 수 있기 때문에, 가상 환경에서의 확장물이 사용자 모드 컨텍스트를 제공받을 수 있는 메카니즘을 제공하는 것이 필요할 수 있다. 사용 자 모드 컨텍스트는 일반적으로, 메모리, 파일, 레지스트리 엔트리 등을 포함하는 프로세스의 자원의 전체 상태를 나타내어, 주어진 사용자 모드 컨텍스트 내의 특정 자원 참조가 정확한 한편, 그러한 동일한 참조가 특정 사용자 모드 컨텍스트의 외부로 전달되는 경우 부절절한 메모리 위치를 나타내거나 부정확하게 되도록 한다. 대량의 데이터를 수용하거나 리턴할 수 있는 확장물에 있어서, 종종, 데이터 자체를 송수신하는 것보다, 공통 사용자 모드 컨텍스트를 나타내는 메모리 참조를 송수신하는 것이 더 효과적이다. 따라서, 그러한 데이터 전달 스킴을 사용하는 확장물이 적절하게 동작할 경우, 가상 프로세스(211)와 호스트 프로세스(201) 간의 공통 사용자 모드 컨텍스트를 유지하는 것이 요구될 수 있다.

도 3을 참조하면, 호스트 프로세스(201)가 상세히 상술된 방식으로, 가상 프로세스(211 및 311)의 내부에서 실행되는 2개의 확장물, 즉, 확장물(215) 및 확장물(315)을 각각 호출하는 것으로 도시되어 있다. 프록시(205)는 상술된 바와 같이, 수퍼 프록시일 수 있고, 호스트 프로세스(201)로부터 확장물(215) 또는 확장물(315)로 요구를 송신할 수 있다. 다르게는, 도 3에 도시되지 않은 제2 프록시가 사용되어, 확장물(215 및 315) 각각이 호스트 프로세스(201) 내의 프록시와 일대일 관계를 가질 수 있도록 할 수 있다.

각각 호스트 프로세스(201), 가상 프로세스(211) 및 가상 프로세스(311)에 대응하는 호스트 프로세스 메모리(301) 및 가상 프로세스 메모리(302 및 303)를 포함하는 오퍼레이팅 시스템(134)도 도 3에 도시되어 있다. 도 3 및 도 4에 도시된 메카니즘은 호스트 프로세스(201) 및 가상 프로세스(211 및 311)의 기저가 되는 공 통 오퍼레이팅 시스템에 의존할 수 있지만, 가상 프로세스가 호스트 프로세스의 기저가 되는 오퍼레이팅 시스템(134)에 독립적으로 실행되더라도, 이하에 더 상세히 설명되는 추가 메카니즘은 호스트 프로세스와 가상 프로세스 간의 공통 사용자 모드를 제공할 수 있다. 호스트 프로세스(201) 및 가상 프로세스(211 및 311)가 도 3에 도시되어 있는 바와 같이, 공통 오퍼레이팅 시스템(134)을 공유하는 상황에서, 오퍼레이팅 시스템은 또한, 호스트 프로세스 메모리(301) 및 가상 프로세스 메모리(302 및 303)를 물리 RAM(132)의 세그먼트에 매핑하는 페이지 테이블 매핑(320)의 컬렉션을 포함할 수 있다. 도 3은 호스트 프로세스 메모리(301) 및 가상 프로세스 메모리(302 및 303)에 각각 대응하는 세그먼트(321, 322 및 323)를 도시하고 있지만, 본 분야에 숙련된 기술자는 세그먼트(321, 322 및 323)는 예시적인 것일 뿐이며, RAM의 물리적 세그먼트가 산재되기 쉽다는 것을 이해할 것이고, 도시된 방법으로 접근하지 않을 수 있다.

호스트 프로세스(201)와 가상 프로세스(211 및 311) 간의 공통 사용자 모드 컨텍스트를 유지하기 위하여, 오퍼레이팅 시스템(134) 또는 다른 지원 소프트웨어는 가상 프로세스(211 및 311)에 대한 호스트 프로세스(201)의 사용자 모드 컨텍스트를 포함하는 자원의 일부 또는 전부로의 액세스를 제공할 수 있다. 다음의 설명은 사용자 모드 컨텍스트의 메모리 자원 양태로의 공통 액세스를 제공하기 위한 메카니즘에 초점을 두고 있지만, 본 분야에 숙련된 기술자는 레지스트리 자원, 파일 자원 등을 포함하는 사용자 모드 컨텍스트를 포함할 수 있는 다른 자원에 대한 이러한 메카니즘의 적용성을 인식할 것이다.

본 발명의 실시예가 제시하는 사용자 모드 컨텍스트의 메모리 자원 양태로의 공통 액세스를 제공하기 위한 하나의 메카니즘에서, 오퍼레이팅 시스템(134) 또는 유사한 지원 소프트웨어는 호스트 프로세스 메모리(301)를 가상 프로세스 메모리(302 및 303)에 복사할 수 있다. 도 3에 도시된 바와 같이, 호스트 프로세스 메모리(301)를 가상 프로세스 메모리(302 및 303)에 복사하는 것은 RAM 세그먼트(321)를 새로운 RAM 세그먼트(322 및 323)에 물리적으로 복사하는 것을 의미한다. 다르게는, I/O 관리자가 호스트 프로세스 메모리(301)를 시스템 메모리의 상주 비페이지화된(nonpaged) 풀(pool)에 복사할 수 있고, 가상 프로세스(211 또는 311)에게 그 비페이지화된 풀로의 액세스를 제공할 수 있다.

확장물(215 또는 315)이 그 태스크를 완료하면, 가상 프로세스 메모리(302 또는 303)는 호스트 프로세스 메모리(301)와 다시 병합될 수 있다. 예를 들어, 프록시(205)는 임의의 차이를 결정하기 위해, 위치(322 및 323) 내의 가상 프로세스 메모리와 위치(321) 내의 호스트 프로세스 메모리 사이에서 바이트-대-바이트 비교 또는 더 심화된 매크로 레벨 비교일 수 있는 상이한 함수를 수행할 수 있다. 이러한 차이는 적절하고 확장물(215 또는 315)의 예상된 행위에 맞는 것으로서 검증될 수 있고, 호스트 프로세스 메모리(301)에 다시 복사되거나 프록시(205)를 통해 호스트 프로세스(201)에 사용가능해질 수 있다. 다르게는, I/O 관리자가 호스트 프로세스 메모리(301)를 시스템 메모리의 상주 비페이지화된 풀에 복사한 경우, I/O 관리자는 그 비페이지화된 풀을 호스트 프로세스 메모리에 다시 복사할 수 있다. 일반적으로, 그러한 복사는 요구 당 행해진다. 따라서, 전체 호스트 프로세스 메 모리(301)를 복사하기 보다, 본 발명의 실시예가 제시하는 더 효율적인 메카니즘은, 오퍼레이팅 시스템(134) 또는 다른 지원 소프트웨어가 확장물(215 또는 315)이 요구된 태스크를 수행하는 데 필요한 호스트 프로세스 메모리(301)의 버퍼만을 복사하는 것이다. 오퍼레이팅 시스템(134)의 I/O 관리자에 의해 수행될 때, 시스템 메모리의 비페이지화된 풀로의 그러한 버퍼-특정 복사는 "버퍼링된 I/O(Buffered I/O 또는 I/O Method Buffered"로 알려져 있다.

도 4를 참조하면, 본 발명의 실시예가 제시하는 사용자 모드 컨텍스트의 메모리 자원 양태로의 공통 액세스를 제공하기 위한 다른 메카니즘이 도시되어 있다. 특히, 도 4에 도시되어 있는 바와 같이, 호스트 메모리 프로세스(301)의 일부 또는 전부를 복사하기 보다, 오퍼레이팅 시스템(134)에 의해 유지되는 페이지 테이블 매핑(320)이 가상 프로세스 메모리(302 및 303)를, 호스트 프로세스 메모리(301)를 나타내는 데이터가 저장되어 있는 RAM(132) 내의 물리적 위치(321)에 전송하도록 수정될 수 있다. 데이터를 복사할 필요가 제거되기 때문에, 도 4에 도시된 메카니즘은 도 3에 도시된 메카니즘보다 더 효율적일 수 있다.

그러나, 확장물(215 및 315)이 호스트 프로세스 메모리(301)를 포함하는 물리적 세그먼트(321)에 영향을 줄 수 있으면, 확장물의 일부분에 대한 에러 또는 불안정성은 호스트 프로세스(201) 자체의 에러 또는 불안정성으로 귀착할 수 있다. 따라서, 이 가능성을 최소화하기 위해, 페이지 테이블 매핑은 "판독전용" 방식으로 수정되어, 가상 프로세스(211 및 311)가 판독만을 할 뿐 수정하지 못하게 되도록 물리적 메모리(321)에 포인팅될 수 있다. 따라서, 가상 프로세스는 호스트 프로세 스의 메모리를 수정하는 것이 허용되지 않기 때문에, 가상 프로세스(211 및 311)에서 실행하고 있는 확장물의 일부분에 대한 임의의 에러 또는 불안정성은 호스트 프로세스(201)에 에러 또는 불안정성을 도입할 수 없다.

상술된 바와 같이, 도 4의 메카니즘이 제시하는 페이지 테이블 매핑(320)에 대한 수정은 요구 당 수행될 수 있다. 그러나, 단지 하나의 가상 프로세스가 존재하면, 페이지 테이블 매핑(320)은 심지어 사용자 모드 컨텍스트를 요구하지 않는 요구에 대해서도 계속해서 RAM(132)의 물리적 세그먼트(321)를 포인팅할 수 있다. 상술된 페이지 테이블 매핑의 수정은 일반적으로 "버퍼링도 다이렉트도 아닌 I/O(Neither Buffered Nor Direct I/O 또는 I/O Method Neither"로 알려져 있다.

본 발명의 실시예가 제시하는 사용자 모드 컨텍스트의 메모리 양태로의 공통 액세스를 제공하기 위한 또 다른 메카니즘은, 도 3 및 도 4에 도시된 대안들의 혼성일 수 있다. 특히, 가상 프로세스(211 및 311)는 상술된 바와 같이, 물리적 메모리(321)로의 판독-전용 액세스를 제공받을 수 있다. 그러나, 확장물(215) 또는 확장물(315)이 데이터를 다시 메모리에 기록할 필요가 있으면, "카피-온-라이트(copy-on-write)"가 수행될 수 있다. 본 분야에 숙련된 기술자가 알고 있는 바와 같이, 카피-온-라이트는 데이터에 수정을 기록하기 전에, 수정되는 데이터를 새로운 위치에 복사할 수 있다. 따라서, 확장물(215) 또는 확장물(315)이 데이터를 메모리(321)에 다시 기록할 필요가 있으면, 메모리(321)의 일부 또는 전부는 도 3에 도시된 322 또는 323과 같은 새로운 위치에 복사될 수 있고, 그 후, 확장물(215) 또는 확장물(315)은 메모리(322 또는 323) 내의 복사된 데이터를 수정할 수 있다. 그러한 방식으로, 가상 프로세스는 호스트 프로세스의 메모리를 수정하는 것이 허용되지 않기 때문에, 가상 프로세스(211 및 311)에서 실행 중인 확장물에 의해 도입된 임의의 에러 또는 불안정성은 호스트 프로세스(201)에 영향을 주지 못할 것이다.

프록시(205)는 상술된 카피-온-라이트 메카니즘을 사용하여 확장물(215) 또는 확장물(315)에 의해 편집되었을 수 있는 메모리의 세그먼트들을 추적할 수 있다. 프록시는 그러한 메모리 세그먼트에 액세스할 때, 위치(321) 대신에 위치(322 또는 323)를 적절히 참조할 수 있다. 위치(322 또는 323)에 저장된 데이터가 확장물(215 또는 315)의 예상된 행위와 맞으면, 프록시(205)는 예를 들어, 그 데이터를 호스트 프로세스 메모리(301)에 복사함으로써, 또는 위치(322 또는 323)를 호스트 프로세스에 전달함으로써 그 데이터가 호스트 프로세스(201) 내에서 사용되게 할 수 있다. 따라서, 상술된 고립은 프록시(205)가 수정된 데이터에 액세스하는 것을 허용하면서 수행될 수 있다.

상술된 바와 같이, 도 2의 가상 프로세스(211)와 같은 확장물을 호스트할 수 있는 가상 프로세스의 개시는, 프록시가 확장물(215) 대신에 호스트 프로세스(201)에 의해 호출된 후에, 프록시(205)에 의해 조정될 수 있다. 본 발명의 실시예가 제시하는 하나의 유형의 가상 프로세스는, 호스트 프로세스와 동일한 오퍼레이팅 시스템(134) 상에서 실행 중인 호스트 프로세스(201)의 복사본이다. 그러한 가상 프로세스는, 호스트 프로세스를 포크(fork)하고 복제(clone)된 프로세스를 가상 프로세스로서 사용함으로써 생성될 수 있다. 다르게는, 오퍼레이팅 시스템은 어느 소프트웨어 애플리케이션이 처음에 호출되어 호스트 프로세스(201)를 생성했던지 간에 그 소프트웨어 애플리케이션을 다시 개시하도록 지시받을 수 있다. 따라서, 예를 들어, 호스트 프로세스(201)가 웹 브라우저이면, 가상 프로세스(211)는, 웹 프라우저 애플리케이션을 다시 개시하여 별개의 프로세스를 생성함으로써, 또는 현재 실행 중인 웹 브라우저 프로세스를 포크함으로써 생성될 수 있다.

본 발명의 실시예가 제시하는 또 다른 유형의 가상 프로세스는 가상 기기 환경의 문맥에서 생성될 수 있다. 가상 기기는 확장물(215)이 장치 드라이버, 또는 오퍼레이팅 시스템에 의해 사용된 다른 확장물인 경우, 최적의 해결책을 제공할 수 있다. 오퍼레이팅 시스템을 사용하여, 포크 또는 재실행함으로써 자신의 또 다른 복사본을 생성하여 가상 프로세스로서 동작하는 것이 가능할 수 있지만, 더 좋은 해결책은 가상 기기를 개시하고 그 가상 기기의 환경에서 오퍼레이팅 시스템을 부팅하여 하나 이상의 확장물을 호스트하기 위한 가상 프로세스로서 동작하는 것이다. 그러한 메카니즘은 더 양호한 고립을 제공할 수 있고, 하나의 오퍼레이팅 시스템이 다른 오퍼레이팅 시스템에 대해 설계된 확장물을 사용하게 할 수 있다. 예를 들어, 더 새로운 버전의 오퍼레이팅 시스템에 대해 업데이트되지 않은 레가시 드라이버가, 가상 기기 환경에서 실행 중인 더 오래된 버전의 오퍼레이팅 시스템 내에서 호스트될 수 있다. 그러한 방식으로, 확장물의 특징 및 능력은 더 새로운 오퍼레이팅 시스템의 사용자에게 여전히 사용가능할 수 있는 한편, 더 새로운 오퍼레이팅 시스템을, 레가시 확장물에 의해 야기될 수 있는 임의의 불안정성으로부터 보호할 수 있다. 가상 기기를 사용함으로써, 또는 상술된 포크 또는 재실행을 수 행함으로써, 가상 프로세스(211)는 개별로 지원 함수를 설명할 필요없이, 호스트 프로세스(201)와 동등한 지원 API를 제공할 수 있다.

기저 오퍼레이팅 시스템(134)으로부터 지원을 받는 가상 프로세스(211 및 311)와 달리, 본 분야에 숙련된 기술자에 의해 알려진 바와 같이, 가상 기기는 일반적으로 이러한 방식으로 오퍼레이팅 시스템을 이용하지 않는다. 대신에, 전체 오퍼레이팅 시스템을 통해 전달된 각각의 가상 기기 명령어를 갖는 수행 손실을 피하기 위해, 가상 기기는, 제한된 오퍼레이팅 시스템 기능을 제공할 수 있고 가상 기기 환경에서 어느 오퍼레이팅 시스템이 실행될 컴퓨팅 시스템의 기저 하드웨어를 축약할 수 있는 하이퍼바이저(hipervisor)에 의존할 수 있다. 그러한 하이퍼바이저를 사용함으로써, 가상 기기는 훨씬 더 효율적으로 동작할 수 있다. 그러나, 하이퍼바이저를 사용한 결과로서, 가상 기기 프로세스가 컴퓨팅 장치의 프로세서 상에서 실행될 수 있기 전에, 그 컴퓨팅 장치의 오퍼레이팅 시스템은 제거될 수 있고, 그 오퍼레이팅 시스템의 기반(underpinning)이 저장될 수 있다. 그 후, 가상 기기 프로세스는 태스크를 완료할 때 하드웨어로부터 그 기반을 제거할 수 있고, 원래 오퍼레이팅 시스템이 복구될 수 있다. 컴퓨팅 장치의 오퍼레이팅 시스템과 가상 기기 프로세스 간의 그러한 하드웨어 사용의 교환은 매 초 여러 번 일어날 수 있다. 따라서, 사용자는 가상 기기를 단순히 오퍼레이팅 시스템을 사용하는 또 다른 애플리케이션으로서 인지할 수 있는 한편, 가상 기기 프로세스는 일반적으로 단지 컴퓨팅 장치 하드웨어를 오퍼레이팅 시스템과 시간-공유한다.

상술된 교환을 수행하기 위해, 가상 기기는 가상 기기 장치 드라이버, 또는 컴퓨팅 장치의 오퍼레이팅 시스템에 의해 호출될 수 있는 유사한 확장물을 포함할 수 있다. 가상 기기 장치 드라이버는 컴퓨팅 장치 하드웨어로부터 오퍼레이팅 시스템의 기반을 제거하고 오퍼레이팅 시스템이 실행을 다시 시작하게 될 때까지 그것을 캐싱하는 데 필요한 명령어를 제공할 수 있다. 또한, 가상 기기 장치 드라이버는 가상 기기 프로세스의 호출을 조정할 수 있다. 예를 들면, 오퍼레이팅 시스템은 실행 동안, 가상 기기 프로세스가 태스크를 수행하게 하는 사용자 명령을 수신할 수 있다. 그 후, 오퍼레이팅 시스템은 가상 기기 장치 드라이버에게 명령을 발행하여, 가상 기기 프로세스가 요구된 태스크를 수행하고 효율적인 방법으로 오퍼레이팅 시스템에게 제어를 리턴하게 할 수 있다. 따라서, 오퍼레이팅 시스템은 가상 기기 프로세스에게 제어를 전달하는 것을, 오퍼레이팅 시스템에 의해 현재 조정되고 있는 임의의 다른 스레드에게 제어를 전달하는 것으로서 다룰 수 있다. 그러한 명령을 수신할 때, 가상 기기 장치 드라이버는 컴퓨팅 장치 하드웨어로부터 오퍼레이팅 시스템의 기반을 제거하고, 하이퍼바이저가 그 기반을 설치하게 하고, 가상 기기 프로세스에게 그 명령을 전달할 수 있다. 그 후, 가상 기기 프로세스가 완료하면, 가상 기기 장치 드라이버는 오퍼레이팅 시스템의 기반을 재설치하고 컴퓨팅 장치 하드웨어 상의 실행을 재시작하게 할 수 있다.

상세히 상술된 바와 같이, 프록시(205)는 가상 프로세스(211) 내에서 실패를 검출할 수 있고, 그 실패가 호스트 프로세스(201)에 불안정성을 도입하는 것을 방지하도록 검색할 수 있다. 그러나, 가상 프로세스(211)가 가상 기기에 의해 생성된 환경에서 실행하는 가상 오퍼레이팅 시스템 프로세스이면, 프록시(205)가 의존 할 수 있는 오퍼레이팅 시스템은 컴퓨팅 장치 하드웨어 상에서 실행하지 않지만, 저장되어 그 실행을 완료하기 위해 가상 기기를 기다리기 때문에, 프록시(205)가 그러한 가상 오퍼레이팅 시스템 프로세스를 검출 또는 제어하는 것은 어려울 수 있다. 따라서, 본 발명의 실시예가 제시하는 에러를 고립시키기 위한 하나의 메카니즘은, 하이퍼바이저가 가상 기기에 의해 생성된 환경에서 실행하는 소프트웨어를 모니터하고 그 환경 내에서 실패를 검출하는 것이다. 실패가 검출되면, 하이퍼바이저는 실행을 멈추고, 오퍼레이팅 시스템의 기반을 재설치하고, 그것이 컴퓨팅 장치 하드웨어 상의 실행을 다시 시작하게 할 수 있다. 하이퍼바이저는 또한, 오퍼레이팅 시스템, 또는 가상 환경 내의 확장물에 의존하고 있는 다른 소프트웨어가 적절하게 퇴화하게 하기 위해 적절한 응답을 제공할 수 있다.

또한, 오퍼레이팅 시스템은 일반적으로, 하이퍼바이저에 의해 그렇게 하도록 허용될 때까지 실행을 재시작할 수 없기 때문에, 하이퍼바이저는 또한, 가상 기기 환경에서의 실패가 제어를 오퍼레이팅 시스템으로의 리턴으로부터 방지하지 못한다는 것을 확인하기 위해, 타이머 또는 유사 메카니즘을 유지할 수 있다. 타이머 메카니즘은 상술된 방법으로 실패를 검출하는 데 사용될 수 있지만, 가상 기기 환경에서 실패가 발생하면 제어가 오퍼레이팅 시스템으로 리턴될 수 있는 임의의 다른 메카니즘이 존재할 수 있기 때문에, 타이머 메카니즘은 가상 기기가 하나 이상의 확장물을 호스트하는 환경을 생성하는 데 사용되는 경우 더 중요성을 갖는다.

다르게는, 타이머 메카니즘과 같은 실패가 검출될 수 있는 메카니즘을 하이퍼바이저에서 유지하기 보다, 그러한 메카니즘은, 가상 기기에 의해 생성된 환경에 서 실패가 검출되는 경우 하이퍼바이저가 제어를 오퍼레이팅 시스템에 리턴하게 할 수 있는 컴퓨팅 장치(100)의 하드웨어에서 유지될 수 있다. 예를 들어, 오퍼레이팅 시스템은 하이퍼바이저가 하드웨어 상에서 실행하도록 허용하기 전에 하드웨어에 타이머를 설정할 수 있다. 그 후, 가상 기기에 의해 생성된 환경 내에서 실패가 발생하면, 하드웨어-유지된 타이머는 만료하고 하이퍼바이저가 제어를 오퍼레이팅 시스템에 리턴하게 할 수 있다. 오퍼레이팅 시스템에 제어를 리턴하기 위하여, 하이퍼바이저는 하드웨어-유지된 타이머가 만료하는 경우, 임의의 실행을 중단하고 제어를 오퍼레이팅 시스템에 리턴하도록 수정될 수 있다. 하이퍼바이저는 또한, 에러의 존재를 나타낼 수도 있고, 이러한 방식으로 제어가 리턴되는 경우 실행이 완료되지 않은 것을 나타낼 수도 있다.

가상 프로세스(211)가 가상 기기에 의해 생성된 환경에서 실행하는 가상 오퍼레이팅 프로세스인 경우, 상술된 바와 같이, 프록시(205)와 가상 프로세스(211) 또는 확장물(215) 간의 통신이 인터-프로세스 통신 또는 RPC 메카니즘에 의존할 수 없다는 것은 추가적인 곤란한 상황이다. 대신에, 프록시(205)와 가상 오퍼레이팅 시스템 프로세스(211) 간의 통신은 하이퍼바이저, 또는 호스트 프로세스(201)의 기저가 되는 오퍼레이팅 시스템 프로세스와 통신하기 위한 가상 기기에 의해 설정된 다른 메카니즘에 의해 조정될 수 있다. 그러한 메카니즘은 예를 들어, 각각이 컴퓨팅 장치 하드웨어 상에서 실행할 때 가상 기기와 오퍼레이팅 시스템 둘 다에 액세스가능하도록 하기 위해 소정의 메모리 위치에 메시지를 저장하는 것, 또는 또 다른 예로, 가상 기기와 오퍼레이팅 시스템 둘 다가 컴퓨팅 장치 하드웨어 상에서 실행하는 동안 메모리 내에 남아있는 통신 스레드를 제공하는 것을 포함할 수 있다.

또한, 가상 프로세스(211 또는 311)와 호스트 프로세스(201) 간의 공통 사용자 모드를 제공할 수 있는 상술된 메카니즘은 또한, 가상 프로세스(211 또는 311)가 가상 기기 환경 내에서 실행 중인 가상 오퍼레이팅 시스템 프로세스인 환경에서 구현되도록 몇몇 수정을 요구할 수 있다. 예를 들면, 그 수정을 페이지 테이블 매핑에서 수행하기 위해 공통 오퍼레이팅 시스템(134)에 의존하기 보다, 수정은 가상 기기의 하이버바이저에 의해 유지되는 페이지 테이블 매핑에서 이루어질 수 있다. 따라서, 호스트 프로세스 메모리(301)가 가상 프로세스 메모리(302 및 303)를 생성하기 위해 복사되면, 그러한 복사는 도 3에 도시된 오퍼레이팅 시스템(134) 보다는 하이퍼바이저에 의해 수행될 수 있다. 특히, 호스트 프로세스 메모리(301)는 호스트 오퍼레이팅 시스템이 더이상 실행하지 못하고 가상 기기 프로세스가 실행하는 후에도, 물리적 메모리 위치(321)에 유지될 수 있다. 하이퍼바이저는 물리적 메모리 위치(321)를 식별하고, 그 위치의 컨텐츠를 하이퍼바이저의 제어 하에 있을 수 있는 물리적 메모리 위치(322 또는 323)에 복사할 수 있다.

유사한 방법으로, 호스트 프로세스(201)와 가상 프로세스(211 및 311) 간의 공통 사용자 모드가 페이지 테이블 매핑을 수정함으로써 달성되는 경우, 도 4를 참조하여 상세히 상술된 방식으로, 페이지 테이블 매핑의 수정은 하이퍼바이저에 의해 수행될 수 있다. 따라서, 호스트 프로세스 메모리(301)는 물리적 메모리 위치(321)에 남아있을 수 있고, 하이퍼바이저는 호스트 오퍼레이팅 시스템이 현재 실행 중이더라도 가상 프로세스 메모리(302 및 303)를 물리적 메모리 위치(321)에 매핑시킬 수 있다. 특히, 가상 프로세스 메모리(302 또는 303)와 같은 물리적 위치(321)에 매핑될 필요가 있는 가상 프로세스 메모리 둘 다는 하이퍼바이저의 제어 하에 있다. 따라서, 호스트 프로세스 메모리(301)가 임의의 수정을 요구하지 않기 때문에, 상술된 메카니즘은 임의의 표준 오퍼레이팅 시스템일 수 있는 오퍼레이팅 시스템(134)으로부터 임의의 지원을 요구하지 않는다.

가상 프로세스 메모리가 호스트 프로세스 메모리 및 상술된 카피-온-라이트 스킴에 의해 사용된 물리적 메모리 위치에 매핑되는 경우, 하이퍼바이저는 또한, 필요한 복사를 수행할 수 있다. 예를 들어, 하이퍼바이저는 카피-온-라이트의 일부로서 기록된 값을 저장하는 추가 물리적 메모리 위치를 따로 설정할 수 있다. 또한, 상술된 바와 같이, 프록시(205)는 호스트 프로세스 메모리(301), 및 카피-온-라이트에 사용되는 추가 위치 둘 다를 참조하도록 수정될 수 있다. 그러나, 하이퍼바이저에 의해 따로 설정된 추가 메모리는 프록시(205)의 기저가 되는 오퍼레이팅 시스템에 의해 사용될 수 있는 메모리가 아닐 수 있기 때문에, 프록시는 특별히, 기저 오퍼레이팅 시스템에 의해 적절히 액세스되지 않더라도 메모리 위치를 참조하도록 수정될 수 있다. 다르게는, 하이퍼바이저에 의해 따로 설정된 메모리 위치는 또한, 가상 기기가 컴퓨팅 장치 상에서 실행을 중지하고 오퍼레이팅 시스템이 실행을 다시 시작하게 되는 프로시저의 일부로서 프록시(205)의 기저가 되는 오퍼레이팅 시스템에 액세스가능한 메모리 위치에 복사될 수 있다.

본 발명의 실시예가 제시하는 공통 사용자 모드 컨텍스트를 제공하기 위한 또 다른 메카니즘은, 대리 호스트 프로세스가 가상 오퍼레이팅 시스템 프로세스 내부에서 실행되는 것이다. 예를 들어, 호스트 프로세스와 비슷한 대리 호스트 프로세스는 가상 기기 환경에서 가상 오퍼레이팅 시스템의 상단에서 실행될 수 있다. 대리 호스트 프로세스의 사용자 모드 컨텍스트는 가상 기기 환경의 외부에 있는 호스트 프로세스의 사용자 모드 컨텍스트과 동일할 수 있고, 이에 의해, 자동적으로 공통 사용자 모드를 제공한다. 공통 사용자 모드는, 명백하게 호스트 프로세스 메모리(301)에 액세스하거나 그것을 복사할 필요없이, 예를 들어, 상술된 기술을 사용함으로써 호스트 프로세스와 대리 호스트 프로세스 간의 통신에 의해 유지될 수 있다.

가상 오퍼레이팅 시스템 프로세스를 생성하기 위한 본 발명의 실시예가 제시하는 하나의 메카니즘은, 호스트 컴퓨팅 장치(100) 상에서 가상 기기 소프트웨어 애플리케이션을 호출하고, 다음으로, 가상 기기 소프트웨어 애플리케이션이 실행될 때 생성된 환경의 문맥 내에서 적절한 오퍼레이팅 시스템을 부팅하는 것이다. 본 분야에 숙련된 기술자들이 알고 있는 바와 같이, 가상 기기 소프트웨어 애플리케이션은 일반적으로, 컴퓨팅 장치 하드웨어로부터 오퍼레이팅 시스템(134)의 기반을 제거하고 그것을 임시 저장소에 저장하는 데 사용될 수 있는 오퍼레이팅 시스템 확장물을 포함한다. 가상 기기 소프트웨어 애플리케이션은 또한, 오퍼레이팅 시스템(134)의 기반이 제거된 후에, 컴퓨팅 장치 하드웨어 상에 자신의 기반을 설치하고 가상 환경을 생성하는 적절한 방식으로 하드웨어를 추상화할 수 있는 하이퍼바이저를 포함할 수 있다. 오퍼레이팅 시스템(134)과 동일하거나 상이할 수 있는 가상 오퍼레이팅 시스템은 하이퍼바이저에 의해 제공된 추상화된 하드웨어 상에서 부팅될 수 있다. 따라서, 하이퍼바이저는 가상 오퍼레이팅 시스템 프로세스가 오퍼레이팅 시스템(134)에 독립적으로 실행할 수 있는 가상 기기 환경을 생성할 수 있다. 그러한 가상 오퍼레이팅 시스템 프로세스는 상술된 이익을 제공할 수 있지만, 상술된 오퍼레이팅 시스템(134)의 제거를 포함하는 가상 기기 소프트웨어 애플리케이션의 호출, 및 가상 기기 환경 내에서의 적절한 오퍼레이팅 시스템의 부팅은 매우 느린 프로세스일 수 있다.

가상 기기 소프트웨어 애플리케이션을 개시하고 가상 기기 환경 내에서 오퍼레이팅 시스템을 부팅함으로써 도입된 비효율성을 피하기 위해, 본 발명의 실시예가 제시하는 또 다른 메카니즘은, 가상 기기가 초기화되고, 오퍼레이팅 시스템이 가상 기기 환경 내에서 부팅되고, 가상 기기 환경의 결과적인 최종 상태가 추가 사용을 위해 저장되고 복제되는 것이다. 따라서, 예를 들어, 컴퓨팅 장치(100)의 초기 시작동안, 오퍼레이팅 시스템(134)이 부팅된 후에, 가상 기기 소프트웨어 애플리케이션이 자동적으로 시작될 수 있고, 가상 오퍼레이팅 시스템이 가상 기기에 의해 생성된 환경 내에서 부팅될 수 있다. 이 가상 오퍼레이팅 시스템이 부팅되면, 가상 기기 환경의 상태가 저장될 수 있다. 본 분야에 숙련된 기술자들이 알고 있는 바와 같이, 가상 기기 소프트웨어 애플리케이션은 가상 기기 환경의 상태를 포함하는 컴퓨팅 장치(100)의 저장 매체 상의 소수의 파일만을 생성하기 때문에, 그러한 상태는 쉽게 저장될 수 있다. 그러한 파일은 액세스 및 복사될 수 있고, 이 후, 가상 기기 소프트웨어 애플리케이션은 동작 상태로 남을 수도 있고, 다르게는, 슬립 모드(sleep mode)와 같은 보류 상태로 대체될 수도 있고, 완전히 셧다운될 수도 있다.

그 후, 오퍼레이팅 시스템(134) 또는 소프트웨어 애플리케이션들(145) 중 임의의 것일 수 있는 호스트 프로세스는 확장물의 사용에 귀착하는 동작을 수행하기를 시도할 때, 설계로써, 또는 프록시가 중재될 수 있기 때문에, 가상 기기 환경의 저장된 상태는 복사될 수 있고, 새로운 가상 기기 환경이 효율적인 방법으로 생성될 수 있다. 가상 기기의 환경의 상태는 이미, 부팅된 가상 오퍼레이팅 시스템을 포함하기 때문에, 요구된 확장물을 호스트할 수 있는 가상 프로세스는 쉽게 생성될 수 있다. 예를 들어, 요구된 확장물이 오퍼레이팅 시스템 확장물이면, 확장물에 대한 가상 프로세스는 이미, 가상 오퍼레이팅 시스템의 형태로 존재한다. 한편, 요구된 확장물이 소프트웨어 애플리케이션 확장물이면, 적절할 소프트웨어 애플리케이션이 가상 오퍼레이팅 시스템 상에서 실행될 수 있고, 이에 의해, 적절한 가상 프로세스를 생성할 수 있다. 따라서, 가상 오퍼레이팅 시스템이 가상 기기의 환경 내에서 부팅된 후에 가상 기기 소프트웨어 애플리케이션에 의해 생성된 상태를 저장하고, 필요시, 그 저장된 상태를 복제함으로써, 오퍼레이팅 시스템과 소프트웨어 애플리케이션 확장물 둘 다를 호스트하기 위한 가상 프로세스가 효율적으로 생성될 수 있다.

가상 프로세스의 생성에 대한 적절한 지원을 제공하기 위해, 가상 기기 소프트웨어 애플리케이션은 보통 추상화하는 그러한 가상 기기 소프트웨어 애플리케이션보다 더 클 수 있는 하드웨어의 수퍼세트를 추상화하도록 설계될 수 있다. 마찬 가지로, 가상 기기 환경 내에서 부팅되는 가상 오퍼레이팅 시스템은 완전한 오퍼레이팅 시스템 API 세트를 구현할 수 있다. 그러한 하드웨어의 수퍼세트를 추상화하고 완전한 오퍼레이팅 시스템 API 세트를 제공함으로써, 가상 기기에 의해 생성된 상태가 요구된 확장물을 위해 적절한 가상 프로세스를 생성하는 데 사용될 수 있는 가능성이 더 높아진다. 따라서, 저장된 상태를 복제함으로써 더 많은 수의 유용한 가상 프로세스가 생성될 수 있고, 비용이 더 많이 드는 메카니즘을 사용하여 생성될 필요가 있는 가상 프로세스는 더 적어질 것이다.

도 5를 참조하면, 본 발명의 실시예가 제시하는 가상 오퍼레이팅 시스템 프로세스를 생성하는 또 다른 메카니즘이 도시되어 있다. 흐름도(400)는 일반적으로, 컴퓨팅 장치(100)와 같은 다수의 최신 컴퓨팅 장치의 개시 프로시저를 도시한다. 흐름도(400)는 특정 컴퓨팅 장치 또는 오퍼레이팅 시스템의 개시 프로세스에 대한 상세한 설명이 아니라, 본 발명의 실시예가 제시하는 메카니즘을 더 잘 설명하기 위해, 개시 프로시저에서 흔히 발견되는 구성요소들에 대한 일반적 설명을 제공한다.

도 5로부터 보여지는 바와 같이, 개시 프로시저는 단계(405)에서 컴퓨팅 장치에 전원을 제공함으로써 개시된다. 다음 단계(410)에서, 중앙 처리 유닛(CPU)은 판독 전용 메모리(ROM) 기본 입/출력 시스템(BIOS)에서 발견된 명령어의 실행을 시작할 수 있다. ROM BIOS는 기본 하드웨어 테스트를 수행하여 컴퓨팅 장치의 중앙 하드웨어 구성요소가 적절히 기능하는 것을 확인할 수 있다. 단계(415)에서, BIOS는 일반적으로 CMOS(Complementary Metal-Oxide Semiconductor) 메모리에 저장되어 있는 구성 정보를 판독할 수 있다. 본 분야에 숙련된 기술자들이 알고 있는 바와 같이, CMOS 메모리는 컴퓨팅 장치가 동작하지 않을 때 컨텐츠가 배터리에 의해 유지되는 메모리의 작은 영역일 수 있다. CMOS 메모리는 컴퓨팅 장치에 접속될 수 있는 하나 이상의 컴퓨터 판독가능 매체를 식별할 수 있다. 단계(420)에 의해 나타나는 바와 같이, BIOS는 MBR(Master Boot Record)를 찾기 위해, 다양한 컴퓨터 판독가능 매체의 제1 섹터를 검사할 수 있다.

일반적으로, MBR은, 부팅 레코드의 위치를 알아내고 오퍼레이팅 시스템의 부팅를 시작하기 위한 컴퓨터 실행가능 명령어일 수 있는 파티션 로더(partition loader)의 일부 또는 전부를 포함한다. 따라서, 단계(425)에서, MBR에서 발견된 파티션 로더는 BIOS을 대신할 수 있고, 컴퓨터 판독가능 매체 상에서 파티션 테이블 또는 유사 레코드를 검사하여 로드할 적절한 오퍼레이팅 시스템을 결정할 수 있다. 각각의 오퍼레이팅 시스템은 그와 관련된 부팅 레코드를 가질 수 있고, 단계(430)에서, 부팅 레코드가 어떤 문제도 갖지 않으면, 파티션 로더는 오퍼레이팅 시스템의 부팅을 개시할 수 있다.

오퍼레이팅 시스템의 부팅의 일부로서, 파티션 로더는 단계(435)에서 나타나는 바와 같이, 하드웨어 검출을 수행하기 시작할 수 있는 하드웨어 검출 루틴을 호출할 수 있다. 일반적으로, 단계(435)에서 수행된 하드웨어 검출은 예시적인 것일 뿐이며, 단계(435)의 하드웨어 검출은 반드시 하드웨어에 가능하기 보다, 단지 나중의 사용을 위해 하드웨어 장치의 목록을 생성할 수 있다. 그러한 리스트는 예를 들어, 등록 데이터베이스 또는 유사 정보 저장소에 저장될 수 있다. 단계(440)에 서, 파티션 로더는 또 다른 오퍼레이팅 시스템 프로세스 또는 서브시스템을 호출하여 컴퓨팅 장치의 다양한 하드웨어 장치로의 통신 및 제어 링크를 제공할 수 있다. 때때로, 이 서브시스템은 "하드웨어 추상 계층(Hardware Abstraction Layer; HAL)"으로 알려져 있다. 또한, 파티션 로더는 단계(440)에서, 오퍼레이팅 시스템의 커널 및 레지스트리, 또는 필요한 하드웨어 및 소프트웨어 정보를 포함하는 유사 데이터베이스를 로드할 수 있다.

단계(440)에서 파티션 로더에 의해 로드된 레지스트리 또는 유사 데이터베이스는 또한, 오퍼레이팅 시스템 커널이 하드 드라이브 또는 메모리와 같은 요구된 하드웨어에 액세스 하는 데 필요할 수 있는 장치 드라이버의 목록을 포함할 수 있다. 따라서, 단계(445)에서, 파티션 로더는 오퍼레이팅 시스템 커널에 적절한 지원을 제공하기 위하여, 이러한 장치 드라이버를 로드할 수 있다. 장치 드라이버가 로드되면, 단계(445)에서, 파티션 로더는 또한, 컴퓨팅 장치의 제어를 오퍼레이팅 시스템 커널에 전송할 수 있다.

흐름도(400)의 단계(405 내지 445)는 일반적으로 가장 처음의 시동 루틴의 구성요소를 도시하지만, 단계(450)는 오퍼레이팅 시스템 확장물, 또는 소프트웨어 애플리케이션을 호스팅할 수 있는 가상 오퍼레이팅 시스템 프로세스를 생성하는 본 발명의 실시예에 의하여 제시되는 메카니즘의 첫번째 부분을 도시한다. 상세히 기술하자면, 단계(450)에서, HAL 또는 부트 레코드와 관련된 정보는 실제로, 물리적으로 존재하는 것보다 많은 CPU가 컴퓨팅 장치에 존재함을 오퍼레이팅 시스템 커널에게 나타낼 수 있다. 그러므로, 예를 들면, 오직 하나의 CPU를 가지는 컴퓨팅 장 치에서, 오퍼레이팅 시스템 커널은 컴퓨팅 장치에 2개 이상의 CPU가 존재한다는 표시를 단계(445)에서, 수신할 수 있다. 마찬가지로, 이미 2개의 CPU를 구비한 컴퓨팅 장치에서, 오퍼레이팅 시스템 커널은 컴퓨팅 장치에 3개 이상의 CPU가 존재한다는 표시를 수신할 수 있다. 이하 상세히 기술할 바와 같이, 실제로 존재하지 않는 CPU가 존재한다고 나타냄으로써, 가상 오퍼레이팅 시스템 프로세스는 보다 쉽고 효율적으로 생성될 수 있다.

흐름도(400)로 돌아가면, 단계(455)에서 오퍼레이팅 시스템 커널은 HAL을 호출하여 오퍼레이팅 시스템 커널이 컴퓨팅 장치에 존재한다고 믿고 있는 각각의 CPU를 초기화할 수 있다. 그러므로, CPU를 초기화하라는 요청은 컴퓨팅 장치에 실제로 존재하지 않는 CPU들을 포함할 수 있다. 일단 HAL이 이 모든 CPU를 초기화하는 것을 완료한다면, 단계(460)에서, 이하 기술될 방식으로, 다음에 가상 오퍼레이팅 시스템 프로세스를 효율적으로 생성하는 데에 이용하기 위하여 시스템의 상태가 저장될 수 있다. 그 다음 오퍼레이팅 시스템의 부팅은 단계(465)가 나타낸 바와 같이, 예를 들면 오퍼레이팅 시스템의 다양한 서브시스템을 초기화하는 단계, 컴퓨팅 장치(100)를 포함하는 하드웨어 장치를 활성화시키는 단계, 및 적절한 장치 드라이버를 로딩시키는 단계를 포함하는 표준 시동 오퍼레이션으로 계속될 수 있다. 단계(465)는 특히 입출력(I/O) 서브시스템의 초기화를 나열하지만, 단계(465)에서 오퍼레이팅 시스템 커널은 메모리 관리자, 프로세스 관리자, 오브젝트 관리자, 다양한 오퍼레이팅 시스템의 커널, 및 유사한 서브시스템도 초기화할 수 있다. 또한, 오퍼레이팅 시스템 커널은 하드웨어 인터럽트를 재작동 시킬 수 있고 컴퓨팅 장치 (100)의 일부로서 탐지된 다양한 하드웨어 장치를 활성화시킬 수 있다. 상술한 바와 같이, 다양한 하드웨어 장치의 활성화의 일부로서 오퍼레이팅 시스템 커널은 이들 장치에 적절한 장치 드라이버를 로딩시킬 수도 있다. 본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, 복수의 오퍼레이팅 시스템은 본래 하나의 CPU를 구비한 컴퓨팅 장치 용으로 설계되었기 때문에, 이러한 오퍼레이팅 시스템은 오직 하나의 CPU를 가지고 도 5에 도시된 단계 대부분을 수행하고, 모든 시동 프로시저를 거의 완료한 이후에만 임의의 추가적인 CPU를 활성화시킨다. 결과적으로, 주 CPU는 일반적으로 모든 하드웨어 바인딩을 보유하는 한편, 다른 CPU들은 컴퓨팅 장치 상에서 실행될 다양한 프로세스로 태스킹될 수 있다.

상술한 바와 같이, 단계(450)에서는, CPU가 컴퓨팅 장치에 물리적으로 존재하지 않았을 수 있더라도 오퍼레이팅 시스템 커널에게 추가적인 CPU를 알려 주었다. 그러므로, 단계(470)에서, 오퍼레이팅 시스템 커널에게 단계(450)에서 나타났지만 물리적으로는 존재하지 않는 CPU는 존재하지 않음을 알릴 수 있다. 단계(470)에서의 CPU가 실질적으로 존재하지 않음을 알리는 것은 단계(450)에서의 추가적인 CPU를 표시한 것을 표시 이전 상태로 되돌리고, 오퍼레이팅 시스템 커널이 컴퓨팅 장치(100)에 물리적으로 존재하는 것과 동일한 개수의 CPU를 이용하여 오퍼레이팅 시스템의 부팅 프로세스를 완료하도록 한다. 상술했듯이 다양한 시스템이 다양한 시점에서 추가적인 CPU를 초기화할 수 있기 때문에, 단계(470)는 단계(465)에 도시된 모든 구성요소가 수행된 후에만 일어난다고 한정하려는 의도는 아니다. 오히려, 추가적인 CPU가 초기화되고 적절한 하드웨어 바인딩이 구축된 이후에 단계 (470)는 일어날 수 있다면 언제든지 수행됨을 의도한다. 흐름도(400)를 따라 진행하면, 단계(475)에서, 오퍼레이팅 시스템 커널은 적절한 서브시스템을 런칭(launch)하여 사용자 모드 환경을 생성할 수 있으며, 단계(480)에서, 일단 사용자 모드 환경이 생성되면, 오퍼레이팅 시스템은 부팅 프로세스를 완료할 수 있다.

일단 단계(480)에서 부팅 프로세스가 완료되면, 가상 환경은, 단계(480)에서 부팅이 완료된 오퍼레이팅 시스템을 통해 입력되는 명령으로 가상 기기 등을 실행시킴으로써, 부팅될 수 있다. 가상 환경을 보다 효과적으로 생성하기 위하여, 오퍼레이팅 시스템의 부팅 중에 단계(460)에서 저장되었던 상태가 이용될 수 있다. 이 저장된 상태는 단계(450)에서 존재하는 복수의 CPU를 반영하고, 단계(470)에서 보조 CPU의 부재를 표시한 것을 고려하지 않기 때문에, 가상 환경은 복수의 CPU가 존재하는 것처럼 부팅될 수 있다. 그러므로, 가상 기기의 환경은, 이하에 도시될 방식으로, 호스트 오퍼레이팅 시스템에 의해 구축되는 메카니즘을 이용하여 보다 효과적으로 시동될 수 있다.

상술했듯이, 복수의 오퍼레이팅 시스템은 부팅 프로세스가 거의 완료될 때 까지 오직 하나의 CPU를 이용할 것이기 때문에, 그 CPU는 일반적으로 시스템 장치들로부터의, 하드웨어 인터럽트와 같은 임의의 통신의 처리를 포함하는, 이들 시스템 장치 대부분의 또는 모두를 처리하는 것으로 태스킹된다. 따라서, 복수의 물리적 CPU를 가지는 컴퓨팅 장치 상의 오퍼레이팅 시스템은 일반적으로 부팅 프로세스 중에는 이용되지 않는 CPU 상에서 실행되는 프로세스가 부팅 프로세스 중에 이용되는 CPU와 통신할 수 있는 메카니즘을 제공하여 이들 프로세스에게 하드웨어와 통신 하는 기능을 제공한다. 도 5는 이 기능이 가상 기기의 환경이 하드웨어 장치로의 임의의 런타임 바인딩 없이 기본적인 하드웨어와 통신할 수 있게 하도록 촉진할 수 있는 메카니즘을 도시한다. 상세히 기술하자면, 저장된 상태가 가상 환경에 제공된다면, 가상 환경은 부팅 프로세스 중에 사용되었을 CPU가 사용되지 않거나, 적어도 입/출력 하드웨어와 통신할 수 없도록 구성될 수 있다. 대신에, 가상 환경은 컴퓨팅 장치가 복수의 CPU를 포함하는 걱처럼 행동함으로써 오퍼레이팅 시스템의 메카니즘을 이용하여 오퍼레이팅 시스템에 대하여 이미 수행된 하드웨어 바인딩을 촉진시킬 수 있다.

예로서, 오직 하나의 CPU를 가지는 컴퓨팅 장치에서, 단계(470)에서는 오퍼레이팅 시스템은 제2 CPU가 존재하지 않는다는 표시를 수신하지만, 가상 환경은 이러한 표시를 아무것도 수신하지 않기 때문에, 가상 오퍼레이팅 시스템 프로세스는 적어도 하나의 보조 CPU가 존재하는 것처럼 동작할 것이다. 그러므로, 컴퓨팅 장치의 하나의 물리적 CPU가 여전히 모든 작업을 수행하지만, 가상 기기의 환경은 2개의 CPU 시스템이 존재하는 것처럼 동작하는데, 하나의 CPU는 하드웨어 장치로의 모든 런타임 바인딩을 가지고, 제1 CPU가 존재하기 때문에, 하드웨어로의 임의의 런타임 바인딩으로 초기화될 필요가 없는 제 2 CPU는 가상 오퍼레이팅 시스템 프로세스를 호스팅한다. 결과적으로, 가상 오퍼레이팅 시스템은 임의의 하드웨어를 초기화할 필요가 없기 때문에 효과적으로 부팅될 수 있고 가상 기기는 임의의 하드웨어를 추상화할 필요가 없기 때문에 그 자체가 매우 효과적으로 시동될 수 있다. 가상 오퍼레이팅 시스템 프로세스 내에 호스팅된 확장물이 하드웨어 장치와 통신하 기를 요청한다면, 복수의-CPU 시스템에서 사용하기 위하여 구축된 상술한 메카니즘을 이용하여 가상 오퍼레이팅 시스템 프로세스로부터 호스트 오퍼레이팅 시스템에게 요청이 이루어진다. 그러므로, 확장물은 표준 방식으로 동작될 수 있고, 가상 환경은 효과적으로 생성될 수 있다.

그러나, 본 기술 분야에서 숙련된 기술을 가진 자들에 공지된 바와 같이, 오퍼레이팅 시스템 장치 드라이버와 같은, 몇몇의 확장물에서, 상술한 메카니즘은 만족스러운 해결책을 제공할 수 없다. 상세히 기술하자면, 호스트 오퍼레이팅 시스템이 레가시 장치(199)와 같은 레가시 하드웨어를 만날 경우, 이 시스템은 적절한 드라이버를 찾아낼 수 없을 수 있고 하드웨어를 적절하게 인식하지 않을 수 있다. 그러므로, 적절한 가상 오퍼레이팅 시스템 프로세스는 레가시 인터페이스(198)와 같은 레가시 장치 드라이버를 호스팅할 수 있지만, 상술한 메카니즘을 이용하면, 이 오퍼레이팅 시스템이 모든 하드웨어 통신을 처리할 것이고, 이 오퍼레이팅 시스템은 레가시 하드웨어에 적절히 접속되지 않을 것이기 때문에, 레가시 하드웨어와 통신하는 방법은 전혀 존재하지 않을 수 있다. 또한, 비록 기본적인 오퍼레이팅 시스템이 모든 컴퓨팅 장치의 하드웨어에 적절히 접속되더라도, 비디오 장치 드라이버와 같은 몇몇의 확장물은 상기 메카니즘을 이용하는 하드웨어 통신에 일어나는 적은양의 지연만으로도 적절하게 동작할 수 없을 수 있다.

결과적으로, 본 발명의 실시예가 제안하는 상술된 메카니즘의 변형물은 장치 드라이버가 가상 오퍼레이팅 시스템 프로세스에 호스팅 될 하드웨어 장치가 기본적인 오퍼레이팅 시스템의 부팅 시퀀스 중에 식별되고 기본적인 오퍼레이팅 시스템이 아닌 가상 오퍼레이팅 시스템 프로세스에 바인딩되어, 장치 드라이버에게 이 하드웨어 장치로의 직접적인 액세스를 제공하는 것을 언급한다. 보다 상세히 기술하자면, 하드웨어 장치의 인터럽트들은 나타나지만 물리적으로 존재하지 않는 보조 CPU로 송신될 수 있다. 이어서, 가상 기기가 보조 CPU가 존재한다고 가정하는 환경을 생성할 때, 이 기기는 하드웨어 장치로의 런타임 바인딩을 초기화할 수 있어서, 가상 오퍼레이팅 시스템 프로세스가 하드웨어 장치와 직접적으로 통신하도록 할 수 있다. 그러므로, 도 5에 도시된 바와 같이, 단계(499)에서 가상 환경의 부팅이 완료되기 전에, 선택적인 단계(495)가 레가시 장치(199)의 하드웨어 구성에 삽입될 수 있고 이 가상 환경에 레가시 인터페이스(198)와 같은, 적절한 장치 드라이버를 로딩시킬 수 있다.

대안으로, 가상 기기는 상술한 부팅 최적화에 의존하지 않는 2개 이상의 가상 CPU를 구비하는 환경을 생성할 수 있다. 복수의-CPU 가상 환경을 생성하는 데에 이용되는 프로세스와 관계없이, 장치 드라이버가 가상 오퍼레이팅 시스템 프로세스에 의해 호스팅되는 하드웨어 장치는 하드웨어 장치가 가상 CPU인 보조 CPU로 인터럽트를 송신하고 있었던 것처럼 바운딩될 수 있다. 그러므로 이하 보다 상세히 기술될 바와 같이, 오퍼레이팅 시스템의 초기 부팅 중에, 드라이버가 가상 환경에서 호스팅되어야 할 하드웨어 장치는 숨겨지거나 지연될 수 있어서, 하드웨어 장치는 오퍼레이팅 시스템을 로딩시키고 있는 물리적 CPU에 바인딩되지 않는다. 그러나, 부팅 프로세스의 일부인, 가상 환경은 하드웨어 장치에 바인딩될 수 있다. 상술한 바와 같이, 가상 환경은 적어도 제2 CPU가 존재하는 것처럼 생성될 수 있고 가상 환경은 이 CPU를 이용하고 있다. 그러므로, 하드웨어 장치로의 바인딩은 하드웨어 장치가 제2 CPU로의 인터럽트를 송신하고 있었던 것처럼 수행될 것이다. 오직 하나의 물리 CPU가 존재하기 때문에, 이 CPU는 하드웨어 장치로부터 통신을 수신할 수 있다. 그러나, 이들 통신은 호스트 오퍼레이팅 시스템보다는 가상 환경을 이 지시할 수 있어, 이 가상 환경에 하드웨어 장치로의 직접적인 액세스를 제공한다.

본 발명의 실시예는 흐름도(400)의 단계(465)에서 드라이버가 가상 오퍼레이팅 시스템 프로세스에 호스팅되어야 할 하드웨어 장치를 숨기거 지연시킬 수 있는 복수의 메카니즘을 제시한다. 본 발명의 실시예가 제시하는 하나의 메카니즘은 단계(465) 중에서 가상 오퍼레이팅 시스템 프로세스에 호스팅될 수 있는 장치 드라이버에 송신될 수 있는 임의의 제어 정보를 캡쳐하는 것을 언급한다. 이러한 제어 정보는 단계(490)에서 가상 오퍼레이팅 시스템 프로세스가 구축될 때까지 지연된 다음 장치 드라이버에 전달(relay)될 수 있다. 본 발명의 실시예가 제시하는 다른 메카니즘은 단계(465)에서 호스트 프로세스(201) 및 프록시(205)를 참조하여 상술한 방식으로 오퍼레이팅 시스템프로세스가 호출하여 단계(465)에서, "OK" 지시를 리턴하고, 계속하여 단계(490)에서 가상 오퍼레이팅 시스템 프로세스가 구축될 때까지 자신에게 송신되는 임의의 IRP(Input/output Request Packet)들을 캐슁한다. 그 다음 프록시는 IRP들을 가상 오퍼레이팅 시스템 프로세스에서의 장치 드라이버에 전달할 수 있다. 대안으로, 프록시는 가상 오퍼레이팅 시스템 프로세스가 구축될 때까지 지연만 하고, 그 다음 캐슁하지 않고 장치 드라이버에 임의의 IRP들을 직접 전달할 수 있다.

본 발명의 실시예가 제시하는 또 다른 메카니즘은 하드웨어 장치가 단계(465)에서 초기에 오퍼레이팅 시스템에 바인딩되고 계속하여 큐에서 임의의 IRP들을 깨끗하게 플러슁(flush) 시킬 수 있는 "하이버네이트(hibernate)" 또는 유사한 명령을 송신하고 하드웨어를 편리한 상태로 유지하는 것을 언급한다. 그 다음, 단계(495)에서, 가상 오퍼레이팅 시스템 프로세스의 장치 드라이버는 가상 오퍼레이팅 시스템 프로세스 안에서부터 장치와의 직접적인 통신을 구축하려고 시도할 수 있다. 본 발명의 일 실시예가 제시하는 이 메카니즘의 변형물은 하드웨어 장치를, 상술한 바와 같이, 바인딩한 다음 하이버네이팅시키는 것 보다는, 단계(465)에서 오퍼레이팅 시스템으로부터 숨기는 것을 말한다. HAL 또는 플러그-앤-플레이 관리자와 같은, 다양한 다른 서브시스템에 적절한 명령을 송신함으로써 하드웨어 장치를 숨길 수 있다. 계속하여, 단계(480)에서 오퍼레이팅 시스템이 부팅되고 가상 오퍼레이팅 시스템 프로세스가 구축된 후에, 하드웨어 장치는 활성화될 수 있거나, 그렇지 않으면, 단계(495)에서 가시화될 수 있으므로 이 장치는 자신을 가상 오퍼레이팅 시스템 프로세스 및 이에 호스팅된 장치 드라이버에 직접 바인딩시킬 수 있다.

상술한 방식으로 추가적인 CPU를 시뮬레이팅하여 복수의-CPU 오퍼레이팅 시스템의 성능을 촉진시키는 것보다는, 본 발명의 실시예가 제시하는 가상 프로세스를 효과적을 생성하는 대안적인 메카니즘이 일반적으로 도 6에 도시된다. 도 6에 도시된 흐름도(500)는 도 5를 참조하여 상술한 바와 동일한 단계들을 다수 포함한 다. 상술하자면, 단계(405 내지 445, 465, 및 475)는 일반적으로 상술한 바와 동일한 기본 시동 프로시저를 도시한다. 또한, 도 6에는 상세히 도시되지 않았지만, 단계(445)와 단계(465) 사이에 오퍼레이팅 시스템 커널은 컴퓨팅 장치의 CPU들을 알아낼 수 있고 HAL을 호출하여 이들 CPU들을 초기화할 수 있다. 그러나, 도 5에 도시된 단계(450 및 455)와는 다르게, 상술한 단계들은 실제로 컴퓨팅 장치에 존재하는 CPU보다 많은 수의 CPU를 오퍼레이팅 시스템 커널에 나타내는 것을 포함하지는 않는다. 계속되는 단계(475)에서, 컴퓨팅 장치의 상태가 저장될 수 있는 새로운 단계(505)가 수행될 수 있다.

단계(485)에서 오퍼레이팅 시스템 부팅이 완료된 이후에, 가상 기기가 런칭될 수 있고, 이 가상 기기는 관측 및 기록된 코드에 의해 수집된 정보를 이용할 수 있다. 그러므로, 단계(485)에서, 가상 기기는 부팅 프로세스를 시작할 수 있고, 단계(510)에서, 가상 기기는 단계(505)에서 레코딩된 상태를 이용하여 가상 오퍼레이팅 시스템 프로세스를 보다 효과적으로 부팅시킬 수 있다. 보다 상세히 기술하자면, 가상 환경은 가상화되어야 할 특정 하드웨어 장치만의 파라미터를 이용하할 수 있어서, 이 환경은 다른 하드웨어 장치를 건너뛸 수 있다. 또한, 단계(505)에서와 같이, 오퍼레이팅 시스템 부팅 중에 이미 파라미터가 구축되고 기록되었기 때문에, 가상 기기는 이들 하드웨어 장치를 보다 효과적으로 가상화시킬 수 있다. 그러나, 레가시 장치(199)와 같은 하드웨어 장치가 단계(465)에서 적절하게 초기화되지 않았다면, 이 장치는, 앞서 상세히 기술한 방식으로, 선택 단계(495)에서 가상 환경에 초기화될 수 있다. 최종적으로, 가상 기기는 가상화될 제한된 세트의 하드웨어 장치를 선택할 수 있고, 이 장치들을 보다 효과적으로 가상화시킬 수 있기 때문에, 가상 환경은 보다 효과적으로 생성될 수 있다. 그러나, 본 기술 분야에서 숙련된 기술을 가진 자가 이해할 바와 같이, 상술한 최적화는 부팅된 오퍼레이팅 시스템 및 가상 오퍼레이팅 시스템이 일치하거나, 적어도 이들의 하드웨어와의 인터페이스가 유사한 경우에 가장 효과적일 수 있다.

가상 오퍼레이팅 시스템 프로세스에 의해 호스팅될 수 있는 특정 하드웨어 장치 드라이버 확장물을 포함하는 몇몇의 경우에서, 가상 오퍼레이팅 시스템 프로세스가 제공하는 지원 API의 의미들은 유용하지 않을 수 있다. 예를 들면, 몇몇의 하드웨어 장치 드라이버는 이 하드웨어를 적절히 제어하기 위하여 물리적 하드웨어로의 액세스를 요구할 수 있다. 그러므로, 이러한 경우에 가상 오퍼레이팅 시스템 프로세스가 호스팅된 장치 드라이버에게 물리적 하드웨어로의 엑세스를 제공할 필요가 있을 것이다. 상술한 메카니즘 중 몇몇은 필요한 직접적인 액세스를 제공할 수 있지만, 본 발명의 실시예는 가상 프로세스 내에서 호스팅되는 확장물들이 하드웨어로의 직접적인 액세스를 가지도록 하는 임의의 그 가상 프로세스에 적용될 수 있는 추가적인 메카니즘을 제시한다.

결과적으로, 이하 기술될 메카니즘은 확장물과 호스트 프로세스 간의 장애 고립을 제공할 뿐 아니라, 하드웨어를 추상화하는 것이 비효율적이거나 불가능할 수 있는 상황에 가상 기기가 하드웨어로의 직접적인 액세스를 제공할 수 있도록 하는 데에 이용될 수 있다. 예를 들면, 상술한 메카니즘은 가상 기기로 하여금 이 가상기기가 추상화하도록 설계되지 않았던 하드웨어에 의존하는 소프트웨어를 호스 팅할 수 있게 한다. 이와 같이, 후술될 메카니즘은 가상 기기 설계자 및 작성자에게 이들이 고려해야 하는 하드웨어의 범위를 좁히는 능력을 제공하는 한편 소비자에게는 고유한 하드웨어 또는 레가시 하드웨어를 사용하는 능력도 제공한다.

도 7로 돌아가면, 하이퍼바이저(hypervisor)(613)를 이용하여 기본적인 하드웨어(620)와 인터페이스하고, 확장물(615)을 호스팅하는 가상 오퍼레이팅 시스템 프로세스(611)를 포함하는 가상 기기 프로세스(617)가 도시된다. 검은 화살표로 나타낸 바와 같이, 본 발명의 실시예는 하이퍼바이저(613)에 의해 수행되는 임의의 추상화를 무시하며, 확장물(615)이 가상 기기 환경 내로부터 하드웨어(620)를 직접적으로 액세스할 수 있는 가상 기기 환경을 제시한다. 상술한 바와 같이, 하이퍼바이저(613)와 같은 하이퍼바이저는 제한된 오퍼레이팅 시스템 기능을 제공하고, 하드웨어(620)와 같은 기본적인 하드웨어에 추상화된 액세스를 제공함으로써 가상 기기 환경을 관리하는 컴퓨터 실행가능 명령어들일 수 있다. 그러므로, 하이퍼바이저(613)는 기본적인 하드웨어의 사양들로부터 가상 기기 환경을 보호하도록 행동할 수 있어, 가상 기기 소프트웨어 애플리케이션은 이 환경 내에서 실행되고자 하는 임의의 코드에 적절한 가상 기기 환경을 생성 할 수 있다. 그 다음 하이퍼바이저는 가상 기기 환경과 기본적인 하드웨어 사이의 이행을 할 수 있다.

예로서, 가상 기기 환경은 기본적인 하드웨어(620)가 실제로, 완전히 다른 유형의 CPU를 포함할 수 있더라도 가상 오퍼레이팅 시스템 프로세스(611)에 특정된 유형의 CPU 및 그 프로세스 안에서 실행될 수 있는 임의의 프로그램을 제공할 수 있다. 하이퍼바이저(613)는 가상 기기 환경 내부의 하나의 유형의 CPU에 이루어진 요청을 기본적인 하드웨어(620)에 존재하는 다른 유형의 CPU와 통신하기에 적절한 요청으로 변환하는 것으로 태스킹될 수 있다. 그런, 상술한 바와 같이, 장치 드라이버들과 같은 몇몇의 오퍼레이팅 시스템 확장물이 기본적인 하드웨어 장치와 직접적으로 통신할 필요가 없을 수 있기 때문에, 하이퍼바이저에 의해 수행되는 추상화는 오퍼레이팅에서 이러한 오퍼레이팅 시스템 확장물을 적절하게 제거할 수 있다. 결과적으로 본 발명의 실시예들은 하이퍼바이저를 무시하고 가상 오퍼레이팅 시스템 프로세스(611) 안에서 호스팅된 확장물이 하드웨어를 직접적으로 액세스하게 하는 다양한 메카니즘을 제시한다.

가상 기기 프로세스(617) 외에도, 도 7은 하드웨어(620)도 사용할 수 있는 호스트 오퍼레이팅 시스템 프로세스(601) 또한 도시한다. 하드웨어(620)는 2개의 블럭으로 분리되어 상술한 호스트 오퍼레이팅 시스템 프로세스(610)와 가상 기기 프로세스(617) 간의 시간 공유를 도시한다. 그러므로, 가상 기기 프로세스(617)는, 하이퍼바이저(613)를 통하여 하드웨어(620) 상에서 실행되고 있지만, 하드웨어(620)는 호스트 오퍼레이팅 시스템 프로세스(601)를 동시에 실행시키지는 않는다. 대신에 호스트 오퍼레이팅 시스템 프로세스(601)의 언더피닝이 제거되고 임시 저장소에 위치할 수 있다. 도 7에 도시되지 않았지만, 이러한 언더피닝은 레지스트리 엔트리, 다양한 제어 레지스터, 인터럽트 디스패치(dispatch) 루틴, CPU 특권 데이터, 등을 포함할 수 있다. 일단 가상 기기 프로세스(617)가 하드웨어(620) 상에서의 실행을 완료한다면, 가상 기기 프로세스의 언더피닝은 제거되고 임시 저장소에 위치될 수 있으며 호스트 오퍼레이팅 시스템 프로세스(601)가 복구되어 하드웨어 상에서 실행될 수 있다.

도 7은 프록시(605)를 구비한, 호스트 오퍼레이팅 시스템 프로세스(601)를 도시하지만, 본 발명의 실시예가 제시하는 가상 환경 내로부터 하드웨어로의 직접적인 액세스를 제공하는 메카니즘이 확장물 장애 고립에 관련하는 것 이외의 용도일 수 있다. 상세히 기술하자면, 상술한 메카니즘은 일반적으로 가상 기기 기술에 적용될 수 있어서, 가상 기기는 확장물 및 레가시 하드웨어 장치, 고객 하드웨어 장치 또는 통상적인 하드웨어 장치에 의존하는 다른 소프트웨어를 호스팅할 수 있다. 이러한 장치에 대하여 추상화를 설계할 필요성을 없앰으로써, 본 발명의 실시예들은 보다 단순한 하이버바이저 및 보다 효율적인 가상 기기 설계를 제공한다.

본 발명의 실시예가 제안하는 가상 기기 환경 내에서부터 하드웨어로의 직접적인 액세스를 제공하는 하나의 메카니즘은 하이퍼바이저가 하나 이상의 하드웨어 장치에 대응하는 물리적 메모리에 액세스할 수 있도록 페이지 테이블 매핑을 수정하는 것을 언급한다. 본 기술 분야에서 숙련된 기술을 가진 자에 공지된 바와 같이, 애플리케이션 또는 확장물은 적절한 물리적 메모리를 액세스함으로써 하드웨어 장치와 통신할 수 있는데, 이 하드웨어 장치는 종종 레지스터 또는 하드웨어 장치 자신에 위치되거나 인터페이스 카드에 위치되는 유사한 하드웨어일 수 있다. 그러므로, 예를 들면, 도 1에 도시된 예시적인 컴퓨팅 장치(100)는 키보드 장치 드라이버에게 사용자 입력 인터페이스(160)의 물리적 메모리 레지터스로의 액세스를 제공함으로써 키보드 장치 드라이버가 키보드(162)와 통신할 수 있도록 한다. 대안으로, 키보드 장치 드라이버는 RAM(132)에서의 특정 위치를 액세스할 수 있고 추가적 인 프로세스가 키보드(162)로부터의 입력을 RAM에서의 그 위치로 전송하여 장치 드라이버가 판독할 수 있다.

가상 기기 프로세스(617)에서의 확장물(615)과 같이, 가상 기기 환경에서의 코드가 기본적인 하드웨어로의 액세스를 구할 때, 하이퍼바이저(613)는 기본적인 하드웨어에 적절한 변환을 수행할 수 있어 물리적 레지스터를 직접 액세스할 수 있거나, 가상 기기 프로세스 메모리 공간에 데이터를 저장할 수 있는데, 이 데이터는 전용 하드웨어 등에 의해 이 메모리 공간으로부터 판독되거나 적절한 물리적 레지스터에 복사될 수 있다. 가상 기기 환경 내로부터 기본적인 하드웨어 장치로의 직접적인 액세스를 제공하기 위하여, 하이퍼바이저는 임의의 변환을 수행하는 것을 피할 수 있는데, 이는 이러한 변환이 부적절하기 때문에며, 이 대신에 하이퍼바이저는 필요한 물리적 메모리 위치가 가상 오퍼레이팅 시스템 프로세스(611)에 의해 이용되는 메모리 공간과 같은, 적절한 메모리 공간에 매핑될 수 있는 방식으로 페이지 테이블 매핑을 수정할 수 있다. 상술한 바와 같이, 페이지 테이블 매핑은 물리 메모리 위치가 소정의 프로세스에 할당되는지 여부를 판정한다. 그러므로, 하나 이상의 장치에 대응하는 물리적 메모리 위치를 찾아내는 페이지 테이블 매칭을 가상 오퍼레이팅 시스템 프로세스 메모리 공간으로의 매핑으로 수정함으로써, 하이퍼바이저는 가상 오퍼레이팅 시스템을 이용하는 확장물 및 애플리케이션이 하드웨어 장치를 직접적으로 액세스하도록 할 수 있다.

일례에서, 하드웨어 장치 드라이버일 수 있고, 가상 오퍼레이팅 시스템 프로세스(611)가 호스팅하고 있는 확장물(615)은 알려진 메모리 판독 및 기록 오퍼레이 션을 이용하여 하드웨어(620)의 일부인 대응하는 하드웨어 장치로의 직접적인 액세스를 획득할 수 있다. 하드웨어 추상화를 제공하는 하이퍼바이저(613)는 확장물(615)로부터의 메모리 판독 및 기록 오퍼레이션을 해석되지 않아야 하거나 추상화되어야 할 오퍼레이션으로 인식하도록 설계될 수 있고, 이 오퍼레이션들이 기본적인 하드웨어에 전달될 수 있도록 할 수 있다. 또한, 하이퍼바이저(613)가 페이지 테이블 매핑을 적절하게 수정할 수 있기 때문에, 메모리 판독 및 기록 오퍼레이션은 확장물(615)이 제어하기를 요구하는 하드웨어 장치에 대응하는 원하는 레지스터 또는 다른 물리적 메모리 위치 상에서 물리적으로 수행될 수 있다. 결과적으로, 확장물(615)이 하드웨어 장치에 대응하는 메모리 레지스터 또는 다른 물리적 메모리 위치 상의 직접적인 제어를 가지므로, 심지어는 가상 기기 환경 내로부터 장치를 직접적으로 제어할 수 있다.

그러나, 페이지 테이블 매핑을 변경하고 확장물이 가상 기기 환경 내로부터 하드웨어를 직접적으로 액세스하도록 함으로써, 호스트 오퍼레이팅 시스템 프로세스(601)는 확장물이 일으킬 수 있는 임의의 불안정성에 더 노출되어질 수 있다. 예를 들면, 가상 기기 프로세스(617)가 하드웨어(620) 에서 실행될 때, 확장물(615)은 부적절한 방식으로 하드웨어(620)의 컴포넌트 몇몇을 직접 액세스할 수 있어서, 하드웨어 컴포넌트가 부적절하게 행동하거나 심지어는 실행이 불가능하게 되는 상황을 일으킬 수 있다. 결과적으로, 호스트 오퍼레이팅 시스템 프로세스(601)가 하드웨어(620)에서의 실행을 재개한 이후에, 액세스된 하드웨어 컴포넌트는 부적절하게 행동하기를 계속하여 호스트 오퍼레이팅 시스템 프로세스에게 불안정성을 일으킬 가능성이 있거나, 실행불가 상태로 남아있을 수 있어서, 필요한 태스크를 수행하는 프로세스에서 호스트 오퍼레이팅 시스템 프로세스를 제거할 수 있다. 결과적으로, 본 발명의 일 실시예가 제시하는 하나의 메카니즘은 상술한 페이지 테이블 매핑의 수정에 제약 사항을 제공하는 것이다. 예를 들면, 한 제약 사항은 확장물이 필요한 영역만 페이지 테이블 매핑을 수정하는 것일 수 있다. 그러므로, 확장물이, 하드웨어 장치 또는 장치로의 인터페이스에 물리적으로 위치된 메모리 레지스터의 주소를 포함할 가능성이 있는 매우 제한된 주소 범위로의 액세스만 필요로한다면, 페이지 테이블 매핑은 이 제한된 주소 범위를 가상 기기 프로세스 메모리 공간에 매핑시킬 필요가 있는 범위에만 수정될 수 있다. 다른 제약은 페이지 테이블 매핑은 확장물이 자신의 태스크를 수행할 수 있을 때만 수정될 수 있는 일시적인 제약일 수 있다. 예를 들면, 확장물(615)이 하드웨어 장치와 직접적으로 통신하기를 시도할 때, 이 확장물은 직접적인 액세스를 원하는 시간의 길이를 지정하는 하이퍼바이저(613)를 요청할 수 있다. 이러한 요청은 직접적으로 이루어지거나 확장물(615)을 호스팅하는 가상 오퍼레이팅 시스템 프로세스(611)을 통해 이루어질 수 있다. 일단 하이퍼바이저(613)가 요청을 수신한다면, 하이퍼바이저는 요청된 길이의 시간 동안 대한 페이지 테이블 매핑을 수정할 수 있다.

본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, 복수의 하드웨어 장치는 인터페이스 카드 등의 인터페이스 하드웨어를 통해 컴퓨팅 장치에 접속된다. 이러한 인터페이스 하드웨어는 종종 상술한 바와 같이 알려진 버스 메카니즘에 첨가될 수 있다. 버스 주소는 컴퓨팅 장치에서 실행되는 소프트웨어에 의해 또한 액세스될 수 있는 물리적 메모리에 매핑될 수 있다. 결과적으로, 버스에 접속되는 인터페이스 카드 등의 레지스터는 종종 "메모리가 매칭되는 레지스터"라 종종 칭하고 메모리의 하나 이상의 물리적 페이지에 매핑될 수 있다. 그러나, 메모리가 매핑되는 레지스터의 세트는 메모리가 매핑되는 레지스터 의 다른 세트와 물리적 페이지를 거의 공유하지 않기 때문에, 상술한 페이지 테이블 매핑의 수정은 장치 단위 마다 이루어질 수 있다.

또한, 본 발명의 실시예가 제시하는 하나의 메카니즘은 가상 주소 변환을 이용하여 특정 메모리가 매핑된 레지스터가 가상 기기 프로세스(617)에만 이용가능하게 하는 것을 언급한다. 이러한 방식으로, 호스트 오퍼레이팅 시스템 프로세스(601)는 이 프로세스가 적절한 장치 드라이버를 구비하지 않은 하드웨어를 처리하는 것을 피할 수 있고, 가상 오퍼레이팅 시스템 프로세스 내에서 호스팅될 수 있는 적절한 장치 드라이버에게는 특정 하드웨어 장치로의 액세스가 영속적으로 허가될 수 있다.

본 발명의 실시예가 제시하는, 가상 기기에 하드웨어로의 직접적인 액세스를 제공하는 다른 메카니즘은 하이퍼바이저(613)에 의해 수행되는 에뮬레이션 또는 다른 수정 없이 입/출력(I/O) 포트가 가상 기기 환경 내로부터 액세스될 수 있도록 하는 것이다. 본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, I/O 포트는 일반적으로 주소 또는 포트 번호에 의해 식별되고 알려진 "IN" 또는 "OUT" 명령을 통해 액세스될 수 있다. 장치 드라이버 또는 다른 소프트웨어 애플리케이션이 I/O 포트를 이용하여 하드웨어 장치를 액세스하기 위하여, IN 및 OUT 명령은 이 명령에서 기술되었던 하드웨어 장치 상의 레지스터 또는 물리적 포트에, 소프트웨어를 통하여 전달될 수 있거나, 대안으로, 이 명령은 명령을 발행하는 장치 드라이버 또는 다른 애플리케이션으로부터 식별된 포트 또는 레지스터에게 직접적으로 전달될 수 있다. 몇가지 유형의 CPU는 태스크 세그먼트 상의 I/O 비트맵을 이용함으로써 패스-스루(pass-through) 또는 직접 액세스 중에서 선택할 수 있는데, 이 I/O 비트맵은 명령어가 소프트웨어를 패스-스루할 수 있는 주소들 및 명령어가 물리적 포트 또는 레지스터에 직접적으로 송신될 수 있는 주소들을 기술한다.

정상 동작에서, 하이퍼바이저(613)와 같은, 가상 기기의 하이퍼바이저는 I/O 명령어를 트랩(trap)하거나 I/O 명령어를 애뮬레이팅하여 가상 기기 환경 내의 소프트웨어에 적절하게 기본적인 하드웨어(620)를 추상화할 것이다. 하이퍼바이저(613)가 예를 들어, 보호 비트맵을 이용하여 I/O 명령어를 트랩한다면, 본 발명의 실시예가 제시하는 한 메카니즘은 보호 비트맵을 "홀(hole)" 또는 하이버바이저가 트랩하지 않을 I/O 주소를 제공하도록 수정하는 것을 언급한다. 그러므로, 예를 들면, 장치 드라이버일 수 있는 확장물(615)이 특정 I/O 주소를 이용하여 하드웨어로의 직접적인 액세스를 요구한다면, 보호 비트맵은 I/O 주소를 기술하는, 확장물(615)과 같은, 가상 기기 프로세스(617) 내로부터 I/O 명령어를 탐지할 수 있고 보호 비트맵은 트래핑하지 않고 이들 I/O 명령어들을 하이퍼바이저에게 패스-스루할 수 있다.

그러나, 하이퍼바이저(613)가 I/O 명령어를 에뮬레이팅한다면, 본 발명의 실시예가 제시하는 메카니즘은 에뮬레이션 이전에 검사가 이루어져 특정 주소를 기술 하는 I/O 명령어에서는, 어떠한 에뮬레이션도 수행되지 않도록 하이퍼바이저를 수정하는 것을 언급한다. 그러므로, 예를 들어, 확장물(615)이 특정 I/O 주소에서 하드웨어로의 직접적인 액세스를 요구한다면, 하이퍼바이저(613)는 수신된 I/O 명령어에 기술된 I/O 주소를 검사할 수 있고, 수신된 I/O 명령어가 확장물에 의해 이용된 특정 주소를 기술한다면, 하이퍼바이저는 에뮬레이션 없이 이들 I/O 명령어가 패스-스루하도록 할 수 있다. 이러한 방식으로 확장물은 가상 기기 환경 내로부터 하드웨어로의 직접적인 액세스까지도 가질 수 있다.

상술한 바와 같이, 상술된 메카니즘은 확장물 및 다른 소프트웨어 애플리케이션에게 가상 기기 환경 내로부터 I/O 포트를 통하는 하드웨어로의 직접적인 액세스 까지도 제공할 수 있다. 그러나, 확장물이나 다른 소프트웨어 애플리케이션이 I/O 포트를 통해 직접적으로 하드웨어를 액세스하도록 설계되지 않고, 대신에 이러한 하드웨어 액세스를 수행하는 오퍼레이팅 시스템에 의존한다면, 본 발명의 실시예가 제시하는 한 메카니즘은 가상 오퍼레이팅 시스템 프로세스(611)가 I/O 포트를 통하여 하드웨어(620)를 직접적으로 액세스하기를 요구할 확장물(615) 또는 다른 소프트웨어 애플리케이션으로부터 요청을 이 가상 프로세서가 탐지할 때, 이 프로세스는 그 요청을 하이퍼바이저에게 전달하여, 그 다음 프로세스가 확장물 또는 다른 소프트웨어 애플리케이션 대신에 적절한 I/O 명령어를 수행할 수 있도록 하이퍼바이저(613)를 수정하는 것을 언급한다. 대안으로, 상술한 메카니즘 등을 이용함으로써 가상 오퍼레이팅 시스템 프로세스(611)는 I/O 명령어를 직접 수행할 수 있고 하이퍼바이저(613)는 이 명령어가 패스-스루되도록 한다.

하드웨어와 통신하는 데에 자주 이용되는 다른 메카니즘은 DMA(Direct Memory Access)라고 알려져 있다. 본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, DMA는 장치 드라이버 또는 다른 소프트웨어 애플리케이션이 CPU에게 부담을 주지 않고 하드웨어 장치에게 또는 하드웨어 장치로부터 데이터를 전달하도록 할 수 있다. 보다 상세히 기술하자면, DMA는 데이터를 하나 이상의 물리적 메모리 세그먼트로부터 하드웨어 장치 자체의 물리적 레지스터 또는 유사한 구성요소로의 데이터 전송을 제공한다. 이러한 전송은 전용 DMA 칩과 같은 컴퓨팅 장치 상의 회로에 의해 조정되지만, CPU는 이 조정을 반드시 요구하지는 않는다.

일반적으로, DMA 요청은 오퍼레이팅 시스템 또는 소프트웨어 애플리케이션에 의하여 확장물에게 제공된 지원되는 API의 일부일 수 있다. 그러나, 상술했듯이 가상 지원 API가 가상 기기 환경 내에서 실행되는 가상 오퍼레이팅 시스템 프로세스에 의해 제공될 수 있기 때문에, 가상 기기 환경 내부에서 유래하는 DMA에 의해 기술된 메모리 주소는 하드웨어 장치를 가리켜야 하는 적절한 물리적 주소가 아닐 수 있다. 이는 복수의 요인 때문일 수 있지만, 하이퍼바이저가 DMA 주소를 하이퍼바이저에 의해 수행된 하드웨어 추상화의 일부로 수정할 수 있는 요인이 가장 두드러진다. 결과적으로, DMA를 적절하게 수행하기 위하여, 적절한 물리적 주소가 가상 기기 환경 안에서 이용될 수 있다.

본 발명의 실시예가 제시하는 DMA에 적절한 물리적 주소를 제공하는 하나의 메카니즘은 하이퍼바이저(613) 또는 가상 오퍼레이팅 시스템 프로세스(611)가 하드웨어에 의한 DMA 액세스에 적절한 메모리의 영역을 확장물(615)에 제공하는 것을 언급한다. 또한, 악성 DAM 또는 부적절한 DMA 요청으로부터 보호하기 위하여, 하이퍼바이저(613)는 보호되어야하는 주소를 가리키는 임의의 DMA를 블러킹시키거나 그렇지 않으면 적절한 주소로 편향시킬 수도 있다. 보호된 주소는, 예를 들면, 하이퍼바이저(613)가 처음으로 하드웨어(620) 상에 실행될 때 등의 이전에 결정될 수 있다. 보호된 주소는 또한 단순히 다른 하드웨어 장치와의 DMA 통신에 필요한 지원을 제공할 수 없는 메모리의 주소일 수도 있다. 또 다른 대안에서는, 보호된 주소는 현재 DMA 요청에 참여할 수 없는 임의의 또는 모든 주소일 수 있다. 종종 DMA의 보호된 주소의 사용을 방지하는 것은 컴퓨팅 장치(100) 상에 직접 전용 DMA 칩, 메모리 버스, 또는 유사한 회로에 의해 구현될 수 있다. 이러한 경우에는, 하이퍼바이저(613)가 소프트웨어 해결책을 통해 DMA를 블러킹하고 편향키기를 시도하는 대신에 이들 블럭의 알아내고 사용할 수 있다.

DMA에 적절한 메모리 주소를 확장물(615)에 제공하기 위하여, 본 발명의 실시예가 제시하는 한 메카니즘은 하이퍼바이저(613)가 확장물(615)의 오퍼레이션을 모니터링하고 다가올 DMA를 탐지하는 것을 의미한다. 대안으로, 가상 오퍼레이팅 시스템 프로세스(611)는 확장물의 오퍼레이션을 모니터링하고 관련 정보를 하이퍼바이저(613)에게 제공하거나, 가상 오퍼레이팅 시스템이 직접 다가오는 DMA를 탐지할 수 있다. 상술한 바와 같이, 확장물은 일반적으로 지원 API를 이용하여 다양한 자원으로의 액세스를 획득한다. 그러므로, 가상 오퍼레이팅 시스템 프로세스(611)에 의해 제공된 가상 지원 API를 통해 확장물(615)에 의해 호출된 함수를 모니터링함으로써 다가오는 DAM가 탐지될 수 있다. 특정 알려진 함수가 예를 들어, 메모리 의 블럭을 구축하라는 요청 또는 메모리의 물리적 주소에 대한 요청과 같이, DMA를 구축하는 데에 일반적으로 이용된다. 결과적으로, 가상 서비스 API로부터 이들 함수를 요청하는 확장물이 결정되어 DMA를 수행하려 할 수 있다.

가상 서비스를 계속적으로 모니터링하는 대신에 확장물(615), 하이퍼바이저(613), 또는 가상 오퍼레이팅 시스템 프로세스(611)에 의해 이루어지는 API 함수 호출은 일반적으로 DMA를 설정하는 데에 이용되는 알려진 함수가 호출될 때 불법 명령어를 포함하도록 가상 지원 API를 수정함으로써 가능한 DMA를 보다 효과적으로 탐지할 수 있다. 그 다음 이러한 불법 명령어는 트랩을 생성하고 하이퍼바이저 또는 가상 오퍼레이팅 시스템 프로세스에게 다가오는 DMA를 경고할 수 있다.

일단 하이퍼바이저(613) 또는 가상 오퍼레이팅 시스템 프로세스(611)가 상술한 메카니즘 등을 사용함으로써, 다가오는 DMA를 인지하게 된다면, 메모리 주소의 적절한 범위를 확장물(615)에게 제공하여, DMA가 올바르게 진행하도록 한다. 몇몇의 경우에서, 하이퍼바이저(613)는 적절한 범위의 메모리 주소를 제공할 수 있도록 메모리 스와핑 또는 유사한 메모리 관리를 수행할 수 있다. 대안으로, 하이퍼바이저(613)는 호스트 컴퓨팅 장치의 알려진 분산/수집(scatter/gather) 기능에 의존하여 DMA를 통한 하드웨어 장치에 송신되거나 이 장치로부터 수신될 정보를 적절한 메모리 범위에 위치시킬 수 있다. 그러나, 확장물(615)이 하이퍼바이저(613)에 의해 일반적으로 수행된 변환에 의한 별다른 주소를 예상하기 때문에, 상술한 메카니즘이 반대로 확장물에 영향을 더 미칠 가능성은 희박하다.

일단 메모리 주소가 확장물(615)에 제공되면, DMA가 완료될 때까지 이들 주 소에서 메모리를 액세스하는 단계로부터 추가적인 프로세스를 제거하는 것이 필요할 수 있다. 본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, 컴퓨팅 장치의 정상적인 동작 중에, DMA에 적절한 물리적 메모리는 일반적으로 매핑되지 않는다. 그러나, 가상 기기 환경 내의 메모리는 보통 하이퍼바이저에 의하여 거의 항상 매핑된다. 결과적으로, 가상 기기 환경에서 정상적으로 메모리는 다른 프로세스에 할당될 필요가 없는 방식으로 확장물에 전달된 메모리 주소를 보호할 필요가 있을 수 있다. 이러한 보호는 하이퍼바이저에 의해 이루어질 수 있으며, 이는 일반적으로 "피닝(pin)"이라고 알려진 메카니즘을 이용하여 DMA가 완료될 때까지 기술된 메모리 위치를 "핀다운(pin down)"시킬 수 있다.

물론, 일단 DMA가 완료되면, 하이퍼바이저는 특정 메모리 위치를 릴리즈하고나, 언피닝(unpin)시킬 있다. DMA의 완료는 다가오는 DMA가 탐지되는 경우와 아주 유사한 방식으로 삭제될 수 있으며, 이는 상세히 기술하였다. 예를 들면, 하이퍼바이저(613) 또는 가상 오퍼레이팅 시스템 프로세스(611)는 확장물(615)에 의해 호출된 함수들을 모니터링할 수 있다. 기술된 메모리 위치의 반환(deallocation)과 같은 함수는 DMA가 완료되었음을 나타낼 수 있고 하이퍼바이저(613)가 기술된 메모리 위치의 언피닝시킬 수 있다는 표시로 이용될 수 있다.

본 발명의 실시예가 제시하는 하드웨어와의 직접적인 통신의 다른 방법은 가상 기기 환경 내에서 실행되는 코드로 하드웨어 인터럽트를 전달하는 것에 관한 것이다. 본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, 하드웨어 인터럽트는 일반적으로 몇가지 종류의 응답 또는 긍정응답(acknowlegement)을 요구 하는 적절한 장치 드라이버 또는 다른 소프트웨어 애플리케이션에 송신되는, 하드웨어 장치로부터의 신호일 수 있다. 상술한 바와 같이, 호스트 오퍼레이팅 시스템은 특정 하드웨어 장치에 대해 적절한 장치 드라이버 또는 다른 제어 소프트웨어를 지원할 수 없기 때문에, 인터럽트는 가상 기기 환경 내부에서 실행되는 확장물로 지시될 필요가 있을 수 있다. 예를 들면, 도 1의 컴퓨팅 장치(100) 레가시 장치(199)에 접속됨을 도시한다. 오퍼레이팅 시스템(134)이 현대식의 오퍼레이팅 시스템이라면, 이 시스템은 레가시 장치(199)에 장치 드라이버를 적절하게 지원하지 않을 수 있다. 그러므로, 컴퓨팅 장치(100)의 사용자가 레가시 장치(199)를 사용할 수 있도록 하기 위하여, 장치 드라이버 또는 유사한 제어 소프트웨어가 가상 환경 내에서 실행되어야 한다. 결과적으로 레가시 장치(199)로부터 수신된 임의의 인터럽트는 가상 기기 프로세스로 지시되고 장치 드라이버에 패스-스루될 수 있을 때만 적절히 처리할 수 있다.

본 발명의 실시예가 제시하는 확장물(615)과 같은, 확장물로의 인터럽트를 지시하는 하나의 메카니즘은 수신된 인터럽트가 테이블 또는 유사한 구조에 비교되어, 가상 기기 프로세스(617)가 인터럽트를 처리해야할지 또는 호스트 오퍼레이팅 시스템 프로세스(601)에게 인터럽트를 전달해야 할지를 결정하는 것을 언급한다. 보다 상세히는, 오직 하나의 CPU를 가지는 컴퓨팅 장치에서, 가상 기기 프로세스(617)가 CPU에서 실행될 때 또는 호스트 오퍼레이팅 시스템 프로세스(601)가 CPU 에서 실행될 때에 인터럽트가 수신될 수 있다. 본 메카니즘은 가상 기기 프로세스(617)가 CPU 상에서 실행될 때 인터럽트가 도착하는 상황에 적용될 수 있다. 이러 한 경우에서, 하이퍼바이저(613)는 인터럽트의 근원 또는 목적을 결정한다. 그 다음 하이퍼바이저(613)는, 예를 들면, 테이블에서 검색을 실행함으로써, 가상 기기 환경에서의 확장물(615)과 같은 확장물에 의해 인터럽트가 적절하게 처리될 지 여부를 판정할 수 있다. 인터럽트가 확장물(615)에 의해 적절히 처리된다면, 하이퍼바이저(613)는 인터럽트를 가상 기기 프로세스(617)에 전달하므로, 즉 확장물에 전달할 수 있다. 인터럽트가 호스트 오퍼레이팅 시스템 프로세스(601)에 관련된 확장물 또는 다른 소프트웨어 애플리케이션에 의해 적절하게 처리된다면, 하이퍼바이저(613)는 하드웨어(620) 상의 가상 기기 프로세스(617)의 실행을 완료하고 호스트 오퍼레이팅 시스템 프로세스가 하드웨어에서의 실행을 다시 시작하도록 하여, 적절한 방식으로 인터럽트에 도달할 수 있다.

하이퍼바이저(613)가 인터럽트를 가상 기기 프로세스(617)에게 전달한다면, 하이퍼바이저는 가상 오퍼레이팅 시스템 프로세스(611)와의 호환성을 유지하기 위하여 인터럽트가 도달하는 인터럽트 라인의 개수를 수정할 수 있다. 그러므로, 인터럽트 라인을 활성화 시킬 때, 하이퍼바이저(613)는 인터럽트 라인 정보가 물리적 인터럽트 라인에 대응함을 검사할 수 있다. 그 다음 하이퍼바이저(613)는 물리적 인터럽트 라인과 에뮬레이팅된 인터럽트 라인 사이의 이행을 할 수 있다.

가상 기기가 가상 기기 프로세스(617)가 실행되고 있는 하드웨어(620)와는 다른 하드웨어를 에뮬레이팅할 수 있기 때문에, 하이퍼바이저(613)는 단일한 가상 기기 명령어를 호스트 하드웨어 상의 복수의 명령어로 에뮬레이팅할 필요가 있을 수 있다. 예를 들면, 가상 기기가 자신이 실행되고 있는 물리적 CPU와는 다른 유 형의 CPU를 에뮬레이팅하고 있다면, 에뮬레이팅되고 있는 CPU에 의해 수행되는 오직 하나의 CPU 싸이클이 필요할 수 있는 명령어들이 물리적 CPU에 의해 수행될 때 복수의 CPU 싸이클을 요구할 수 있다. 이러한 경우, 에뮬레이팅된 CPU와의 호환성을 유지하기 위하여 하이퍼바이저(613)가 단일한 방식으로 물리적 CPU의 복수의 싸이클을 처리하는 것이 중요할 수 있다. 그러므로, 하이퍼바이저(613)가 에뮬레이팅된 CPU의 하나의 싸이클과 상호 관련있는 물리적 CPU 상에서 일련의 싸이클을 실행시키는 도중에 있을 때 하드웨어 인터럽트가 도착한다면, 하이퍼바이저는 일련의 CPU 싸이클이 완료될 때까지 인터럽트를 무시하고, 큐잉하거나 지연시킬 수 있다.

본 발명의 실시예가 제시하는 가상 기기 프로세스의 확장물에 인터럽트를 지시하는 다른 메카니즘은 호스트 오퍼레이팅 시스템 프로세스가 제어를 가상 기기 프로세스에 전송하기 전에 인터럽트를 지연시키고, 인터럽트가 수신되자마자 가상 기기 프로세스에 제어를 전송하거나, 가상 기기 프로세스로의 적절한 포인터를 가지는 호스트 프로세스 내의 확장물을 실행하려고 시도하는 것을 언급한다. 상술한 바와 같이, 오직 하나의 CPU를 가지는 컴퓨팅 장치에서, 인터럽트는 가상 기기 프로세스(617)가 CPU에서 실행될 때 또는 호스트 오퍼레이팅 시스템 프로세스(601)가 CPU 상에 실행될 때 수신될 수 있다. 본 메카니즘은 호스트 오퍼레이팅 시스템 프로세스(601)가 CPU 상에서 실행될 때 인터럽트가 도착하는 상황에 적용할 수 있다. 초기 문제로, 호스트 오퍼레이팅 시스템은 적절한 장치 드라이버로 인터럽트를 지시하는 소정의 프로시저를 가질 수 있다. 이러한 프로시저는 예를 들면, 장치 드라이버가 로딩될 경우와 같이, 호스트 오퍼레이팅 시스템의 부팅 프로세스 중에 구 축될 수 있다. 그러므로, 확장물(615)의 호출은 이들 소정의 프로시저를 촉진시키고 호스트 오퍼레이팅 시스템 프로세스(601)에게 특정 하드웨어 장치로부터 수신된 인터럽트가 가상 기기 프로세스(617)에 지시되야 함을 알려주려고 시도할 수 있다.

결과적으로, 호스트 오퍼레이팅 시스템 프로세스(601)가 CPU 상에 실행될 때 확장물(615)에 송신되어야 할 인터럽트가 수신된다면, 호스트 오퍼레이팅 시스템 프로세스는 인터럽트를 처리하기에 적절한 소프트웨어가 가상 기기 프로세스(617) 내에서 실행하고 있다고 판정할 수 있는 경우를 제외하고 임의의 다른 인터럽트를 수신할 때 수행되는 것과 유사한 프로시저를 수행할 수 있다. 그 다음 호스트 오퍼레이팅 시스템 프로세스(601)는 예를 들어, 인터럽트를 비활성화 시키고, 하나 이상의 태스크를 완료하고, 가상 기기 프로세스(617)로 실행하기를 전환시킨 다음 인터럽트를 다시 활성화시킴으로써 인터럽트를 확장물(615)로 전송하려는 시도를 할 수 있다. 그러므로, 가상 기기 프로세스(617)는 인터럽트가 재활성화 될 때 CPU 상에 실행될 것이기 때문에, 인터럽트는 앞서 상세히 기술한 방식으로 가상 기기 프로세스(617)에 의해 수신되고 처리될 수 있다.

본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, 하드웨어 장치는 2개의 다른 종류의 인터럽트, 즉 인터럽트가 처리되고 응답될 때까지 활성화 상태로 남아있는 영속적인 인터럽트, 및 래치(latch)를 던진 다음 종료할 수 있는 일시적인 인터럽트를 일반적으로 이용할 수 있다. 상술한 메카니즘을 이용하면, 영속적인 인터럽트는 절대로 비활성화되지 않았기 때문에, 가상 기기 프로세스(617)는 인터럽트가 재활성화되자마자 영속적인 인터럽트를 탐지할 수 있다. 그러 므로, 영구적인 인터럽트에서, 가상 기기 프로세스(617)는 앞서 상세히 기술한 메카니즘을 이용하여 가상 기기 프로세스가 CPU 상에서 실행되었을 때 인터럽트가 처음으로 도달한 경우와 동일한 방식으로 인터럽트를 처리할 수 있다. 그러나, 일시적인 인터럽트에서는, 인터럽트가 일어났다는 것을 나타낼 수 있는 래치는 이전 상태로 돌아올 수 있다. 결과적으로, 다른 인터럽트가 래치를 다시 던지게 되지 않는 한, 가상 기기 프로세스(617)는 오퍼레이팅 시스템 프로세스(601)가 CPU 상에 실행되고 있었을 때 인터럽트가 일어났는지 전혀 알지 못할 수 있다. 그러므로, 호스트 오퍼레이팅 시스템 프로세스(601)는 실행을 가상 기기 프로세스(617)에 전송하기 이전에 일어나는 하나 이상의 일시적인 인터럽트를 추적하거나 저장할 수 있다. 호스트 오퍼레이팅 시스템 프로세스(601)는 하이퍼바이저(613)에 정보를 전달하여 하이퍼바이저에게 일시적인 인터럽트가 일어남을 알리고, 적절하다면 일시적인 인터럽트의 개수를 제공할 수 있다. 일단 가상 기기 프로세스(617)가 CPU 상에서 실행된다면, 하이퍼바이저(613)는 차례대로 일시적인 인터럽트를 에뮬레이팅하고, 확장물(615)이 그 인터럽트를 종류별로 응답하도록 할 수 있다. 일단 하이퍼바이저(613)가 일시적인 인터럽트를 에뮬레이팅하는 것을 완료한다면, 이 하이퍼바이저는 인터럽트를 다시 활성화시킨다.

몇몇의 경우에서, 하드웨어 인터럽트는 상기 프로시저가 제공할 수 있는 고속으로 처리되거나 응답되어야할 필요가 있을 수 있다. 이러한 경우에서, 본 발명의 실시예가 제시하는 메카니즘은 호스트 오퍼레이팅 시스템 프로세스(601)는 상술한 메카니즘을 이용하여 인터럽트를 비활성화시키고 하나 이상의 태스크를 완료하 기를 시도하는 대신에, 확장물(615)과 같은, 가상 기기 프로세스에서 실행되는 확장물에 의해 인터럽트가 적절하게 처리됨을 탐지할 때 실행을 가상 기기 프로세스(617)로 즉시 전송하는 것을 언급한다. 그러나, 하이퍼바이저(613)는 하나씩 스레딩(thread)되어 인터럽트의 탐지가 지연될 수 있고, 결과적으로 하이퍼바이저가 응답 또는 몇몇의 다른 정보를 기다리고 있다면 인터럽트를 서비스를 지연시킨다.

하이퍼바이저의 하나씩 스레딩되는 특성에 의한 지연을 피하기 위하여, 본 발명의 실시예가 또한 제시한 상술한 메카니즘의 변형은 하이퍼바이저가 복수의 CPU 컴퓨팅 장치를 에뮬레이팅하고 가상 오퍼레이팅 시스템 프로세스(611)가 복수의 CPU 환경에서 동작할 수 있는 것을 언급한다. 또한, 하이퍼바이저(613)는 적어도 하나의 에뮬레이팅된 CPU가 인터럽트를 수락할 수 있는 상태로 유지되도록 명령어의 실행을 구조화할 수 있다. 예를 들면, 상술한 바와 같이, 가상 기기 프로세스(617)는 명령을 가상 기기 프로세스로 전달하고, 그 다음 호스트 오퍼레이팅 시스템 프로세스의 언더피닝(underpinnning)을 캐슁하고 하드웨어(620) 상에서 가상 기기 프로세스를 실행함으로써 호스트 오퍼레이팅 시스템 프로세스(601)로부터 호출될 수 있다. 하이퍼바이저(613)는 호스트 오퍼레이팅 시스템 프로세스(601)로부터 수신된 명령을 다른 에뮬레이팅된 CPU에 전달함으로써 하나의 에뮬레이팅된 CPU를 인터럽트를 수락할 수 있는 상태로 유지할 수 있다. 결과적으로 이 유지된 CPU는 호스트 오퍼레이팅 시스템 프로세스(601)로부터의 명령을 처리할 수 없으므로, 이 CPU는 수신된 인터럽트를 즉시 처리할 수 있도록 보유될 수 있다.

결과적으로, 기본 호스트 오퍼레이팅 시스템 프로세스(601)가 하드웨어(620) 상에서 실행되었을 때 인터럽트가 도달하려 하고, 이 인터럽트는 낮은 지연이 요구된다면, 호스트 오퍼레이팅 시스템 프로세스는 가능한 빨리 가상 기기 프로세스(617)에 제어를 전송할 수 있다. 일단 가상 기기 프로세스(617)가 하드웨어(620) 상에서 실행되기 시작한다면, 가상 기기 프로세스의 적어도 하나의 에뮬레이팅된 CPU는 이 CPU가 인터럽트를 수락할 수 있는 상태이다. 그러므로, 다른 에뮬레이팅된 CPU들이 함수를 수행하고 있었거나 응답을 기다리고 있더라도, 인터럽트는 인터럽트를 위해 예약하였던된 적어도 하나의 에뮬레이팅된 CPU에 의해 효과적인 방식으로 처리될 수 있다. 그 다음 하이퍼바이저(613) 및 가상 오퍼레이팅 시스템 프로세스(611)는 앞서 상세히 기술하였던 방식으로, 확장물(615)과 같은 적절한 소프트웨어에 인터럽트를 전달하는 데에 필요한 단계를 수행할 수 있다. 또한, 상술한 바와 같이, 하이퍼바이저(613)가 물리적 메모리가 피닝기를 요구할 수 있기 때문에, 인터럽트를 수신하였던 에뮬레이팅된 CPU는 다른 에뮬레이팅된 CPU 또는 다른 프로세스로 제어를 리턴하기 이전에 인터럽트의 처리를 완료할 수 있다. 이러한 방식으로, 적어도 하나의 에뮬레이팅된 CPU는 인터럽트의 처리를 용이하게 하기 위하여 예약될 수 있다.

본 발명의 실시예가 제시하는 하드웨어 인터럽트의 지연을 낮추는 처리 동작을 제공하는 다른 메카니즘은 호스트 오퍼레이팅 시스템 프로세스(601)가 확장물(615)로부터 인터럽트 서비스 루틴에 대한 코드를 페칭(fetch)하고 직접 코드를 실행시켜 적절한 데이터 포인터가 가상 기기 프로세스(617)로 되돌아가도록 하는 것을 언급한다. 예를 들면, 호스트 오퍼레이팅 시스템 프로세스(601)는 가상 기기 프로세스(617)의 메모리 공간의 시작부로부터 적절한 인터럽트 서비스 루틴을 추적할 수 있다. 일단 찾아내면, 이들 인터럽트 서비스 루틴은 지연을 매우 낮추며 인터럽트를 처리하기 위하여 호스트 오퍼레이팅 시스템 프로세스(601)로 복사되고 이곳에서 실행될 수 있다.

인터럽트 서비스 루틴이 가상 기기 프로세스(617)의 프로세스 공간 내에 실행될 것을 의도하였기 때문에, 호스트 오퍼레이팅 시스템 프로세스(601)는, 이들 루틴을 복사하고 실행시킬 때, 가상 기기 프로세스에 데이터 포인터를 다시 제공하여 루틴이 적절히 동작하도록 할 수 있다. 예를 들면, 호스트 오퍼레이팅 시스템 프로세스(601)는 인터럽트 서비스 루틴의 적절한 명령어 또는 페이지 테이블 매핑을 변경시켜 가상 기기 프로세스(617) 내에서 메모리를 참조할 수 있다. 알려진 소프트웨어 장애 고립 기법이 이용되어 적절한 명령어를 수정하고 장애 고립 대책을 제공할 수 있다. 본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, 소프트웨어를 모니터링하고 있는 명령들 사이에 적절한 명령을 추가함으로써 소프트웨어의 실행을 모니터링할 수 있다. 모니터링되고 있는 소프트웨어를 재컴파일할 필요성을 없애기 위하여, 삽입된 명령은 컴파일된 코드에 삽입될 수 있는 저급 명령일 수 있다. 예를 들면, 액세스되고 있는 메모리 위치의 주소를 알려진 범위의 주소와 비교 등을 함으로써, 검사하는 명령어는 위치 내용물을 프로세서의 레지스터에 복사함으로써 특정 메모리 위치를 액세스하는 저급 명령어 이전에 삽입될 수 있다. 메모리 위치가 적절하지 않은 위치, 예를 들어, 주소의 적절한 범위 밖에 있다면, 액세스 요청으로의 적절한 주소로 대신하려는 수정이 이루어질 수 있 다. 이러한 방식으로, 인터럽트 처리 루틴이 가상 기기 프로세스(617) 대신 호스트 오퍼레이팅 시스템 프로세스(601)에서 실행될 수 있더라도, 각 메모리 액세스 명령어는 올바른 메모리 위치를 액세스하도록 수정될 수 있다.

상술한 바와 같이, 소프트웨어 장애 고립 기법은 인터럽트 처리 루틴이 호스트 오퍼레이팅 시스템 프로세스(601)에서 직접 실행되더라도 장애 고립 대책을 제공할 수도 있다. 예를 들면, 소프트웨어 장애 고립의 한 양태는 각 메모리 기록 명령어 이전에 그 기록 명령어가 가리키는 위치가 적절한 위치인지 확인하는 저급 명령어를 추가함으로써 수행될 수 있다. 본 기술 분야에서 숙련된 기술을 가진 자에게 공지된 바와 같이, 소프트웨어 부재는 부적절한 메모리 위치에 데이터가 기록되는 사태를 초래하기 때문에 종종 불안정하게 된다. 또한, 데이터가 기록될 주소가 바로 앞서는 명령어를 완료할 때까지 결정되지 않을 수 있기 때문에 이러한 부적절한 기록 명령어는 탐지하기 어려울 수 있다. 임의의 메모리를 기록하기 직전에 상술한 명령어들을 삽입함으로써, 이러한 기록 명령어가 가리키는 메모리 주소는, 예를 들면, 이 주소를 메모리 주소의 알려진 범위와 비교함으로써, 검사될 수 있다. 그러므로, 기록이 알려진 범위 이외의 메모리 위치를 가리킨다는 표시는 판독 명령어는 부적절하고 불안정하게 될 수 있음을 나타낸다. 결과적으로, 기록 명령어는 수정되거나 중지될 수 있고, 장애 고립 대책이 수행될 수 있다. 또한 샌드박스(sandbox) 제어 흐름, 특권 명령어의 사용 등을 포함하는 소프트웨어 장애 고립의 다른 양태들도 이용될 수 있다. 상술한 것들을 포함하는 소프트웨어 장애 고립의 다양한 양태에 관련되는 추가적인 정보는 Wahbe 등이 저술한 미국 특허번호 제 5,761,477에서 볼 수 있고, 이 문헌의 내용은 이 개시물에 관련된 본 발명 내에 포함되는 임의의 설명 및 제안을 더 설명하고 기술하기 위하여 그 전체가 참조로서 본 명세서에 포함되는 것으로 한다.

그러나, 상술한 몇몇의 메카니즘이 필요하지 않을 수 있는 경우에, 특정 컴퓨팅 장치는 복수의 물리적 CPU를 가질 수 있다. 예를 들면, 복수의 물리적 CPU를 구비한 컴퓨팅 장치에서, 하나의 물리적 CPU가 가상 기기 프로세스(617)를 항상 실행시키고 있을 수 있다. 이러한 경우에, 본 발명의 실시예가 제시하는 하나의 메카니즘은 종종 컴퓨팅 장치 자체의 일부인 전용 회로일 수 있는, 하드웨어 인터럽트의 제어 메카니즘이 확장물(615)과 같은 확장물을 요구하는 모든 인터럽트가 가상 기기 프로세스(617)가 항상 실행되는 물리적 CPU를 가리키도록 지시하는 것을 언급한다. 가상 기기 프로세스(617)는 물리적 CPU를 다른 프로세스와 공유하지만, 항상 동일한 물리적 CPU를 공유하는 경우라도, 확장물(615)을 요구하는 모든 인터럽트가 그 물리적 CPU를 가리키는 것은 현재 물리적 CPU에서 실행되고 있지 않더라도 인터럽트를 적절한 가상 기기 프로세스로 전송하는 상술한 메카니즘과 결합될 때도 여전히 최적 해결책을 제공할 수 있다.

그러나, 가상 기기 프로세스(617)가 복수의 물리적 CPU 중 임의의 하나에서 실행된다면, 인터 프로세서 메세지는 임의의 프로세서가 하드웨어 인터럽트에 응답하도록 하는 데에 이용될 수 있다. 예를 들면, 가상 기기 프로세스(617)가 제1 물리적 CPU에서 실행되게 되고 인터럽트가 확장물(615)에 의해 처리될 수 있는 제2 물리적 CPU에 도착한다면, 제2 물리적 CPU는 관련 정보가 제1 물리적 CPU와 통신하 여 확장물이 하드웨어 인터럽트를 처리할 수 있도록 한다. 본 기술 분야에서 숙련된 기술을 가진자에게 공지된 바와 같이, 하드웨어 인터럽트를 하나의 물리적 CPU에서 다른 CPU로 물리적으로 전달하는 것은 매우 어려울 수 있다. 결과적으로 인터-프로세서 메세지를 이용함으로써, 인터럽트는 적절한 물리적 CPU에 도착하는 것처럼 처리될 수 있다.

본 발명의 원리가 적용될 수 있는 복수의 가능한 실시예들을 검토하면, 도면에 관련하여 본 명세서에서 기술되는 실시예는 단지 예시적임을 의미하며 본 발명의 범위를 제한하도록 해선 안된다고 인식되어야 한다. 예를 들면, 본 기술 분야에서 숙련된 기술을 가진 자는 소프트웨어에 나타난 예시된 실시예의 몇몇의 구성요소가 하드웨어 등에 구현될 수 있거나 예시된 실시예는 본 발명의 사상으로부터 벗어나지 않고 구조 및 세부사항을 변경할 수 있다고 이해할 것이다. 마찬가지로 가상 기기 환경에 관련하여 기술된 메카니즘은 일반 오퍼레이팅 시스템 등의 최상부에 생성된 가상 환경에 적용될 수 있다고 이해될 것이다. 예를 들면, 가상 기기 환경에 관련하여 기술한 소프트웨어 장애 고립 기법은 가상 프로세스 및 호스트 프로세스 모두가 공통된 기본 오퍼레이팅 시스템을 공유할 때에도, 이 가상 프로세스로부터 호스트 프로세스까지 복사되는 확장물 루틴을 포함하는, 과도한 환경 전환이 바람직하지 못한 임의의 상황에 동일하게 적용될 수 있다. 그러므로, 본 명세서에서 기술된 발명은 특허청구범의 및 그 동등물의 범위 내에 포함될 수 있는 모든 실시예를 고려한다.

본 발명의 실시예는 가상 기기 환경 내의 확장물 및 다른 소프트웨어 애플리케이션이 호스트 컴퓨팅 장치에 접속된 하나 이상의 하드웨어 장치를 직접적으로 액세스하도록 한다.

Claims (36)

1. 가상 환경 내의 확장물에게 하드웨어 엘리먼트로의 직접적인 액세스를 제공하기 위한 컴퓨터 실행가능 명령어를 구비한 컴퓨터 판독가능 매체로서,

   상기 가상 환경은 상기 하드웨어 엘리먼트를 포함하는 컴퓨팅 환경을 이용하고,

   상기 하드웨어 엘리먼트와 관련된 메모리가 매핑된(memory mapped) 입/출력 통신을 탐지하고,

   상기 메모리가 매핑된 입/출력 통신에 대응하는 상기 하드웨어 엘리먼트의 물리적 메모리 주소를 하나 이상 결정하고,

   가상 환경 메모리의 세그먼트가 상기 결정된 하나 이상의 물리적 메모리 주소에 매핑되도록 메모리 매핑을 수정하는 컴퓨터 실행가능 명령어

   를 포함하는 컴퓨터 판독가능 매체.
2. 제1항에 있어서,

   상기 메모리가 매핑된 입/출력 통신이 완료된 이후에 상기 메모리 매핑을 수정 이전으로 되돌리는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
3. 제1항에 있어서,

   상기 메모리가 매핑된 입/출력 통신에 대하여, 상기 확장물에 상기 하드웨어 엘리먼트로의 직접적인 액세스가 허가되어야 하는지 여부를 판정하는 컴퓨터 실행가능 명령어를 더 포함하고,

   상기 메모리 매핑을 수정하는 명령어는 상기 확장물에 상기 하드웨어 엘리먼트로의 직접적인 액세스가 허가어야 하는 경우에만 수행되는

   컴퓨터 판독가능 매체.
4. 제1항에 있어서,

   상기 확장물은 상기 하드웨어 엘리먼트에 대한 장치 드라이버인 컴퓨터 판독가능 매체.
5. 제1항에 있어서,

   상기 가상 환경은 상기 컴퓨팅 환경에서 실행되는 가상 기기 애플리케이션에 의해 생성되는 컴퓨터 판독가능 매체.
6. 가상 환경 내의 확장물에게 하드웨어 엘리먼트로의 직접적인 액세스를 제공하는 컴퓨터 실행가능 명령어를 구비한 컴퓨터 판독가능 매체로서,

   상기 가상 환경은 상기 하드웨어 엘리먼트를 포함하는 컴퓨팅 환경을 이용하고,

   입/출력 포트를 참조하는 입/출력 통신을 탐지하고,

   상기 입/출력 포트가 상기 하드웨어 엘리먼트와 관련되는 경우 상기 입/출력 포트를 상기 가상 환경 내로부터 액세스되도록 상기 가상 환경과 상기 컴퓨팅 환경 간의 인터페이스를 수정하고,

   상기 가상 환경 내에 에뮬레이팅된 입/출력 포트를 제공하고, 상기 입/출력 포트가 상기 하드웨어 엘리먼트에 관련되지 않을 경우, 상기 인터페이스에 의해서 상기 입/출력 포트를 액세스하는 컴퓨터 실행가능 명령어

   를 포함하는 컴퓨터 판독가능 매체.
7. 제6항에 있어서,

   상기 인터페이스를 수정하는 상기 컴퓨터 실행가능 명령어는 입/출력 보호 비트맵을 수정하여 상기 입/출력 포트에 관련된 명령어에 의한 트랩(trap)을 방지하는 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능매체.
8. 제6항에 있어서,

   상기 입/출력 통신은 상기 가상 환경 내의 상기 확장물에 의해 이루어졌던 컴퓨터 판독가능 매체.
9. 제6항에 있어서,

   상기 입/출력 통신은 상기 확장물을 대신하여 상기 인터페이스에 의해 이루어졌던 컴퓨터 판독가능 매체.
10. 제6항에 있어서,

    상기 확장물은 상기 하드웨어 앨리먼트에 대한 장치 드라이버인 컴퓨터 판독가능 매체.
11. 제6항에 있어서,

    상기 가상 환경은 상기 컴퓨팅 환경에서 실행되는 가상 기기 애플리케이션에 의해 생성되는 컴퓨터 판독가능 매체.
12. 가상 환경 내의 확장물에게 하드웨어 엘리먼트로의 직접적인 액세스를 제공하는 컴퓨터 실행가능 명령어를 구비한 컴퓨터 판독가능 매체로서,

    상기 가상 환경은 상기 하드웨어 엘리먼트를 포함하는 컴퓨팅 환경을 이용하고,

    상기 가상 환경에서 상기 확장물에 의한 직접적인 메모리 액세스를 지시하는 하나 이상의 이벤트를 탐지하고 - 상기 직접적인 메모리 액세스는 상기 하드웨어 엘리먼트와 관련됨 - ,

    상기 직접적인 메모리 액세스와 관련된 적절한 물리적 직접 메모리 액세스 주소를 결정하고,

    상기 확장물에 의한 상기 직접적인 메모리 액세스 이전에 상기 가상 환경 내의 상기 확장물에게, 상기 적절한 물리적 직접 메모리 액세스 주소를 제공하고,

    상기 적절한 물리적 직접 메모리 액세스 주소에 대응하는 상기 컴퓨팅 환경의 물리적 메모리를 피닝(pin)하고,

    상기 적절한 물리적 직접 메모리 액세스 주소에 대응하는 상기 가상 환경의 가상 메모리를 피닝하는 컴퓨터 실행가능 명령어

    를 포함하는 컴퓨터 판독가능 매체.
13. 제12항에 있어서,

    상기 하나 이상의 이벤트를 탐지하는 컴퓨터 실행가능 명령어는

    상기 가상 환경에 의해 노출되는 지원되는 API를 통하여, 상기 확장물에 제공되는 하나 이상의 함수를 식별하고 - 상기 하나 이상의 함수는 상기 확장물에 의한 직접 메모리 액세스와 관련됨 - ,

    상기 확장물에 의한, 상기 하나 이상의 식별된 함수의 액세스를 탐지하는

    컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
14. 제13항에 있어서,

    상기 확장물에 의한, 상기 하나 이상의 식별된 함수의 액세스를 탐지하는 컴퓨터 실행가능 명령어는 상기 하나 이상의 식별된 함수를 수정하여 하나 이상의 불법 명령어를 포함하는 컴퓨터 실행가능 명령어를 포함하고,

    상기 하나 이상의 불법 명령어는 액세스될 때 트랩을 생성하고, 상기 트랩은 상기 확장물에 의한, 상기 하나 이상의 식별된 함수의 상기 액세스의 상기 탐지를 용이하게 하는 컴퓨터 판독가능 매체.
15. 제12항에 있어서,

    상기 적절한 물리적 직접 메모리 액세스 주소를 결정하는 컴퓨터 실행가능 명령어는

    상기 직접적인 메모리 액세스에 관련된 물리적 직접 메모리 액세스 주소가 보호된 주소인지 여부를 판정하고,

    상기 직접적인 메모리 액세스와 관련된 상기 물리적 직접 메모리 액세스 주소와 다른 주소가 될 상기 적절한 물리적 직접 메모리 액세스 주소가 상기 보호된 주소임을 판정하는 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
16. 제12항에 있어서,

    상기 확장물에 의한 상기 직접적인 메모리 액세스가 완료된 이후에 상기 적절한 물리적 직접 메모리 액세스 주소에 대응하는 상기 컴퓨팅 환경 내의 상기 물리적 메모리를 언피닝(unpin)하고,

    상기 확장물에 의한 상기 직접적인 메모리 액세스가 완료된 이후에 상기 적절한 물리적 직접 메모리 액세스 주소에 대응하는 상기 가상 환경 내의 상기 가상 메모리를 언피닝하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
17. 제12항에 있어서,

    상기 확장물은 상기 하드웨어 엘리먼트에 대한 장치 드라이버인 컴퓨터 판독가능 매체.
18. 제12항에 있어서,

    상기 가상 환경은 상기 컴퓨팅 환경에서 실행되는 가상 기기 애플리케이션에 의해 생성되는 컴퓨터 판독가능 매체.
19. 가상 환경 내의 확장물에게 하드웨어 엘리먼트로의 직접적인 액세스를 제공하는 컴퓨터 실행가능 명령어를 구비한 컴퓨터 판독가능 매체로서,

    상기 가상 환경은 상기 하드웨어 엘리먼트 및 프로세서를 포함하는 컴퓨팅 환경을 이용하고,

    상기 가상 환경이 상기 프로세서 상에서 실행되는 동안 상기 하드웨어 엘리먼트로부터의 인터럽트를 수신하고,

    상기 인터럽트가 상기 확장물에 의해 처리될지 여부를 판정하고,

    상기 인터럽트를 상기 확장물에 의해 처리해야할 경우, 상기 인터럽트와 관련된 물리적 인터럽트 라인과 상기 가상 환경 내의 에뮬레이팅된 물리적 인터럽트 라인 사이를 이행하는 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
20. 제19항에 있어서,

    상기 판정하는 컴퓨터 실행가능 명령어는 상기 확장물에 의해 처리될 수 있는 인터럽트를 나타내는 인터럽트 테이블을 참조하는 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
21. 제19항에 있어서,

    상기 판정 및 이행 이전에 명령어의 애뮬레이션을 완료하는 컴퓨터 실행가능 명령어를 더 포함하고,

    상기 명령어의 상기 에뮬레이션은 상기 인터럽트의 수신 이전에 초기화되었던 컴퓨터 판독가능 매체.
22. 제19항에 있어서,

    상기 컴퓨팅 환경은 적어도 하나의 추가적인 프로세서를 더 포함하고, 상기 인터럽트를 상기 확장물에 의해 처리해야 할 경우 및 상기 인터럽트가 상기 적어도 하나의 추가적인 프로세서 중 하나에 의해 수신되는 경우에 상기 프로세서에게 상기 적어도 하나의 추가적인 프로세스 중 상기 하나로부터의 인터-프로세서 인터럽트를 수행하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
23. 제19항에 있어서,

    상기 컴퓨팅 환경은 적어도 하나의 추가적인 프로세서 및 인터럽트 제어 회로를 더 포함하고, 상기 인터럽트 제어 회로는 상기 인터럽트를 임의의 상기 적어 도 하나의 추가적인 프로세서 대신에 상기 프로세서로 송신하도록 설계되는 컴퓨터 판독가능 매체.
24. 제19항에 있어서,

    상기 확장물은 상기 하드웨어 엘리먼트에 대한 장치 드라이버인 컴퓨터 판독가능 매체.
25. 제19항에 있어서,

    상기 가상 환경은 상기 컴퓨팅 환경에서 실행되는 가상 기기 애플리케이션에 의해 생성되는 컴퓨터 판독가능 매체.
26. 가상 환경 내의 확장물에게 하드웨어 엘리먼트로의 직접적인 액세스를 제공하는 컴퓨터 실행가능 명령어를 구비한 컴퓨터 판독가능 매체로서,

    상기 가상 환경은 상기 하드웨어 엘리먼트 및 프로세서를 포함하는 컴퓨팅 환경을 이용하고,

    상기 가상 환경이 상기 프로세서 상에서 실행되지 않을 동안 상기 하드웨어 엘리먼트로부터 인터럽트를 수신하고,

    상기 인터럽트가 상기 확장물에 의해 처리되어야 할지 여부를 판정하고,

    상기 인터럽트가 상기 확장물에 의해 처리되어야 할 경우 상기 확장물의 기능을 처리하는 인터럽트 서비스가 실행되도록 하는 컴퓨터 실행가능 명령어를 포함 하는 컴퓨터 판독가능 매체.
27. 제26항에 있어서,

    상기 확장물의 기능을 처리하는 상기 인터럽트 서비스가 실행되도록 하는 상기 컴퓨터 실행가능 명령어는

    인터럽트를 비활성화 시키고,

    제어를 전송하기 이전에 하나 이상의 명령어의 실행을 완료하고,

    제어를 전송하여 상기 가상 환경이 상기 프로세서에서 실행되는 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
28. 제27항에 있어서,

    상기 확장물의 기능을 처리하는 상기 인터럽트 서비스가 실행되도록 하는 상기 컴퓨터 실행가능 명령어는

    상기 확장물에 의해 처리될 일시적인 인터럽트를 캐슁하고 - 상기 일시적인 인터럽트는 상기 비활성화 이후에 수신됨 - ,

    상기 제어를 전송한 이후에 상기 캐슁된 일시적인 인터럽트를 시뮬레이트하고,

    상기 시뮬레이팅 이후에 인터럽트를 다시 활성화시키는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
29. 제26항에 있어서,

    상기 확장물의 기능을 처리하는 상기 인터럽트 서비스가 실행되도록 하는 상기 컴퓨터 실행가능 명령어는 제어를 전송하여 상기 인터럽트가 수신되었을 때 실행되고 있었던 하나 이상의 명령어의 실행이 완료되지 않아도 상기 가상 환경은 상기 프로세서 상에서 실행되는 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
30. 제26항에 있어서,

    상기 확장물의 기능을 처리하는 상기 인터럽트 서비스가 실행되도록하는 상기 컴퓨터 실행가능 명령어는

    제어를 전송하여 상기 가상 환경이 상기 프로세서 상에 실행되고 있고,

    상기 가상 환경에서 적어도 2개의 프로세스를 에뮬레이팅하고 - 상기 적어도 2개의 에뮬레이팅된 프로세스 중 적어도 하나는 인터럽트를 처리하기 위해 예약됨 - ,

    상기 적어도 하나의 예약된 에뮬레이팅된 프로세서를 이용하여 상기 확장물의 기능을 처리하는 상기 인터럽트 서비스를 실행시키는

    컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
31. 제26항에 있어서,

    상기 확장물의 기능을 처리하는 상기 인터럽스 서비스가 실행되도록 하는 상 기 컴퓨터 실행가능 명령어는

    상기 확장물의 기능을 처리하는 상기 인터럽트 서비스를 제공하는 컴퓨터 실행가능 명령어를 현재 실행되는 오퍼레이팅 시스템 프로세스에 복사하고 - 상기 현재 실행되는 오퍼레이팅 시스템 프로세스는 상기 인터럽트가 수신되었을 때 상기 프로세스 상에서 실행되고 있었음 - ,

    상기 가상 환경과 관련된 메모리 위치를 참조하도록 상기 복사된 컴퓨터 실행가능 명령어가 사용하는 하나 이상의 메모리 참조를 수정하고,

    상기 복사된 컴퓨터 실행가능 명령어들 간에 하나 이상의 컴퓨터 실행가능 명령어를 삽입하고 - 상기 하나 이상의 삽입된 컴퓨터 실행가능 명령어는 상기 복사된 컴퓨터 실행가능 명령어를 모니터링하거나 수정함 - ,

    상기 현재 실행되는 오퍼레이팅 시스템 프로세스 내에서, 상기 하나 이상의 수정된 메모리 참조 및 상기 하나 이상의 삽입된 컴퓨터 실행가능 명령어로 상기 복사된 컴퓨터 실행가능 명령어를 실행시키는

    컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
32. 제31항에 있어서,

    상기 하나 이상의 메모리 참조의 수정 및 상기 하나 이상의 컴퓨터 실행가능 명령어의 삽입은 소프트웨어 장애 고립을 제공하는 컴퓨터 판독가능 매체.
33. 제26항에 있어서,

    상기 컴퓨팅 환경은 적어도 하나의 추가적인 프로세서를 더 포함하고, 상기 컴퓨터 판독가능 매체는 상기 인터럽트를 상기 확장물에 의해 처리해야 하는 경우 및 상기 인터럽트가 상기 적어도 하나의 추가적인 프로세서 중 하나에 의해 수신될 경우 상기 적어도 하나의 추가적인 프로세서 중 상기 하나로부터 인터 프로세서 인터럽트를 수행하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
34. 제26항에 있어서,

    상기 컴퓨팅 환경은 적어도 하나의 추가적인 프로세서 및 인터럽트 제어 회로를 더 포함하고, 상기 인터럽트 제어 회로는 상기 인터럽트를 임의의 상기 적어도 하나의 추가적인 프로세서 대신에 상기 프로세서에 송신하도록 설게되는 컴퓨터 판독가능 매체.
35. 제26항에 있어서,

    상기 확장물은 상기 하드웨어 엘리먼트에 대한 장치 드라이버인 컴퓨터 판독가능 매체.
36. 제26항에 있어서,

    상기 가상 환경은 상기 컴퓨팅 환경에서 실행되는 가상 기기 애플리케이션에 의해 생성되는 컴퓨터 판독가능 매체.

Images