KR20200015721A

KR20200015721A - 인터럽트 요청 처리 방법 및 장치, 및 가상화된 디바이스

Info

Publication number: KR20200015721A
Application number: KR1020207000394A
Authority: KR
Inventors: 치쉬안 우; 레이 다이; 산시 천
Original assignee: 후아웨이 테크놀러지 컴퍼니 리미티드
Priority date: 2017-06-27
Filing date: 2018-06-26
Publication date: 2020-02-12
Also published as: EP3627330B1; TW201905686A; EP3627330A4; WO2019001434A1; US20200125397A1; EP3627330A1; CN109144679B; EP4235420A2; EP4235420A3; CN109144679A; TWI705375B; KR102339095B1; US11972285B2

Abstract

본 출원은 가상화된 디바이스, 및 가상화된 디바이스 상에서 실행되는 인터럽트 처리 방법을 제공한다. 그 방법은: 프로세서에 의해, 게스트 모드에서 다음의 동작들: 프로세서에 의해, 하드웨어로부터 인터럽트 요청을 수신하는 동작; 프로세서에 의해, 인터럽트 요청과 처리 엔티티 사이의 대응관계에 기초하여 수신된 인터럽트 요청의 처리 엔티티를 결정하는 동작; 및 수신된 인터럽트 요청의 처리 엔티티가 프로세서 상에서 현재 실행되는 가상 프로세서를 포함할 때, 프로세서에 의해, 인터럽트 요청과 인터럽트 서비스 루틴 사이의 대응관계에 기초하여, 수신된 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 결정하고, 인터럽트 서비스 루틴을 호출하여 인터럽트 요청을 처리하는 동작을 수행하는 단계를 포함한다. 이러한 방식으로, 애플리케이션 인터럽트 요청에 대해 프로세서의 트랩-인 및 트랩-아웃이 회피될 수 있어, 애플리케이션 인터럽트 요청의 처리 지연을 감소시킨다.

Description

인터럽트 요청 처리 방법 및 장치, 및 가상화된 디바이스

본 발명의 실시예들은 컴퓨터 기술들에 관한 것으로, 특히, 컴퓨터-내 인터럽트 요청 처리 방법, 가상화된 디바이스 등에 관한 것이다.

가상화 기술에서, 호스트 계층 및 가상 컴퓨터 계층을 포함하는 특정 소프트웨어 계층들은 물리적 컴퓨터를 위해 추가되어, 물리적 컴퓨터의 하드웨어에 대한 "가상화" 및 "격리"를 구현한다. 각각의 소프트웨어 계층은 사용자 모드 및 커널 모드와 같은 상이한 실행 상태들을 포함한다. 소프트웨어 계층들 및 실행 상태들의 다양성으로 인한 물리적 컴퓨터에서의 일부 요건에 대한 처리 단계들이 증가하고, 그에 의해 이들 요건들에 대한 처리 지연이 증가한다.

인터럽트 처리는 가상화된 디바이스의 주요 요건이다. 가상화된 디바이스에 대한 기존의 인터럽트 처리 절차(물리적 인터럽트 처리 절차)에서는, 하드웨어(예컨대, 네트워크 인터페이스 카드, 키보드, 또는 마우스)에 의해 생성된 인터럽트 요청이 프로세서에 전송된다. 그 후, 프로세서는 인터럽트 요청을 분배하기 위해 호스트 내의 인터럽트 처리 모듈을 호출한다. 인터럽트 요청이 가상 컴퓨터에서 인터럽트 서비스 루틴에 의해 처리될 필요가 있을 때, 인터럽트 처리 모듈은 인터럽트 요청을 가상 컴퓨터에 추가로 분배한다. 이러한 크로스 오버 소프트웨어 계층들 및 그 안에서의 상이한 실행 상태들 사이의 가능한 전환은 그러한 인터럽트 요청에 대한 처리 지연을 증가시킨다. 특히, 서비스들을 구현하기 위한 다양한 애플리케이션이 가상 컴퓨터 상에 배치될 때, 이들 애플리케이션의 인터럽트 서비스 루틴들은 모두 가상 컴퓨터 상에 배치된다. 인터럽트 처리 절차는 실제로 서비스 처리 절차의 일부이다. 따라서, 이러한 지연의 증가는 서비스 처리 지연의 증가를 야기한다.

본 출원은, 가상화된 디바이스 상의 애플리케이션 인터럽트 요청의 처리 지연을 감소시키고, 추가로 서비스 처리를 가속화하기 위한, 인터럽트 요청 처리 방법 및 장치, 가상화된 디바이스 등을 제공한다.

제1 양태에 따르면, 본 출원은 가상화된 디바이스를 제공한다. 가상화된 디바이스는 하드웨어 계층, 하드웨어 계층에서 실행되는 호스트, 및 호스트 상에서 실행되는 가상 컴퓨터를 포함한다. 가상 컴퓨터는 가상 컴퓨터를 서빙(serving)하는 하나 이상의 가상 프로세서를 포함한다.

호스트는 하드웨어 계층으로부터 인터럽트 요청을 수신할 수 있도록 가상 컴퓨터의 가상 프로세서를 구성하도록 구성된다. 이것은 레지스터 비트를 수정함으로써 구현된다. 구체적으로, 호스트는 레지스터 내에 있고 가상 프로세서의 인터럽트 수신 모드를 표시하는데 사용되는 레지스터 비트를 수정함으로써, 게스트 모드에서 하드웨어 계층으로부터 모든 인터럽트 요청들을 직접 수신하도록 가상 프로세서를 인에이블한다. 가상 프로세서의 인터럽트 수신 모드는 하나 이상의 레지스터 비트에 의해 표시된다. 레지스터는 가상 프로세서를 실행하는 물리적 프로세서와 연관된 물리적 레지스터이다. 따라서, 물리적 레지스터는 이 구성 단계에서 최종적으로 수정될 필요가 있다.

가상 컴퓨터(이하에서는 "현재의 가상 프로세서"일 수 있음)는 하드웨어 계층으로부터 인터럽트 요청을 수신하고, 인터럽트 요청에 기초하여 수신된 인터럽트 요청의 처리 엔티티를 결정하도록 구성된다. 수신된 인터럽트 요청의 처리 엔티티가 가상 컴퓨터의 현재의 가상 프로세서를 포함할 때, 가상 컴퓨터는 인터럽트 요청에 기초하여 수신된 인터럽트 요청에 대응하는 인터럽트 서비스 루틴(구체적으로는, 인터럽트 서비스 루틴의 어드레스)을 결정하고, 인터럽트 서비스 루틴을 호출하여 인터럽트 요청을 처리한다. 구체적으로, 수신된 인터럽트 요청은 인터럽트 요청의 식별자, 예를 들어, IRQ ID를 운반할 수 있다. 처리 엔티티 및 인터럽트 서비스 루틴은 후속하여 식별자에 기초하여 결정된다.

가상화된 디바이스에서 가상 컴퓨터(예컨대, 가상 머신 또는 libOS)에 의해 동작을 수행하는 것은 가상 컴퓨터를 서빙하는 가상 프로세서가 동작을 수행하는 것으로 이해될 수 있다는 점에 유의해야 한다. 따라서, "가상 컴퓨터의 현재의 가상 프로세서"는 전술한 구성이 실행되기 시작한 후에 전술한 구성을 수행하고 있는 가상 프로세서로서 이해될 수 있다. 또한, 본 출원에서의 인터럽트 요청의 "처리 엔티티"는 하나 이상의 가상 프로세서일 수 있거나, 또는 호스트일 수 있다. 분명히, 이들 2가지 타입의 처리 엔티티는 본질적으로 물리적 프로세서들이고, 상이한 모드들에서의 물리적 프로세서들이다.

구체적으로, 가상 컴퓨터는 일부 정보 및 인터럽트 요청에 기초하여 인터럽트 요청 및 인터럽트 서비스 루틴의 처리 엔티티를 결정한다. 정보는 인터럽트 요청(의 식별자), 처리 엔티티, 및 인터럽트 서비스 루틴(의 어드레스) 사이의 대응관계를 포함한다. 정보는 정보를 사용하는 가상 프로세서에 의해 액세스될 수 있는, 게스트 어드레스 공간과 같은 저장 영역에 저장된다. 이러한 방식으로, 가상 프로세서는 트랩 아웃(trap out) 없이 정보에 직접 액세스할 수 있다. 대응관계는 호스트에 의해 업데이트될 수 있다. 정보 관리를 용이하게 하고 저장 공간을 절약하기 위해, 정보는 복수의 VM의 모든 가상 프로세서에 액세스가능한 저장 영역에 저장될 수 있어, 정보는 임의의 가상 프로세서에 의해 쉽게 액세스될 수 있다. 추가로, 호스트는 정보를 업데이트할 수 있기 때문에, 호스트는 또한 정보에 액세스할 수 있다.

이러한 가상화된 디바이스에서, 가상 컴퓨터는 하드웨어 계층으로부터 모든 인터럽트 요청들을 직접 수신하고, 인터럽트 요청들을 분배할 수 있다는 것을 알 수 있다. 인터럽트 요청의 처리 엔티티가 가상 컴퓨터의 현재의 가상 프로세서를 포함할 때, 인터럽트 요청은 가상 컴퓨터에 의해 직접 처리될 수 있다. 인터럽트 요청이 애플리케이션 인터럽트 요청이고, 인터럽트 요청의 처리 엔티티가 가상 컴퓨터의 현재의 가상 프로세서를 포함하는 경우, 가상 컴퓨터는 인터럽트 요청을 직접 처리할 수 있다. 이것은 가상 컴퓨터의 트랩-인(trap-in) 및 트랩-아웃(trap-out)을 회피하고, 인터럽트 처리 절차가 가상화된 디바이스의 복수의 계층을 크로스하는 것을 방지하고, 애플리케이션 인터럽트 요청의 처리 지연을 감소시킨다. 분명히, 이것은 또한 게스트 운영 체제 인터럽트 요청의 처리 지연을 감소시킨다.

제1 양태를 참조하면, 제1 구현에서, 가상 컴퓨터가 수신된 인터럽트 요청의 처리 엔티티가 가상 컴퓨터의 현재의 가상 프로세서를 포함하지 않는 다른 가상 프로세서라고 결정하면, 가상 컴퓨터는 다른 가상 프로세서가 서비스 가능인지를 결정한다. 다른 가상 프로세서가 서비스 가능인 경우, 가상 컴퓨터는 IPI 인터럽트 요청을 다른 가상 프로세서의 하나 이상의 서비스 가능 가상 프로세서에 전송하도록 물리적 인터럽트 제어기를 동작시키고, IPI 인터럽트 요청은 수신된 인터럽트 요청의 식별자를 운반한다. 이 동작을 수행하기 위한 전제조건은, 호스트가 가상 프로세서에 대한 인터럽트 제어기 동작 모드를 구성하여, 가상 프로세서가 트랩 아웃 없이 물리적 인터럽트 제어기를 동작시킬 수 있다는 것이다. IPI를 수신한 후에, 서비스 가능 가상 프로세서가 IPI에 대응하는 인터럽트 서비스 루틴을 실행한다. 인터럽트 서비스 루틴의 특정 구현은, IPI에서 운반되는, 인터럽트 요청의 식별자에 대응하는 인터럽트 서비스 루틴을 호출하고 있다.

본 명세서에서 "다른 가상 프로세서"는 가상 컴퓨터를 서빙하는 가상 프로세서일 수 있거나, 또는 다른 가상 컴퓨터를 서빙하는 가상 프로세서일 수 있다. 인터럽트 수신 모드와 유사하게, 가상 프로세서의 인터럽트 제어기 동작 모드는 가상 프로세서를 실행하는 물리적 프로세서와 연관된 레지스터의 하나 이상의 비트에 의해 표시된다.

관리를 용이하게 하고 공간을 절약하기 위해, 가상 프로세서가 서비스 가능(in-service) 또는 서비스 불능(out-of-service) 상태에 있는지에 관한 모든 정보가 모든 가상 프로세서에 액세스가능한 저장 영역에 저장되어, 임의의 가상 프로세서에 의해 액세스될 수 있다. 또한, 호스트는 가상 프로세서를 스왑 인(swap in) 또는 스왑 아웃(swap out)할 때 가상 프로세서의 상태를 수정할 수 있기 때문에, 정보는 호스트에 의해 액세스될 수 있다. 가상 프로세서가 IPI 인터럽트 요청을 다른 가상 프로세서에 전송할 때, 가상 프로세서는 다른 가상 프로세서를 실행하는 물리적 프로세서를 알 필요가 있다. 가상 프로세서를 실행하는 물리적 프로세서에 관한 정보(예컨대, 다음의 실시예에서의 CORE ID)는 또한 상태 정보를 저장하는 것과 유사한 방식으로 저장될 수 있다. 정보는 또한 가상 프로세서가 서비스 가능 또는 서비스 불능인지에 따른 다음의 해결책에서 또는 IPI가 전송되는 다음의 해결책에서 사용될 수 있다.

가상 컴퓨터의 현재의 가상 프로세서가 인터럽트 요청을 수신하지만 현재의 가상 프로세서가 인터럽트 요청의 처리 엔티티가 아니고, 인터럽트 요청을 처리할 수 있는 가상 프로세서가 서비스 가능인 경우, 현재의 가상 프로세서는, 트랩 아웃 없이 IPI 인터럽트를 사용하여, 현재의 가상 프로세서에 의해 처리될 수 없는 인터럽트 요청을, 인터럽트 요청을 처리할 수 있는 서비스 가능 가상 프로세스에 직접 전송할 수 있다는 것을 알 수 있다. 이것은, 현재의 가상 프로세서가 트랩 아웃하고 나서 호스트가 인터럽트 요청을 포워딩하는 시간을 절약하여, 다른 가상 프로세서가 인터럽트 요청을 가능한 한 빨리 수신하고 처리할 수 있게 한다. 이것은 애플리케이션 인터럽트 요청의 처리 지연을 추가로 감소시킨다. 더욱 구체적인 구현 방법들에 대해서는, 제6 양태 및 제6 양태의 구현들을 참조한다.

제1 양태 또는 제1 양태의 제1 구현을 참조하면, 제2 구현에서, 가상 컴퓨터는: 수신된 인터럽트 요청의 처리 엔티티가 가상 프로세서의 현재의 가상 프로세서를 포함하지 않는 다른 가상 프로세서이고, 다른 가상 프로세서 중 어느 것도 서비스 가능이 아니라고 결정되는 경우, 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하고, 수신된 인터럽트 요청의 식별자를 현재의 가상 프로세서와 호스트 둘 다에 액세스가능한 저장 영역에 기록하도록 추가로 구성된다. 분명히, 본 명세서에서 식별자가 기록될 때, 인터럽트 요청이 타겟 가상 프로세서에 의해 처리될 것임을 표시하기 위해, 식별자와 타겟 가상 프로세서 사이에 관계가 확립될 필요가 있다.

본 출원에서, A와 B 둘 다에 액세스가능한 저장 영역은 구체적으로 A와 B 둘 다에 의해 액세스될 수 있는 공유 메모리일 수 있거나, 또는 A 및 B에 의해 액세스될 수 있는 다른 타입의 저장 공간일 수 있다.

대응하여, 호스트는: 타겟 가상 프로세서가 스왑 인된 후에, 저장 영역에 기록된 식별자에 기초하여 인터럽트 요청을 타겟 가상 프로세서에 전송하여, 타겟 가상 프로세서가 트랩 인 후에 인터럽트 요청을 처리하게 하도록 추가로 구성된다. 구체적으로, 처리 엔티티 내의 임의의 가상 프로세서가 호스트에 의해 스왑 인된 후에 그리고 가상 프로세서가 트랩 인하기 전에, 호스트는 저장 영역을 체크하고 가상 프로세서가 처리되지 않은 인터럽트 요청을 갖는다는 것을 발견한다. 따라서, 호스트는, 스왑 인된 가상 프로세서에, 수신된 인터럽트 요청과 동일한 특성을 갖는 인터럽트 요청을 전송한다(실제로, 인터럽트 요청은 가상 프로세서가 스케줄링되는 물리적 프로세서에 전송된다). 스왑 인된 가상 프로세서는 트랩 인 후에 인터럽트 요청을 수신하고 처리한다.

동일한 특성을 갖는 인터럽트 요청은 초기에 수신된 인터럽트 요청과 동일한 식별자를 갖는 인터럽트 요청일 수 있거나, 또는 초기에 수신된 인터럽트 요청의 식별자를 운반하는 IPI 인터럽트일 수 있다.

본 명세서에서 "타겟 가상 프로세서"는 인터럽트 요청의 모든 처리 엔티티일 수 있다. 따라서, 본 명세서에서 타겟 가상 프로세서를 결정하고 나서 식별자를 기록하는 것은, 이러한 특정 구현: 인터럽트 요청의 모든 처리 엔티티에 대해 인터럽트 요청의 식별자를 직접 기록하는 것을 포함한다는 것이 이해될 수 있다.

가상 컴퓨터의 현재의 가상 프로세서가 인터럽트 요청을 수신하지만 현재의 가상 프로세서가 인터럽트 요청의 처리 엔티티가 아니고, 인터럽트 요청을 처리할 수 있는 타겟 가상 프로세서가 서비스 불능인 경우, 가상 컴퓨터는 현재의 가상 프로세서와 호스트 둘 다에 액세스가능한 저장 영역에 인터럽트 요청의 식별자를 기록하여, 타겟 가상 프로세서를 스왑 인한 후에, 호스트가 저장 영역에 액세스함으로써, 처리를 위해 타겟 가상 프로세서에 동일한 인터럽트 요청을 전송할 수 있게 한다는 것을 알 수 있다. 타겟 가상 프로세서는 트랩 인 후에 인터럽트 요청을 처리할 수 있다. 이것은, 현재의 가상 프로세서가 트랩 아웃하지 않는 동안 복수의 가상 프로세서 사이의 인터럽트 요청 공유를 구현하고, 인터럽트 요청의 처리 지연을 추가로 감소시킨다.

또한, 하나의 가상 프로세서에 의해서만 처리될 필요가 있는 인터럽트 요청의 경우, 인터럽트 요청을 한번 전송한 후에, 호스트는 다른 처리 엔티티의 대응하는 기록을 클리어(clear)할 수 있다. 이것은 인터럽트 요청이 복수의 가상 프로세서에 의해 반복적으로 처리되는 것을 방지할 수 있다.

제1 양태의 제2 구현을 참조하면, 제3 구현에서, 호스트는 인터럽트 요청의 우선순위를 설정하고, 우선순위를 호스트와 가상 컴퓨터 둘 다에 액세스가능한 저장 영역에 기록하도록 추가로 구성된다. 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하는 양태에서, 가상 컴퓨터는 수신된 인터럽트 요청의 우선순위 및 가상 프로세서의 우선순위에 기초하여 타겟 가상 프로세서를 결정하도록 구체적으로 구성되며, 여기서 모든 가상 프로세서들의 상태들 및 우선순위들은 모든 가상 컴퓨터들에 액세스가능한 저장 영역에 저장된다.

가상 프로세서의 우선순위는 가상 프로세서 상의 현재의 작업의 우선순위이다. 현재의 작업은, 가상 프로세서가 서비스 불능일 때 실행중이 아니고, 가상 프로세서가 서비스 가능일 때 실행중이다.

정보 관리를 용이하게 하기 위해, 인터럽트 요청의 우선순위는 전술한 구현에서 언급된 인터럽트 서비스 루틴과 같은 정보와 동일한 저장 영역에 저장될 수 있고; 가상 프로세서의 우선순위는 전술한 구현에서 언급된 가상 프로세서의 상태와 동일한 저장 영역에 저장될 수 있다.

인터럽트 우선순위가 도입되고, 그 다음에 인터럽트 우선순위는 적절한 타겟 가상 프로세서를 선택하기 위해 가상 프로세서 상의 현재의 작업의 우선순위와 비교된다. 이것은 가상 프로세서 상의 현재의 작업에 대한 비교적 큰 영향을 회피한다.

제1 양태의 제3 구현을 참조하면, 제4 구현에서, 가상 컴퓨터는 수신된 인터럽트 요청의 식별자에 기초하여 호스트와 가상 컴퓨터 둘 다에 액세스가능한 저장 영역을 검색하여, 수신된 인터럽트 요청의 우선순위를 획득하고; 수신된 인터럽트 요청의 우선순위를 모든 서비스 가능 가상 프로세서의 우선순위들과 비교하고; 모든 서비스 가능 가상 프로세서들의 우선순위들이 수신된 인터럽트 요청의 우선순위보다 높은(또는 그와 같은) 경우, 수신된 인터럽트 요청의 처리 엔티티에 포함된 모든 가상 프로세서들을 타겟 가상 프로세서로서 결정하거나; 또는 하나 이상의 서비스 가능 가상 프로세서의 우선순위가 수신된 인터럽트 요청의 우선순위보다 낮은 경우, 수신된 인터럽트 요청의 처리 엔티티에 포함된 모든 가상 프로세서들 중에서 가장 높은 우선순위를 갖는 가상 프로세서를 타겟 가상 프로세서로서 결정한다.

제1 양태의 제4 구현을 참조하면, 제5 구현에서, 하나 이상의 서비스 가능 가상 프로세서의 우선순위가 수신된 인터럽트 요청의 우선순위보다 낮은 경우, 가상 컴퓨터는 모든 서비스 가능 가상 프로세서들 중에서 가장 낮은 우선순위를 갖는 가상 프로세서를 중계 가상 프로세서(transit virtual processor)로서 결정하고, IPI 인터럽트 요청 - IPI 인터럽트 요청은 타겟 가상 프로세서의 식별자를 운반함 - 을 중계 가상 프로세서에 전송하여, 중계 가상 프로세서가 IPI 인터럽트 요청에 따라 트랩 아웃하게 하도록 추가로 구성되고; 호스트는 중계 가상 프로세서가 트랩 아웃한 후에 타겟 가상 프로세서를 스왑 인하도록 추가로 구성된다. 더욱 구체적인 구현 방법들에 대해서는, 제6 양태 및 제6 양태의 구현들을 참조한다.

현재의 가상 프로세서가 가장 낮은 우선순위를 갖는 가상 프로세서인 경우, 현재의 가상 프로세서는 타겟 가상 프로세서의 식별자를 호스트에 전송하고, 이어서 트랩 아웃한다. 다시 말해서, 어떠한 IPI 인터럽트 요청도 전송될 필요가 없고, 현재의 가상 프로세서는 스왑 아웃될 "중계 가상 프로세서"이다.

다시 말해서, 인터럽트 요청의 우선순위가 가장 낮은 경우, 인터럽트 요청의 식별자만이 기록되고, 타겟 가상 프로세서의 스왑-인이 능동적으로 트리거될 필요가 없거나; 또는 서비스 가능 가상 프로세서의 우선순위가 인터럽트 요청의 우선순위보다 낮은 경우, 이것은 인터럽트 요청이 가상 프로세서의 현재의 작업 이전에 처리될 수 있고, 가상 프로세서는 스왑 아웃될 수 있다는 것을 표시한다. 스왑 아웃될 수 있는 가상 프로세서들로부터 가장 낮은 우선순위를 갖는 가상 프로세서가 결정되고 중계 프로세서로서 사용된다. 인터럽트 요청의 처리 엔티티로부터 가장 높은 우선순위를 갖는 가상 프로세서가 결정되고 타겟 가상 프로세서로서 사용된다. 그 다음, 타겟 가상 프로세서가 스왑 인되고, 중계 가상 프로세서가 스왑 아웃된다. 이것은 가상 프로세서의 현재의 작업에 대한 영향을 최소화한다. 본 명세서에서 "가장 낮은" 또는 "가장 높은"은 본 출원의 구현일 뿐이다. 예를 들어, 시스템이 허용하는 경우, 두번째로 가장 낮은 또는 두번째로 가장 높은 우선순위를 갖는 대응하는 가상 프로세서가 대안적으로 선택될 수 있다.

제1 양태의 제2 구현을 참조하면, 제6 구현에서, 수신된 인터럽트 요청의 처리 엔티티가 가상 컴퓨터의 현재의 가상 프로세서를 포함하지 않는 다른 가상 프로세서이고, 다른 가상 프로세서 중 어느 것도 서비스 가능이 아니라고 결정될 때, 가상 컴퓨터는 타겟 가상 프로세서의 식별자를 호스트에 전송하고, 타겟 가상 프로세서를 트랩 아웃하도록 추가로 구성되고, 타겟 가상 프로세서는 처리 엔티티 내의 임의의 가상 프로세서 또는 처리 엔티티 내의 가장 높은 우선순위를 갖는 가상 프로세서이고; 호스트는 타겟 가상 프로세서의 식별자에 기초하여 타겟 가상 프로세서를 스왑 인하고, 가상 프로세서의 현재의 가상 프로세서를 스왑 아웃하도록 추가로 구성된다.

예를 들어, 때때로, 인터럽트 요청은 매우 긴급하거나, 우선순위가 정의될 때 매우 높은 우선순위를 가지며, 인터럽트 요청은 즉시 처리될 필요가 있다. 따라서, 중계 가상 프로세서가 결정될 필요가 없고, 현재의 가상 프로세서가 직접 스왑 아웃되고, 임의의 처리 엔티티 또는 가장 높은 우선순위를 갖는 처리 엔티티가 스왑 인되어, 인터럽트 요청을 가능한 한 빨리 처리한다.

일부 다른 구현들에서, 타겟 가상 프로세서를 능동적으로 스왑 인하는 방식으로, 인터럽트 요청의 식별자는 사전에 기록되지 않을 수 있다; 대신에, 인터럽트 요청의 식별자는 타겟 가상 프로세서의 스왑-인을 트리거하는데 사용되는 이벤트 또는 메시지에서 운반된다. 예를 들어, 전술한 제5 구현에서의 IPI 인터럽트 요청은 타겟 가상 프로세서의 식별자에 더하여 인터럽트 요청의 식별자를 추가로 운반한다. 중계 가상 프로세서는 트랩 아웃할 때 인터럽트 요청의 식별자를 호스트에 전송한다. 타겟 가상 프로세서를 스왑 인한 후에, 호스트는 식별자에 기초하여 타겟 가상 프로세서와 동일한 인터럽트 요청을 전송한다.

제1 양태의 전술한 구현들 중 어느 하나를 참조하면, 일부 구현들에서, 가상화된 디바이스는, 모든 가상 프로세서들(즉, 모든 가상 머신들)에 액세스가능한 저장 영역에, 가상 프로세서가 서비스 가능 또는 서비스 불능 상태에 있는지에 관한 정보를 저장한다. 구체적으로, 정보는 하나 이상의 테이블을 사용하여 기록될 수 있다. 설명을 용이하게 하기 위해, 기록은 본 출원의 일부 실시예들에서 "실행 엔티티 테이블(running entity table)"로서 지칭된다. 그러나, 테이블의 이름은 본 출원에서 제한되지 않는다. 마찬가지로, 다음의 구현들에서 나타나는 "인터럽트 벡터 테이블" 또는 "인터럽트 매핑 테이블"의 이름도 본 출원에서 제한되지 않는다.

제1 양태의 전술한 구현들 중 어느 하나를 참조하면, 일부 구현들에서, 가상 프로세서의 스케줄링은 호스트에 의해 수행되고, 구체적으로, 호스트 내의 가상 머신 모니터링 장치에 의해 수행될 수 있다. 실행 엔티티 테이블의 업데이트가 호스트에 의해 수행된다. 이것은 호스트가 실행 엔티티 테이블의 저장 영역에 액세스할 수도 있다는 것을 의미한다. 구체적으로, 호스트가 가상 프로세서를 스왑 인한 후에 그리고 가상 프로세서가 트랩 인하기 전에, 실행 엔티티 테이블 내의 가상 프로세서의 대응하는 상태가 서비스 가능으로 업데이트되고, 그 후에 가상 프로세서가 트랩 인한다. 가상 프로세서가 트랩 아웃한 후에 그리고 호스트가 가상 프로세서를 스왑 아웃하기 전에, 실행 엔티티 테이블 내의 가상 프로세서의 대응하는 상태가 서비스 불능으로 업데이트되고, 그 후에 호스트가 가상 프로세서를 스왑 아웃한다.

모든 가상 프로세서들 및 호스트에 의해 액세스될 수 있는 실행 엔티티 테이블을 사용하여 적시에(in a timely manner) 가상 프로세서의 최신 상태가 획득될 수 있다. 인터럽트 요청의 처리 엔티티가 서비스 가능인 경우, 현재의 가상 프로세서가 트랩 아웃 없이 인터럽트 요청을 서비스 가능 가상 프로세서에 직접 전송할 수 있거나; 또는 인터럽트 요청의 처리 엔티티들 중 어느 것도 서비스 가능이 아닌 경우, 현재의 가상 프로세서가 트랩 아웃 없이 인터럽트 요청을 실행 엔티티 테이블에 기록하거나 또는 타겟 가상 프로세서의 트랩-인을 추가로 트리거할 수 있다. 이러한 방식으로, 타겟 가상 프로세서는 트랩 인 후에 인터럽트 요청을 처리할 수 있다. 이것은 가상 프로세서의 트랩-인 및 트랩-아웃에 의해 야기되는 지연을 회피하고, 인터럽트 요청의 처리 효율을 향상시킨다.

제1 양태 또는 제1 양태의 전술한 구현들 중 어느 하나를 참조하면, 제7 구현에서, 인터럽트 요청을 수신하는 가상 프로세서가 인터럽트 요청의 처리 엔티티가 아닌 경우를 최대한 회피하여, 인터럽트 처리 지연을 추가로 감소시키기 위해, 인터럽트 제어기의 인터럽트 친화성이 수정될 필요가 있다. 인터럽트 친화성은 인터럽트 제어기의 속성이다. 인터럽트 친화성은 인터럽트 요청의 식별자와 물리적 프로세서(또는 본 출원에서 프로세서로 지칭됨)의 식별자 사이의 대응관계를 포함한다. 인터럽트 제어기는, 다른 하드웨어에 의해 생성된 인터럽트 요청을 수신하고 인터럽트 친화성에 기초하여 인터럽트 요청을 대응하는 물리적 프로세서에 전송하도록 구성되는 하드웨어의 일부이다. 대응하여, 호스트는 인터럽트 제어기의 인터럽트 친화성을 구성하여, 인터럽트 요청이 인터럽트 요청의 처리 엔티티에 포함된 가상 프로세서에 전송될 수 있게 하도록 추가로 구성된다. 가상 프로세서가 물리적 프로세서 상에서 실행되기 때문에, 인터럽트 요청이 올바른 가상 프로세서에 전송되는 것을 보장하는 것은 실제로 인터럽트 요청이 올바른 가상 프로세서를 실행하는 물리적 프로세서에 전송되는 것을 보장한다.

제1 양태의 제7 구현을 참조하면, 제8 구현에서, 가상 프로세서가 스왑 인한 후에 그리고 가상 프로세서가 트랩 인하기 전에, 호스트는, 인터럽트 친화성에서, 스왑-인된 가상 프로세서를 실행할 물리적 프로세서와 처리 엔티티가 스왑-인된 가상 프로세서를 포함하는 모든 인터럽트 요청들 사이의 대응관계를 확립한다. 이어서, 가상 프로세서가 트랩 인되고 실행된다.

이러한 방식으로, 인터럽트 제어기는, 수정된 인터럽트 친화성에 기초하여, 가상 프로세서를 실행하는 물리적 프로세서에 인터럽트 요청을 전송할 수 있고, 즉, 가상 프로세서에 인터럽트 요청을 전송할 수 있다. 인터럽트 요청의 처리 엔티티가 가상 프로세서를 포함하고, 가상 프로세서는 인터럽트 요청을 직접 처리할 수 있다. 이것은 가상 프로세서들 사이의 인터럽트 요청의 분배를 효과적으로 회피한다.

대응하여, 가상 프로세서를 스왑 아웃하기 전에, (실행 엔티티 테이블을 업데이트하는 것 외에) 호스트는 스왑-아웃될 가상 프로세서와 처리 엔티티가 가상 프로세서를 포함하는 모든 인터럽트 요청들 사이의 대응관계를 인터럽트 친화성으로부터 삭제한다.

인터럽트 제어기의 인터럽트 친화성이 구성된 후에, 인터럽트 요청은 현재 서비스 가능하고 인터럽트 요청을 처리할 수 있는 가상 프로세서에 전송될 가능성이 크다. 이것은 가상 프로세서들 사이의 인터럽트 요청의 분배를 크게 회피하고, 인터럽트 요청의 처리 효율을 추가로 향상시킨다.

제1 양태의 제7 또는 제8 구현을 참조하면, 제9 구현에서, 인터럽트 친화성이 구성되더라도, 가상 프로세서는 가상 프로세서가 처리할 수 없는 인터럽트 요청을 여전히 수신할 수 있다. 이 경우, 인터럽트 친화성이 구성되기 때문에, 인터럽트 요청의 처리 엔티티에 포함된 가상 프로세서들 중 어느 것도 서비스 가능이 아니라고 결정될 수 있고, 따라서 인터럽트 요청의 처리 엔티티가 서비스 가능인지가 결정될 필요가 없다. 다른 구현에 대해서는, 전술한 제2, 제3, 제4, 제5, 또는 제6 구현을 참조한다. 대응하는 효과에 대해서는, 전술한 구현들을 또한 참조한다. 예를 들어, 처리될 인터럽트 요청의 타겟 가상 프로세서(모든 처리 엔티티들을 포함할 수 있음)가 인터럽트 요청의 처리 엔티티로부터 결정된다. 그 후, 타겟 가상 프로세서에 대해 인터럽트 요청의 식별자만이 기록된다. 대안적으로, 타겟 가상 프로세서가 인터럽트 요청의 우선순위에 기초하여 적절히 선택될 수 있다. 또한, 타겟 가상 프로세서의 스왑-인이 능동적으로 트리거될 수 있어서, 인터럽트 요청이 가능한 한 빨리 처리된다.

제1 양태 또는 제1 양태의 전술한 구현들 중 어느 하나를 참조하면, 일부 구현들에서, 가상 컴퓨터는: 수신된 인터럽트 요청의 처리 엔티티가 호스트일 때, 수신된 인터럽트 요청을 호스트에 주입(inject)하도록 추가로 구성되고; 호스트는 가상 컴퓨터에 의해 주입된 인터럽트 요청을 수신하고 처리하도록 추가로 구성된다.

제1 양태 또는 제1 양태의 전술한 구현들 중 어느 하나를 참조하면, 일부 구현들에서, 가상 컴퓨터는 인터럽트 벡터 테이블 및 수신된 인터럽트 요청의 식별자에 기초하여 인터럽트 요청의 처리 엔티티 및 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 결정하도록 구체적으로 구성된다. 인터럽트 벡터 테이블은 인터럽트 요청의 식별자, 인터럽트 요청의 처리 엔티티, 및 인터럽트 요청의 인터럽트 서비스 루틴 사이의 대응관계를 포함한다. 인터럽트 벡터 테이블은 가상 컴퓨터와 호스트 둘 다에 액세스가능한 저장 영역에 저장된다. 호스트는 인터럽트 요청의 식별자, 인터럽트 요청의 처리 엔티티, 및 인터럽트 요청의 인터럽트 서비스 루틴 사이의 대응관계를 추가하기 위해 인터럽트 벡터 테이블을 수정하도록(가상 컴퓨터에 의해 트리거됨) 추가로 구성된다.

크로스-계층 공유된 인터럽트 벡터 테이블(구체적으로, 인터럽트 벡터 테이블이 가상 프로세서 및 호스트에 의해 공유될 수 있음)은 인터럽트 요청, 인터럽트 요청의 처리 엔티티, 및 인터럽트 서비스 루틴 사이의 대응 관계와 같은 정보를 저장하여, 가상 프로세서가 정보를 사용하여 인터럽트 요청을 처리할 필요가 있을 때 가상 프로세서가 트랩 아웃 없이 저장 영역에 직접 액세스할 수 있게 한다. 이것은 트랩-아웃에 의해 야기되는 인터럽트 지연을 회피한다. 이러한 방식으로 정보를 저장하는 것은 저장 공간을 절약할 수 있고, 추가로, 호스트는 정보를 수정할 수 있다. 이 설계는 더욱 적절하고 안전하다.

제2 양태에 따르면, 본 출원은 인터럽트 요청 처리 방법을 제공한다. 그 방법은 가상화된 디바이스에 적용된다. 가상화된 디바이스는 프로세서 및 2개의 실행 모드: 호스트 모드와 게스트 모드를 포함한다.

프로세서는 호스트 모드에서 레지스터를 구성하여, 프로세서가 게스트 모드에서 실행되는 가상 프로세서를 실행할 때 가상화된 디바이스의 다른 하드웨어로부터 인터럽트 요청을 수신할 수 있다.

프로세서는 게스트 모드에서 다음의 동작들: 프로세서에 의해, 다른 하드웨어로부터 인터럽트 요청을 수신하는 동작; 프로세서에 의해, 인터럽트 요청에 기초하여 수신된 인터럽트 요청의 처리 엔티티를 결정하는 동작; 및 수신된 인터럽트 요청의 처리 엔티티가 프로세서 상에서 현재 실행되는 가상 프로세서를 포함할 때, 프로세서에 의해, 인터럽트 요청에 기초하여, 수신된 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 결정하고 인터럽트 서비스 루틴을 호출하여 인터럽트 요청을 처리하는 동작을 수행한다. 구체적으로, 수신된 인터럽트 요청은 인터럽트 요청의 식별자, 예를 들어, IRQ ID를 운반할 수 있다. 처리 엔티티 및 인터럽트 서비스 루틴은 후속하여 식별자에 기초하여 결정된다.

또한, 가상 컴퓨터가 일부 정보 및 인터럽트 요청에 기초하여 인터럽트 서비스 루틴 및 인터럽트 요청의 처리 엔티티를 결정한다. 정보는 인터럽트 요청(의 식별자), 처리 엔티티, 및 인터럽트 서비스 루틴 사이의 대응관계를 포함한다.

본 명세서에서 "프로세서"는 물리적 코어와 같은 가장 작은 물리적 처리 유닛으로서 이해될 수 있다.

제2 양태를 참조하면, 제1 구현에서, 프로세서는, 호스트 모드에서, 가상화된 디바이스의 물리적 인터럽트 제어기를 동작시킬 수 있도록 프로세서 상에서 실행될 가상 프로세서를 구성한다.

프로세서는 게스트 모드에서 다음의 동작: 수신된 인터럽트 요청의 처리 엔티티가 프로세서 상에서 현재 실행되는 가상 프로세서를 포함하지 않는 다른 가상 프로세서이고 다른 가상 프로세서 중 적어도 하나가 서비스 가능이라고 결정될 때, IPI 인터럽트 요청을 다른 가상 프로세서의 하나 이상의 서비스 가능 가상 프로세서에 전송하도록 물리적 인터럽트 제어기를 동작시키는 동작을 추가로 수행하고, IPI 인터럽트 요청은 수신된 인터럽트 요청의 식별자를 운반한다.

제2 양태를 참조하면, 제2 구현에서, 프로세서는, 인터럽트 요청이 인터럽트 요청의 처리 엔티티에 포함된 가상 프로세서에 전송될 수 있도록, 호스트 모드에서 가상화된 디바이스의 인터럽트 제어기의 인터럽트 친화성을 구성하고, 인터럽트 친화성은 인터럽트 요청의 식별자와 프로세서의 식별자 사이의 대응관계를 포함한다. 대응하여, 프로세서는 인터럽트 친화성에 기초하여 인터럽트 제어기에 의해 프로세서에 전송되는 인터럽트 요청을 수신한다.

제2 양태의 제2 구현을 참조하면, 제3 구현에서, 호스트 모드에서 가상 프로세서를 스왑 인한 후에, 프로세서는, 인터럽트 친화성에서, 처리 엔티티가 스왑-인된 가상 프로세서를 포함하는 모든 인터럽트 요청들과 프로세서 사이의 대응관계를 확립한다. 대응하여, 호스트 모드에서 가상 프로세서를 스왑 아웃하기 전에, 프로세서는, 인터럽트 친화성으로부터, 처리 엔티티가 가상 프로세서를 포함하는 모든 인터럽트 요청들과 스왑-아웃될 가상 프로세서 사이의 대응관계를 삭제한다.

제2 양태의 제2 또는 제3 구현을 참조하면, 제4 구현에서, 수신된 인터럽트 요청의 처리 엔티티가 프로세서 상에서 현재 실행되는 가상 프로세서를 포함하지 않는 다른 가상 프로세서일 때, 프로세서는 게스트 모드에서 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하고, 인터럽트 요청의 식별자를 게스트 모드와 호스트 모드 둘 다에서 프로세서에 액세스가능한 저장 영역에 기록한다. 타겟 가상 프로세서가 스왑 인된 후에, 프로세서는, 호스트 모드에서, 저장 영역에 기록된 식별자에 기초하여 타겟 가상 프로세서에 인터럽트 요청을 전송하여, 타겟 가상 프로세서가 트랩 인 후에 인터럽트 요청을 처리하게 한다.

구체적으로, 타겟 가상 프로세서가 스왑 인된 후에 그리고 타겟 가상 프로세서가 트랩 인하기 전에, 프로세서는 호스트 모드에서 호스트 모드의 인터럽트 응답을 디스에이블한 다음, 저장 영역에 기록된 식별자에 기초하여 프로세서에 동일한 특성을 갖는 인터럽트 요청을 전송한다(타겟 가상 프로세서가 현재 스케줄링되어 있는 프로세서가 프로세서 자체이기 때문). 타겟 가상 프로세서가 트랩 인한 후에(다시 말해서, 프로세서가 게스트 모드에 있은 후에), 타겟 가상 프로세서는 인터럽트 요청을 수신하고 처리할 수 있다.

제2 양태의 제4 구현을 참조하면, 제5 구현에서, 프로세서는 호스트 모드에서 인터럽트 요청의 우선순위를 설정하고, 우선순위를 호스트 모드와 게스트 모드 둘 다에서 프로세서에 액세스가능한 저장 영역에 기록하고; 프로세서는, 게스트 모드에서, 수신된 인터럽트 요청의 우선순위 및 가상 프로세서의 우선순위에 기초하여 타겟 가상 프로세서를 결정하고, 가상 프로세서의 우선순위는 모든 가상 프로세서들에 액세스가능한 저장 영역에 저장된다.

제2 양태의 제4 구현을 참조하면, 제6 구현에서, 수신된 인터럽트 요청의 처리 엔티티가 프로세서 상에서 현재 실행되는 가상 프로세서를 포함하지 않는 다른 가상 프로세서일 때, 방법은: 프로세서에 의해, 게스트 모드에서 (호스트 또는 호스트 모드로) 타겟 가상 프로세서의 식별자를 역방향으로 주입하는 단계; 다음으로, 프로세서에 의해, 게스트 모드를 퇴장하고 호스트 모드에 진입하는 단계 - 타겟 가상 프로세서는 다른 가상 프로세서 또는 다른 가상 프로세서에서 가장 높은 우선순위를 갖는 가상 프로세서 중 어느 하나임 - ; 및 호스트 모드에서 프로세서에 의해, 타겟 가상 프로세서의 식별자에 기초하여 타겟 가상 프로세서를 스왑 인하고, 프로세서 상에서 현재의 가상 프로세서를 스왑 아웃하는 단계를 추가로 포함한다.

제2 양태에서 제공되는 방법은 가상화된 디바이스에 적용된다. 가상화된 디바이스는 하드웨어 계층, 하드웨어 계층에서 실행되는 호스트, 및 호스트 상에서 실행되는 가상 컴퓨터를 포함한다. 가상 컴퓨터는 가상 컴퓨터를 서빙하는 가상 프로세서를 포함한다. 하나의 가상 프로세서는 하나의 프로세서 상에서 실행될 수 있다. 프로세서가 게스트 모드에서 동작을 수행하는 것은 가상 프로세서가 (게스트 모드에서) 동작을 수행하는 것으로서 이해될 수 있고, 추가로, 가상 프로세서에 의해 서빙되는 가상 컴퓨터가 동작을 수행하는 것으로서 이해될 수 있다. 프로세서가 호스트 모드에서 동작을 수행하는 것은 호스트가 동작을 수행하는 것으로서 이해될 수 있다.

제2 양태의 더 많은 구현들에 대해서는, 전술한 제1 양태를 참조한다.

제3 양태에 따르면, 본 출원은 인터럽트 요청 처리 장치를 제공한다. 처리 장치는 가상화된 디바이스에 적용된다. 가상화된 디바이스는 하드웨어 계층, 호스트, 및 가상 컴퓨터를 포함한다. 처리 장치는 호스트 상에 배치된 호스트 인터럽트 관리 유닛 및 가상 컴퓨터 상에 배치된 게스트 인터럽트 관리 유닛을 포함한다.

호스트 인터럽트 관리 유닛은 가상 컴퓨터의 가상 프로세서가 하드웨어 계층으로부터 인터럽트 요청을 수신할 수 있게 구성시키도록 구성된다.

게스트 인터럽트 관리 유닛은, 하드웨어 계층으로부터, 인터럽트 요청의 식별자를 운반하는 인터럽트 요청을 수신하고; 식별자에 기초하여 수신된 인터럽트 요청의 처리 엔티티를 결정하도록 구성된다. 수신된 인터럽트 요청의 처리 엔티티가 가상 컴퓨터의 현재의 가상 프로세서를 포함할 때, 가상 컴퓨터는, 식별자에 기초하여, 수신된 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 결정하고, 인터럽트 서비스 루틴을 호출하여 인터럽트 요청을 처리한다.

더욱 구체적인 구현들에 대해서는, 전술한 제1 양태 또는 제2 양태를 참조한다.

제4 양태에 따르면, 본 출원은 가상화된 디바이스를 제공한다. 가상화된 디바이스는 프로세서 및 메모리를 포함한다. 메모리는 컴퓨터 판독가능 명령어를 저장하도록 구성된다. 프로세서는 컴퓨터 판독가능 명령어를 판독하고, 위에서 제공된 방법들 중 어느 하나의 방법을 구현하도록 구성된다.

제5 양태에 따르면, 본 출원은 컴퓨터 판독가능 명령어를 저장하도록 구성되는 컴퓨터 저장 매체를 제공한다. 컴퓨터 판독가능 명령어가 프로세서에 의해 판독될 때, 프로세서는 위에서 제공된 방법들 중 어느 하나의 방법을 구현할 수 있게 된다. 또한, 본 출원은 컴퓨터 프로그램 또는 컴퓨터 프로그램 제품을 추가로 제공한다. 컴퓨터 프로그램 또는 컴퓨터 프로그램 제품은 컴퓨터 판독가능 명령어를 포함한다. 컴퓨터 판독가능 명령어가 프로세서에 의해 판독될 때, 프로세서는 전술한 양태들에서 제공된 방법들 중 어느 하나의 방법을 구현할 수 있게 된다.

제6 양태에 따르면, 본 출원은 프로세서-간 인터럽트(IPI) 처리 방법을 제공한다. 방법은 전술한 양태들 또는 구현들 중 어느 하나에서 제공되는 방법 또는 장치에 적용될 수 있다.

호스트가 소스 가상 프로세서에 대한 인터럽트 제어기 동작 모드를 구성하여, 소스 가상 프로세서가, 트랩 아웃 없이, 인터럽트 제어기가 IPI 인터럽트 요청을 목적지 가상 프로세서를 실행하는 물리적 프로세서에 전송하도록 동작시킬 수 있다. 소스 가상 프로세서는, 정보에 기초하여, 목적지 가상 프로세서를 실행하는 물리적 프로세서를 결정하고, 여기서 정보는 소스 가상 프로세서에 액세스가능한 저장 영역에 기록되고, 정보는 목적지 가상 프로세서를 실행하는 물리적 프로세서를 표시하는 정보를 포함한다. 이어서, 소스 가상 프로세서는 인터럽트 제어기가 IPI 인터럽트 요청을 목적지 가상 프로세서를 실행하는 물리적 프로세서에 전송하도록 동작시킨다.

이러한 방식으로, 인터럽트 제어기 동작 모드의 구성을 통해 그리고 직접 액세스될 수 있는 정보를 사용하여, 소스 가상 프로세서는 트랩 아웃 없이 IPI 인터럽트 요청을 목적지 가상 프로세서에 전송할 수 있다.

제6 양태를 참조하면, 제1 구현에서, 소스 가상 프로세서는 IPI 인터럽트 요청을 목적지 가상 프로세서에 전송하고, 여기서 IPI 인터럽트 요청은 다른 인터럽트 요청의 식별자를 운반하거나, IPI 인터럽트 요청은 다른 인터럽트 요청의 식별자 및 가상 프로세서의 식별자를 운반한다. 목적지 가상 프로세서가 IPI 인터럽트 요청이 가상 프로세서의 식별자를 운반하지 않는다고 결정하거나, IPI 인터럽트 요청에서 운반되는 가상 프로세서의 식별자가 목적지 가상 프로세서의 식별자와 일치한다고 결정하는 경우, 목적지 가상 프로세서는 다른 인터럽트 요청의 식별자에 대응하는 인터럽트 서비스 루틴을 호출하여 다른 인터럽트 요청을 처리한다.

이러한 방식으로, 공통 인터럽트 요청은 가상 프로세서들 사이에 IPI 인터럽트 요청을 전송함으로써 가상 프로세서들 사이에 분배될 수 있다. 이러한 가상 프로세서들은 동일한 가상 컴퓨터에 있을 수 있거나, 상이한 가상 컴퓨터들에 있을 수 있다.

제6 양태 또는 제6 양태의 제1 구현을 참조하면, 제2 구현에서, IPI 인터럽트 요청이 가상 프로세서의 식별자를 운반할 때(다른 인터럽트 요청의 식별자를 운반하지 않을 수 있음), 방법은: 목적지 가상 프로세서가 IPI 인터럽트 요청에서 운반되는 가상 프로세서의 식별자가 목적지 가상 프로세서의 식별자와 불일치한다고 결정하는 경우, 목적지 가상 프로세서에 의해, 가상 프로세서의 식별자를 호스트에 전송하고, 트랩 아웃하여, 호스트가 가상 프로세서의 식별자에 의해 표시된 가상 프로세서를 스왑 인하게 하는 단계를 추가로 포함한다.

이러한 방식으로, 호스트는 가상 프로세서들 사이에 IPI 인터럽트 요청을 전송함으로써 타겟 가상 프로세서를 스왑 인할 수 있어, 타겟 가상 프로세서가 가능한 한 빨리 IPI 인터럽트 요청에서 운반된 인터럽트 요청을 처리하게 할 수 있다.

제6 양태 또는 제6 양태의 구현들 중 어느 하나를 참조하면, 제3 구현에서, 소스 가상 프로세서는 목적지 가상 프로세서가 서비스 가능이라고 결정할 때에만 IPI 인터럽트 요청을 전송한다. 구체적으로, 소스 가상 프로세서는 목적지 가상 프로세서가 서비스 가능인지를 결정하기 위해 정보에 대해 질의한다. 이 정보는 목적지 가상 프로세서가 서비스 가능인지를 표시하는 정보를 추가로 포함한다. 구체적으로, 정보는 가상 프로세서와 호스트 둘 다에 액세스가능한 저장 영역에 기록될 수 있다. 호스트는 가상 프로세서를 스왑 인 또는 스왑 아웃할 때 정보를 수정하도록 구성된다.

제7 양태에 따르면, 본 출원은 제6 양태에 대응하고 제6 양태 또는 제6 양태의 구현들 중 어느 하나에서 제공되는 방법을 구현하기 위한 하나 이상의 모듈을 포함하는 IPI 인터럽트 처리 장치를 추가로 제공한다. 또한, 본 출원은 가상화된 디바이스를 추가로 제공한다. 가상화된 디바이스 내의 가상 프로세서는 제6 양태 또는 제6 양태의 구현들 중 어느 하나에서 설명된 방법을 구현하도록 구성된다. 또한, 본 출원은 컴퓨터 저장 매체, 컴퓨터 프로그램, 및 컴퓨터 프로그램 제품을 추가로 제공한다. 상세사항들에 대해서는, 전술한 양태들을 참조한다.

제8 양태에 따르면, 본 출원은, 클록 인터럽트와 같은, 복수의 가상 프로세서에 의해 처리될 필요가 있는 인터럽트 요청을 처리하는데 사용되는 인터럽트 처리 방법을 추가로 제공한다. 방법은: 호스트에 의해, 각각의 물리적 프로세서에 대한 대응하는 정보를 생성하는 단계 - 정보는 물리적 프로세서 상에서 이전에 실행된 가상 프로세서에 관한 정보를 포함함 - ; 및 가상 프로세서에 의해, 인터럽트 요청을 수신하고, 인터럽트 요청이 복수의 가상 프로세서에 의해 처리될 필요가 있다고 결정하고, 그 다음에 정보 세트 내의 가상 프로세서가 인터럽트 요청의 처리 엔티티에 포함된다고 결정하고, 이어서 호스트와 가상 프로세서 둘 다에 의해 액세스될 수 있는 영역에서 가상 프로세서에 대응하는 위치에 인터럽트 요청을 기록하여, 가상 프로세서의 스왑-인이 트리거되고, 가상 프로세서가 가능한 한 빨리 인터럽트 요청을 처리할 수 있게 하는 단계를 포함한다. 더 많은 처리 방법들에 대해서는, 전술한 양태들 및 그의 실시예들을 참조한다. 또한, 본 출원은 이 양태에 대응하는 장치 및 판독가능 저장 매체를 추가로 제공한다. 이 방법에 따르면, 클록 인터럽트와 유사한 인터럽트 요청의 지연이 또한 효과적으로 감소된다.

제9 양태에 따르면, 본 출원은 인터럽트 처리 방법을 추가로 제공한다. 호스트가 애플리케이션 인터럽트 요청을 수신하고; 정보에 액세스함으로써, 인터럽트 요청을 처리할 수 있는 가상 프로세서가 서비스 가능인지를 결정하고; 인터럽트 요청을 처리할 수 있는 임의의 가상 프로세서가 서비스 가능인 경우, IPI 인터럽트를 사용하여 인터럽트 요청을 서비스 가능 가상 프로세서에 전송하거나; 또는 인터럽트 요청을 처리할 수 있는 가상 프로세서가 서비스 가능이 아닌 경우, 호스트와 가상 프로세서 둘 다에 의해 액세스될 수 있는 영역에 인터럽트 요청을 기록한다. 스왑-인을 능동적으로 트리거할지 및 어떻게 스왑-인을 수행할지에 관한 정보에 대해서는, 전술한 양태들 및 그의 구체적인 실시예들을 참조한다. 또한, 본 출원은 이 양태에 대응하는 장치 및 판독가능 저장 매체를 추가로 제공한다. 이 방법에 따르면, 본 출원은 호스트가 인터럽트 응답을 디스에이블할 수 없는 시나리오에 적용될 수 있고, 적용 범위는 더 넓다.

본 발명의 실시예들에서의 또는 종래기술에서의 기술적 해결책들을 더욱 명확하게 설명하기 위해, 이하에서는 실시예들 또는 종래기술을 설명하기 위해 요구되는 첨부 도면들을 간단히 설명한다. 명백히, 다음의 설명에서의 첨부 도면들은 본 발명의 일부 실시예들을 도시하는 것일 뿐이고, 본 기술분야의 통상의 기술자는 창의적인 노력들 없이도 이러한 첨부 도면들로부터 다른 도면들을 여전히 도출할 수 있다.
도 1은 본 발명의 실시예에 적용되는 네트워크 아키텍처의 개략도이다.
도 2는 본 발명의 실시예에 따른 가상화된 네트워크 디바이스의 하드웨어 구조의 개략도이다.
도 3a는 본 발명의 실시예에 따른 가상화된 네트워크 디바이스의 개략적인 구성도이다.
도 3b는 본 발명의 실시예에 따른 다른 가상화된 네트워크 디바이스의 개략적인 구성도이다.
도 4는 본 발명의 실시예에 따른 인터럽트 처리 방법의 개략적인 흐름도이다.
도 5는 본 발명의 실시예에 따른 가상화된 네트워크 디바이스의 기능 유닛들 및 모듈들의 제1 개략도이다.
도 6은 본 발명의 실시예에 따른 호스트 인터럽트 관리 유닛을 초기화하는 개략적인 흐름도이다.
도 7은 본 발명의 실시예에 따른 게스트 인터럽트 관리 유닛을 초기화하는 개략적인 흐름도이다.
도 8a 및 도 8b는 본 발명의 실시예에 따른 인터럽트 처리 방법의 개략적인 흐름도들이다.
도 9a 및 도 9b는 본 발명의 실시예에 따른 인터럽트 친화성을 구성하는 개략적인 흐름도들이다.
도 10은 본 발명의 실시예에 따른 가상화된 네트워크 디바이스의 기능 유닛들 및 모듈들의 제2 개략도이다.
도 11은 본 발명의 실시예에 따른 인터럽트 복제 처리 방법의 개략적인 흐름도이다.
도 12는 본 발명의 실시예에 따른 가상화된 네트워크 디바이스의 기능 유닛들 및 모듈들의 제3 개략도이다.

본 발명의 실시예들을 쉽게 이해하기 위해, 본 발명의 실시예들의 설명들에서 사용되는 일부 요소들이 먼저 본 명세서에서 설명된다.

가상 컴퓨터는 모든 타입들의 가상화된 디바이스들에서 소프트웨어-가상화된 런타임 환경들에 대한 일반적인 용어이다. 이 개념은 가상 머신, 컨테이너, 경량 가상 libOS 등을 포함한다.

가상 머신(virtual machine, VM)은 소프트웨어를 사용하여 하나의 물리적 컴퓨터 상에 시뮬레이션된 하나 이상의 가상 컴퓨터이다. 가상 머신은 완전히 격리된 환경에서 실행되고, 실제 컴퓨터처럼 작동한다. 게스트 운영 체제(guest operating system, guest OS)가 가상 머신 상에 설치될 수 있다. 게스트 운영 체제는 하나 이상의 애플리케이션을 실행한다. 가상 머신은 또한 네트워크 자원에 액세스할 수 있다. 가상 머신 상에서 실행되는 애플리케이션은, 애플리케이션이 실제 컴퓨터에서 작동하는 것처럼 작동한다.

호스트(host) 계층은 관리 계층으로서 사용되고, 하드웨어 자원을 관리 및 할당하고, 가상 머신에 대한 가상 하드웨어 플랫폼을 제시하고, 가상 머신을 스케줄링 및 격리하고, 그와 유사한 것을 하는 데 사용된다. 일부 구현들에서, 호스트 계층은 호스트 운영 체제 및 가상 모니터링 장치, 예컨대, 가상 머신 모니터(virtual machine monitor, VMM) 또는 하이퍼바이저를 포함한다. 가상 모니터링 장치는 호스트 운영 체제 내에 배치될 수 있거나, 호스트 운영 체제 외부에 배치될 수 있다. 일부 다른 구현들에서, "호스트 계층"은 하나의 특권 가상 머신(예컨대, 가상 아키텍처 Xen)을 추가로 포함할 수 있다. 가상 하드웨어 플랫폼은 가상 프로세서, 가상 메모리, 가상 디스크, 및 가상 네트워크 인터페이스 카드와 같은 다양한 하드웨어 자원들을 갖는 가상 하드웨어 플랫폼 상에서 실행되는 가상 컴퓨터들을 제공한다. 가상 컴퓨터들은 가상 컴퓨터들을 위해 호스트 계층에 의해 준비된 가상 하드웨어 플랫폼 상에서 실행된다. 본 출원에서, 호스트 계층은 때때로 호스트라고 지칭된다.

하드웨어 계층은 가상 환경이 실행되는 하드웨어 플랫폼이다. 하드웨어 계층은 복수의 타입의 하드웨어를 포함할 수 있다. 예를 들어, 물리적 컴퓨터의 하드웨어 계층은 프로세서 및 메모리를 포함할 수 있고, 인터럽트 제어기, 네트워크 인터페이스 카드(network interface card, NIC), 입력/출력(input/output, I/O) 디바이스 등을 추가로 포함할 수 있다.

인터럽트 요청(interrupt request) 및 인터럽트 번호: 인터럽트 요청은 하드웨어에 의해 생성된 이벤트이다. 하드웨어는 이벤트를 프로세서에 전송한다. 이벤트를 수신할 때, 프로세서는 현재 루틴을 중단하고 이벤트에 대응하는 루틴을 실행한다. 하드웨어가 인터럽트 요청을 생성하는 것은 하드웨어에 의해 트리거될 수 있거나, 소프트웨어에 의해 트리거될 수 있다. 인터럽트 요청은 때때로 인터럽트로 지칭된다. 컴퓨터 내의 일부 하드웨어(예컨대, 네트워크 인터페이스 카드, 오디오 카드, 마우스, 및 하드 디스크)는 프로세서의 개입 없이 특정 작업을 완료할 수 있다. 그러나, 하드웨어는 여전히 프로세서를 주기적으로 인터럽트하고, 프로세서가 하드웨어에 대한 일부 특정 작업을 수행할 것을 요구할 필요가 있다. 인터럽트 번호는 인터럽트 요청의 식별자이고, 본 출원에서 IRQ ID에 의해 표현된다.

인터럽트 제어기는 인터럽트 요청을 트리거하는 하드웨어와 프로세서 사이에 배치되고, 주로 다양한 하드웨어에 의해 생성된 인터럽트 요청들을 수집하고, 특정 우선순위에 기초하여 또는 다른 규칙에 따라 인터럽트 요청들을 프로세서에 전송하도록 구성된다. 예를 들어, 인터럽트 제어기는 진보된 프로그램가능 인터럽트 제어기(advanced programmable interrupt controller, APIC)이다. 본 출원에서, 인터럽트 제어기는 일반적인 용어이고, 상이한 기능 컴포넌트들을 포함할 수 있다. 예를 들어, X86 시스템 내의 인터럽트 제어기는 하나의 io-APIC 및 복수의 local-APIC를 포함하고, 여러 다른 인터럽트 제어 컴포넌트를 추가로 포함할 수 있다. 하나의 local-APIC는 하나의 물리적 코어에 대응한다.

인터럽트 친화성은 인터럽트 요청과, 인터럽트 요청을 처리하는 처리 엔티티(보통 물리적 코어와 같은 물리적 처리 엔티티) 사이의 대응관계이다. 인터럽트 제어기는 인터럽트 친화성에 기초하여 인터럽트 요청에 대응하는 하나 이상의 물리적 처리 엔티티에 인터럽트 요청을 전송할 수 있다.

인터럽트 서비스 루틴(interrupt service routine, ISR)은 인터럽트 요청을 처리하는 데 사용되는 루틴이다. 인터럽트 요청을 수신할 때, 프로세서는 현재 루틴을 실행하는 것을 중단하고 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 실행한다.

애플리케이션 인터럽트 요청: 애플리케이션은 가상 머신 상에 배치된 애플리케이션(또는 서비스 소프트웨어)이다. 가상 머신 상의 애플리케이션은 애플리케이션의 인터럽트 서비스 루틴을 애플리케이션이 실행되는 게스트 운영 체제에 배치한다. 인터럽트 요청의 인터럽트 서비스 루틴이 게스트 운영 체제에 있고 애플리케이션에 의해 배치되는 경우(즉, 인터럽트 서비스 루틴이 애플리케이션에 의해 처리될 필요가 있는 경우), 인터럽트 요청은 애플리케이션 인터럽트 요청으로 지칭된다. 대부분의 가상화된 네트워크 디바이스들에서, 가상 머신 상에 배치된 애플리케이션은 다양한 실제 서비스 요건들을 이행하기 위해 일반적으로 사용된다. 따라서, 애플리케이션 인터럽트 요청은 때때로 서비스 인터럽트 요청으로 지칭될 수 있다.

게스트 운영 체제 인터럽트 요청: 이러한 인터럽트 요청에 대응하는 인터럽트 서비스 루틴은 가상 머신의 게스트 운영 체제에 의해 제공되고, 가상 머신 상의 애플리케이션에 의해 배치되지 않는다. 애플리케이션 인터럽트 요청과 같이, 그러한 인터럽트 요청의 인터럽트 서비스 루틴도 가상 머신의 게스트 운영 체제에 배치된다.

libOS(library operating system)는 경량 가상화 기술(light-weight virtualization technology)에 의해 제공되는 운영 체제이다. libOS는 런타임 라이브러리이고, 운영 체제의 기능과 유사한 기능을 제공하고 애플리케이션 링크와 함께 실행되어, 애플리케이션의 실행을 위해 요구되는 모든 자원들이 운영 체제 대신에 애플리케이션에 의해 관리되게 할 수 있다. 예를 들어, libOS는 unikernel, OSv, 또는 dune일 수 있다. libOS는 경량 가상 컴퓨터로서 고려될 수 있다.

물리적 프로세서는 때때로 "프로세서"로 지칭된다. 본 출원에서, 물리적 프로세서는 물리적 처리 유닛이고, 구체적으로는, 가장 작은 처리 유닛, 즉, 본 출원에서의 물리적 코어일 수 있다. 일부 실시예들에서, 물리적 프로세서는 대안적으로 복수의 물리적 코어를 포함하는 처리 유닛일 수 있다.

가상 프로세서는, 가상 CPU(virtual central processing unit, vCPU)와 같은, 가상 컴퓨터가 사용하기 위한 가상화 기술에서의 공유 또는 단편화된 방식으로 제공되는 물리적 처리 유닛을 나타낸다. 하나의 가상 컴퓨터는 하나 이상의 가상 프로세서에 의해 서빙될 수 있다. 복수의 가상 프로세서가 있을 때, 보통, 하나의 가상 프로세서는 주요 가상 프로세서이고, 다른 가상 프로세서들은 보조 가상 프로세서들이다.

가상 컴퓨터는 독립적인 컴퓨터와 동등하고, 가상 컴퓨터가 동작을 수행한다는 것은, 가상 프로세서가 동작을 수행한다는 것으로 간주될 수도 있다는 것을 이해해야 한다. 또한, 가상 프로세서는 소프트웨어에 의해 구현된다. 따라서, 가상 프로세서가 동작을 수행한다는 것은, 실제로 물리적 프로세서 또는 가상 프로세서를 실행하는 물리적 코어가 동작을 수행한다는 것이다. 본 발명의 복수의 실시예에서, 전술한 표현 방식들은 현재 시나리오에서의 기술적 표현 습관들을 따르기 위해 선택적으로 사용될 수 있다.

가상 프로세서의 트랩-인 및 가상 프로세서의 트랩-아웃: 가상 시스템은 2가지 모드: 호스트 모드(host mode) 및 게스트 모드(guest mode)를 포함한다. 가상 프로세서가 게스트 모드에 진입할 때, 이것은 트랩-인(가상)이라고 불리고; 가상 프로세서가 게스트 모드를 퇴장할 때, 이것은 트랩-아웃(가상)이라고 불린다. 가상 프로세서가 트랩 아웃한 후에, 물리적 프로세서는 가상 프로세서의 코드를 실행하는 것을 일시적으로 중지한다. 따라서, 이 경우는 가상 프로세서가 실행되지 않는 것으로 이해될 수 있다. 본 출원의 대부분의 실시예들에서는, 예로서 vCPU와 같은 가상 프로세서를 사용하여 방법 또는 장치가 설명된다. 따라서, 이러한 실시예들에서, 가상 프로세서의 트랩-인 또는 트랩-아웃은 구체적으로 vCPU의 트랩-인 또는 트랩-아웃이다. 물리적 프로세서의 경우, 물리적 프로세서 상에서 실행되는 가상 프로세서가 트랩 인할 때, 물리적 프로세서가 게스트 모드에 있고 가상 프로세서의 코드가 실행되는 것으로 간주될 수 있거나; 또는 물리적 프로세서 상에서 실행되는 가상 프로세서가 호스트 모드로 트랩 아웃할 때, 물리적 프로세서가 호스트 모드에 있고, VMM과 같은 호스트-관련 코드를 실행하는 것으로 간주될 수 있다.

가상 프로세서의 서비스 가능 또는 서비스 불능: 가상 프로세서가 트랩 인한 후에 획득되는 상태가 서비스 가능으로 지칭되고, 가상 프로세서가 트랩 인하기 전에 획득되는 상태가 서비스 불능으로 지칭된다. 가상 프로세서가 서비스 가능이라는 것은 가상 프로세서가 실행중이라는 것, 즉, 가상 프로세서의 코드가 물리적 프로세서에 의해 실행된다는 것으로 이해될 수 있다. 가상 프로세서가 서비스 불능이라는 것은 물리적 프로세서가 가상 프로세서의 코드를 실행하지 않는다는 것을 의미한다. 본 출원의 대부분의 실시예들에서는, 예로서 vCPU와 같은 가상 프로세서를 사용하여 방법 또는 장치가 설명된다. 따라서, 이러한 실시예들에서, 가상 프로세서의 서비스 가능 또는 서비스 불능은 구체적으로 vCPU의 서비스 가능 또는 서비스 불능이다.

IPI 프로세서-간 인터럽트는 프로세서들 사이의 인터럽트이고, 특수 인터럽트이고, 프로세서에 의해 다른 프로세서에 전송되는 인터럽트 요청이다. 예를 들어, IPI는 APIC의 인터럽트 커맨드 레지스터(interrupt command register, ICR)이다. ICR은 프로세서 상에서 실행되는 소프트웨어가 IPI 인터럽트를 다른 프로세서에 전송할 수 있게 한다. 일부 IPI들은 시스템 유지보수를 구현하기 위해 게스트 운영 체제에 의해 트리거되고, 게스트 운영 체제의 인터럽트 요청들로서 간주될 수 있다. 일부 IPI들은 서비스에 의해 트리거되고, 따라서 애플리케이션 인터럽트 요청들로서 간주될 수 있다. 본 출원에서, IPI 인터럽트는 상이한 시나리오들에서 상이한 파라미터들을 운반하고, 일부 실시예들에서 기술적 효과를 달성하기 위해 대응하는 인터럽트 서비스 루틴이 추가된다.

또한, 본 발명의 설명에서, "복수"는 달리 명시되지 않는 한 적어도 2를 의미한다. 본 출원에서, 용어 "및/또는" 또는 문자 "/"는 연관된 객체들 사이의 연관 관계만을 기술하고, 3가지 관계가 존재할 수 있다는 것을 나타낸다. 예를 들어, A 및/또는 B, 또는 A/B는 다음의 3가지 경우를 나타낼 수 있다: A가 단독으로 존재하는 경우, A와 B 둘 다가 존재하는 경우, 및 B가 단독으로 존재하는 경우.

이하에서는 본 발명의 실시예들에서의 첨부 도면들을 참조하여 본 발명의 실시예들에서의 기술적 해결책들을 명확하게 설명한다.

도 1은 예로서 네트워크 시스템의 실시예를 도시한다. 네트워크 시스템은 사용자 장비, 진화된 노드B(eNodeB)(100), 이동성 관리 엔티티(mobility management entity, MME), 및 서빙 게이트웨이와 같은 네트워크 디바이스들을 포함한다. 네트워크 시스템은 또한 5G 통신 표준을 따르는 네트워크 시스템일 수 있다. 사용자 장비는 모바일 폰, 데스크톱 컴퓨터, 노트북 컴퓨터, 차량-내 디바이스 등을 포함한다. 또한, 네트워크 시스템은 몇 가지만 예를 들면, 홈 가입자 서버 및 PDN 네트워크 게이트웨이와 같은 다른 네트워크 디바이스들을 추가로 포함할 수 있다.

도 2는 전술한 실시예에서의 eNodeB(100)의 하드웨어 구조의 개략도이고, 구체적으로는 진화된 NodeB의 서비스 처리 보드(service processing board)의 하드웨어 구조의 개략도로서 간주될 수 있다. eNodeB(100)는 프로세서(110), 메모리(120), 및 네트워크 인터페이스(130)(네트워크 인터페이스 카드 또는 네트워크 어댑터로도 지칭됨)와 같은 컴포넌트들을 포함한다. 프로세서(110)는 단일-코어 프로세서일 수 있거나, 멀티-코어 프로세서일 수 있다. 프로세서(110)가 멀티-코어 프로세서일 때, 본 출원에서 제공되는 방법은 하나의 코어 상에서 실행될 수 있거나, 분산된 방식으로 상이한 코어들 상에서 실행될 수 있다. 하나의 프로세서(110)가 있을 수 있거나, 복수의 프로세서(110)가 있을 수 있다. 복수의 프로세서는 동일한 타입 또는 상이한 타입들일 수 있다. 프로세서 타입들은 중앙 처리 유닛(central processing unit, CPU), 그래픽 처리 유닛, 마이크로프로세서, 코프로세서 등을 포함한다. 네트워크 인터페이스(130)는 무선 접속 및 유선 접속을 포함하는 다른 네트워크 디바이스들을 접속하도록 구성된다. 메모리(120)는 휘발성 메모리 및 비휘발성 메모리를 포함한다. 보통, 비휘발성 메모리는 가상화 소프트웨어 프로그램(122), 본 출원에서 제공되는 인터럽트 요청 처리 방법에서의 소프트웨어(121), 및 다른 프로그램 모듈(123)을 저장한다. 프로세서(110)에 의해 판독 및 실행된 후에, 가상화 소프트웨어 프로그램(122)은, 호스트 계층, 복수의 가상 컴퓨터 등을 생성하는 것을 포함하는, eNodeB(100)의 가상화를 구현한다. 프로세서(110)에 의해 판독 및 실행된 후에, 본 출원에서 제공되는 인터럽트 처리 소프트웨어 프로그램(121)은 본 출원의 실시예들에서 제공되는 다양한 인터럽트 요청 처리 방법들을 구현한다. 본 출원에서 제공되는 소프트웨어 프로그램(121)은 가상화 소프트웨어 프로그램(122)에 통합될 수 있다.

전술한 컴포넌트들은 버스(140)를 사용하여 접속된다. 버스(140)는 하나의 버스일 수 있거나, 복수의 버스일 수 있다. 버스(140)는 진보된 마이크로제어기 버스 아키텍처(advanced microcontroller bus architecture, AMBA) 산업 표준 아키텍처(industry standard architecture, ISA) 버스, 마이크로 채널 아키텍처(micro channel architecture, MCA) 버스, 확장된 ISA(extended-ISA) 버스, 비디오 전자 표준 협회(video electronics standard association, VESA) 로컬 영역 버스, 주변 컴포넌트 인터커넥트(peripheral component interconnect, PCI) 버스 등을 포함한다.

도 3a는 전술한 실시예에서 eNodeB(100)의 가상화 후의 구성의 개략도를 도시한다. 가상화된 디바이스(100)는 하드웨어 계층, 호스트 계층, 및 가상화 계층을 포함한다. 가상화 계층은 2개의 가상 머신을 포함한다. 하드웨어 계층은 2개의 프로세서(110), 메모리(120), 네트워크 인터페이스(130), 및 인터럽트 제어기(160)와 같은 하드웨어를 포함한다. 다른 실시예에서, 더 많거나 더 적은 프로세서들(110) 및 가상 머신들이 있을 수 있다.

일부 다른 실시예들에서, 가상 머신은 컨테이너(container)를 포함할 수 있다. 컨테이너는 애플리케이션과 동등하다. 일부 다른 실시예들에서, 도 3b를 참조하면, 가상화 계층은, libOS(190)와 같은, 경량 가상화 기술을 사용하여 구현된다. 하나의 libOS는 보통 하나의 애플리케이션을 포함한다. 전체 libOS는 하나 이상의 라이브러리이고, 단일-어드레스 공간 이미지를 획득하기 위해 애플리케이션에 링크된다. libOS(190)는 본 출원에서 제공되는 게스트 인터럽트 관리 유닛(191)을 포함한다. 종래의 가상화 기술을 사용하여 구현되는 가상 머신이 본 출원의 이 실시예에서 예로서 일반적으로 사용된다. 가상 머신을 참조하여 다른 타입들의 가상화 아키텍처들이 구현될 수 있다.

본 실시예에서는 eNodeB(110)가 예로서 사용되지만, 본 출원에서 제공되는 방법은 그 디바이스로 제한되지 않으며, 모든 타입들의 가상화된 디바이스들에 적용될 수 있다는 점에 유의해야 한다.

인터럽트 제어기(160)는 네트워크 인터페이스(130)와 같은 하드웨어 디바이스들에 의해 생성된 인터럽트 요청들을 수집하고, 특정 규칙에 따라 인터럽트 요청들을 프로세서들(110)에 전송하는 것을 담당한다. 프로세서(110)는 하나 이상의 물리적 코어(본 출원에서 물리적 코어는 때때로 코어로 지칭됨)를 포함할 수 있다.

"물리적 코어"는 본 출원에서 가장 작은 처리 유닛을 나타낸다. 도 3a 또는 도 3b에 도시된 바와 같이, 이 실시예에서의 각각의 프로세서는 2개의 물리적 코어, 즉, 코어 0과 코어 1, 및 복수의 레지스터를 갖는다. 일부 다른 실시예들에서, 프로세서는 더 많거나 더 적은 코어들을 포함할 수 있고, 상이한 프로세서들은 상이한 수량의 코어들을 포함할 수 있다.

호스트 운영 체제(170) 및 VMM(180)은 호스트 상에 배치된다. VMM(180)은 다른 가상화 아키텍처 내의 하이퍼바이저 또는 다른 타입의 가상 모니터링 장치와 동등하다. VMM(180)은 호스트 운영 체제(170)에 배치될 수 있거나, VMM(180) 및 호스트 운영 체제(170)는 개별적으로 배치될 수 있다. VMM(180)은 VMM(180) 상에서 실행되는 하나 이상의 가상 머신을 관리하는 것을 담당한다.

가상 머신(VM)은 가상 하드웨어 계층, 게스트 운영 체제(190), 및 복수의 애플리케이션을 포함한다. 가상 하드웨어 계층은 가상 메모리(도면에 도시되지 않음) 및 가상 프로세서(110-v)와 같은 가상 하드웨어를 포함한다. 도 3a 또는 도 3b에 도시된 바와 같이, 이 실시예는 2개의 가상 머신을 포함한다. 각각의 가상 머신은 3개의 가상 프로세서(110-v)를 포함한다. 가상 프로세서(110-v)는 소프트웨어와 하드웨어의 조합에 의해 구현된다. 가상 프로세서(110-v)의 실행은 실제로 소프트웨어 프로그램을 판독하고 실행하는 물리적 코어에 의해 구현된다. 예를 들어, 물리적 코어는 소프트웨어 프로그램을 판독하고, 물리적 코어의 특정 하드웨어-보조 가상화 모드(예를 들어, X86의 비-루트(non-Root) 모드)에서 소프트웨어 프로그램을 실행하여, 가상 프로세서(110-v)를 구현한다. 따라서, 가상 프로세서(110-v)는 물리적 코어 상에 스케줄링될 필요가 있다.

가상 프로세서(110-v)는 물리적 코어에 바인딩될 수 있는데, 즉, 가상 프로세서(110-v)는 항상 특정 물리적 코어 상에서 실행되고, 실행을 위해 다른 물리적 코어 상에 스케줄링될 수 없고, 가상 프로세서는 물리적 코어에 바인딩된다. 가상 프로세서(110-v)가 요건에 따라 실행을 위해 상이한 물리적 코어들 상에 스케줄링될 수 있는 경우, 가상 프로세서는 물리적 코어에 바인딩되지 않는다.

이 실시예에서, 가상 프로세서들(110-v)의 전체 수량은 6이고, 물리적 코어들의 수량 4보다 크다. 이 시나리오는 물리적 프로세서의 초과 할당(excessive allocation)으로 지칭된다. 물리적 프로세서의 초과 할당의 경우에, 복수의 가상 프로세서는 시간 단편화(time fragmentation)의 방식으로 또는 다른 방식으로 하나의 물리적 코어를 공유할 수 있다. 이 물리적 코어는 비-배타적 코어(non-exclusive core)라고 불린다. 분명히, 초과 할당이 없는 경우에 비-배타적 코어가 있을 수도 있다. 하나의 물리적 코어가 하나의 가상 프로세서에 바인딩되고 다른 가상 프로세서에 의해 공유되지 않는 경우, 물리적 코어는 배타적 코어이다.

가상 모니터링 장치로서, VMM(180)은 VM들의 가상 프로세서들(110-v)을 스케줄링하는 것을 담당한다. 예를 들어, 커널-기반 가상 머신(kernel-based virtual machine, KVM)은 전형적인 VMM이다. VMM(180)에 의해 가상 프로세서(110-v)를 스케줄링하는 것은 가상 프로세서를 스왑 인하는 것과 가상 프로세서를 스왑 아웃하는 것을 포함한다. 먼저, VMM(180)은 VM의 객체를 생성하고 초기화한 다음, VM에 대한 3개의 가상 프로세서(110-v)를 생성한다. VM이 복수의 가상 프로세서(110-v)를 포함할 때, 보통, 하나의 가상 프로세서는 주요 가상 프로세서이고, 다른 가상 프로세서들은 보조 가상 프로세서들이다. 가상 프로세서(110-v)가 초기에 생성될 때, 가상 프로세서(110-v)는 물리적 코어와 연관되지 않는다. VMM(180)이 정책에 따라 물리적 코어 상으로 가상 프로세서(110-v)를 스케줄링하는 것은 가상 프로세서를 스왑 인하는 것으로 지칭된다. VMM(180)이 가상 프로세서(110-v)를 중단하거나 가상 프로세서(110-v)를 물리적 코어로부터 마이그레이션하는 것은 가상 프로세서를 스왑 아웃하는 것으로 지칭된다. 가상 프로세서가 물리적 코어에 바인딩되는 경우, 가상 프로세서가 스왑 인될 때마다, 가상 프로세서는 동일한 코어 상으로 스케줄링된다. 가상 프로세서가 물리적 코어에 바인딩되지 않은 경우, 스케줄링 전에, VMM(180)은 시스템의 현재 실행 상태 및/또는 스케줄링 알고리즘에 기초하여 가상 프로세서(110-v)가 스케줄링될 코어를 결정할 수 있다.

스왑 인된 후에, 가상 프로세서(110-v)가 즉시 트랩 인 및 실행되지 않을 수 있다는 점에 유의해야 한다. 가상 프로세서(110-v)가 스왑 인된 후에 그리고 가상 프로세서(110-v)가 트랩 인하기 전에, 호스트(구체적으로 VMM임)는 가상 프로세서(110-v)에 대한 일부 구성들을 추가로 구현할 수 있고, 그 후 가상 프로세서(110-v)는 게스트 모드로 트랩 인한다.

도 3a 또는 도 3b의 구성에 기초하여, 기존의 인터럽트 요청 처리 해결책은 보통 "시스템 인터럽트 먼저" 규칙에 따라 설계되고, 하드웨어에 의해 생성된 모든 인터럽트 요청은 호스트 계층에 직접 전송된다. 따라서, 호스트 계층에서의 인터럽트 요청 처리 절차는 비교적 빠르다. 그러나, 이 해결책에서, 애플리케이션 인터럽트 요청은 호스트에 의해 식별된 다음 가상 머신에 전송될 필요가 있다. 따라서, 전체 처리 절차는 2개의 처리 엔티티: 호스트 및 가상 머신(또는 가상 프로세서로 간주됨)을 포함하고, 가상 프로세서의 트랩-인 및 트랩-아웃을 포함한다. 그 결과, 처리 절차가 더 길어지고, 지연이 증가한다. 이것은 명백하게 서비스 처리의 초-저 지연 요건을 충족시킬 수 없다. 따라서, 본 출원은 애플리케이션 인터럽트 요청 처리 지연을 효과적으로 감소시키기 위한 방법을 제공하고, 그 방법에 기초하여 더 많은 기능들을 점진적으로 확장시킨다.

애플리케이션 인터럽트 요청 처리 지연이 크다는 전술한 문제점을 해결하기 위해, 본 실시예에서 제공되는 디바이스(100)는 호스트 인터럽트 관리 유닛(181) 및 게스트 인터럽트 관리 유닛(191)을 포함한다. 2개의 유닛은 도 2의 인터럽트 처리 소프트웨어 프로그램(121)의 2개의 기능 모듈로서 간주될 수 있다.

호스트 인터럽트 관리 유닛(181)은 호스트 계층에 배치된다. VMM(180)이 호스트 운영 체제(170)에 배치될 때, 호스트 인터럽트 관리 유닛(181)은 호스트 운영 체제(170)에 배치될 수 있거나; 또는 VMM(180)에 배치될 수 있거나; 또는 부분적으로는 호스트 운영 체제(170)에 배치되고, 부분적으로는 VMM(180)에 배치될 수 있다. VMM(180)이 호스트 운영 체제(170)에 배치될 때, 호스트 인터럽트 관리 유닛(181)은 VMM(180)에 배치될 수 있거나; 또는 호스트 운영 체제(170)에 배치되지만 VMM(180)에는 배치되지 않을 수 있거나; 또는 부분적으로는 VMM(180)에 배치되고 부분적으로는 호스트 운영 체제(170)에 배치되지만 VMM(180)에는 배치되지 않을 수 있다.

게스트 인터럽트 관리 유닛(191)은 각각의 가상 머신의 게스트 운영 체제(190)에 배치될 수 있다. 가상화된 컴퓨터 디바이스의 가상 계층이 libOS일 때, 게스트 인터럽트 관리 유닛(191)은 libOS의 런타임 라이브러리에 배치될 수 있다. 게스트 인터럽트 관리 유닛(191)은 하드웨어 계층으로부터 인터럽트 요청을 직접 수신할 수 있도록 구성된다.

게스트 인터럽트 관리 유닛(191)은 인터럽트 제어기(160) 또는 다른 인터럽트 수집 장치로부터 인터럽트 요청을 직접 수신하고, 인터럽트 요청의 처리 엔티티를 결정하도록 구성된다. 인터럽트 요청의 처리 엔티티가 현재의 가상 머신의 현재의 가상 프로세서인 경우, 인터럽트 서비스 루틴이 직접 호출된다. 또한, 인터럽트 요청의 처리 엔티티가 호스트인 경우, 인터럽트 요청은 호스트에 전송된다. 또한, 인터럽트 요청의 처리 엔티티가 현재의 가상 프로세서 대신 다른 가상 프로세서인 경우, 인터럽트 요청은 처리를 위해 다른 가상 프로세서로 스케줄링된다. 다른 가상 프로세서가 서비스 가능인 경우, 인터럽트 요청은 IPI를 전송함으로써 스케줄링될 수 있거나; 또는 다른 가상 프로세서가 서비스 불능인 경우, 인터럽트 요청이 기록될 수 있어, 다른 가상 프로세서는 서비스 가능해진 후에 인터럽트 요청을 처리한다. "현재의 가상 머신"은 게스트 인터럽트 관리 유닛(191)이 속하는 가상 머신이고, "현재의 가상 프로세서"는 게스트 인터럽트 관리 유닛(191)을 현재 판독하고 실행하는 가상 프로세서라는 점에 유의해야 한다.

호스트 인터럽트 관리 유닛(181)은 가상 프로세서(110-v)의 인터럽트 수신 모드를 구성하도록 구성되어, 가상 프로세서(110-v)가 게스트 모드에서 하드웨어 계층으로부터 인터럽트 요청을 수신할 수 있게 한다. 일부 구현들에서, 호스트 인터럽트 관리 유닛(181)은 가상 프로세서(110-v)에 의해 인터럽트 제어기(160)를 동작시키기 위한 모드를 구성하도록 추가로 구성되어, 가상 프로세서(110-v)가 게스트 모드에서 물리적 인터럽트 제어기(160)(보통 가상 프로세서를 실행하는 물리적 코어의 로컬 인터럽트 제어기)를 직접 동작시킬 수 있게 한다. 또한, 호스트 인터럽트 관리 유닛(181)은 인터럽트 요청 처리에 요구되는 정보(다음의 실시예에서 표 1 및 표 2 참조)를 관리하고 - 정보는 애플리케이션이 인터럽트 요청을 등록할 때 제공되는 정보를 포함함 - ; 가상 머신 및 호스트에 의해 공유될 수 있는 저장 영역에 정보를 저장하여, 가상 머신 및 호스트가 정보를 액세스하거나 수정할 수 있게 하도록 추가로 구성된다. 또한, 호스트 인터럽트 관리 유닛(181)은 가상 머신에 의해 전송된 인터럽트 요청을 수신하고, 인터럽트 요청을 호스트 내의 기존의 인터럽트 처리 모듈에 전송하도록 추가로 구성된다. 모듈은 호스트에 배치된 인터럽트 서비스 루틴을 호출하여 인터럽트 요청을 처리한다.

도 4를 참조하면, 가상 프로세서(110-v)의 관점에서, 게스트 인터럽트 관리 유닛(191)에 의해 수행되는 액션은 게스트 모드(즉, 트랩-인 상태)에서 현재의 가상 머신의 현재의 가상 프로세서에 의해 수행되는 동작으로서 고려될 수 있다.

구체적으로, 가상 프로세서(110-v)는 먼저 수신된 인터럽트 요청의 처리 엔티티를 결정한다(S401). 인터럽트 요청의 처리 엔티티가 가상 프로세서(110-v) 자체라고 결정하는 경우, 가상 프로세서(110-v)는 인터럽트 요청을 처리하거나(S402); 인터럽트 요청의 처리 엔티티가 호스트라고 결정하는 경우, 가상 프로세서(110-v)는 인터럽트 요청을 호스트에 전송하거나(S403); 또는 인터럽트 요청의 처리 엔티티가 다른 가상 프로세서라고 결정하는 경우, 가상 프로세서(110-v)는 모든 가상 프로세서들에 의해 공유될 수 있는 저장 영역에 인터럽트 요청을 기록하거나, 인터럽트 요청을 예를 들어, IPI를 사용하여 다른 가상 프로세서에 전송하여(S404), 다른 가상 프로세서가 저장 영역에 액세스하고 인터럽트 요청을 처리하거나, IPI를 수신한 후에 인터럽트 요청을 처리하게 한다. 가상 프로세서(110-v)가 게스트 모드에서 물리적 인터럽트 제어기(160)를 직접 동작시킬 수 있도록 호스트 인터럽트 관리 유닛(181)이 가상 프로세서(110-v)를 구성하는 경우, 가상 프로세서(110-v)는, 게스트 모드에서, 인터럽트 제어기(160)가 IPI를 다른 가상 프로세서에 전송하도록 직접 동작시킬 수 있고, IPI는 처리되지 않은 인터럽트 요청에 관한 정보를 운반한다.

또한, 단계 S404의 구현들은 다음과 같다: 인터럽트 요청의 처리 엔티티가 다른 가상 프로세서라고 결정하는 경우, 일부 구현들에서, 가상 프로세서는 모든 가상 프로세서들에 의해 공유될 수 있는 저장 영역에만 인터럽트 요청을 기록하고, 인터럽트 요청의 처리 엔티티는 처리 엔티티의 실행 상태에 기초하여 적절한 시간에 저장 영역에 액세스하고 인터럽트 요청을 처리한다. 일부 다른 구현들에서, 가상 프로세서는 먼저 처리 엔티티가 서비스 가능인지를 결정할 수 있고; 처리 엔티티가 서비스 가능인 경우, 가상 프로세서는 IPI를 전송함으로써 인터럽트 요청을 서비스 가능 처리 엔티티에 전송하여, 처리 엔티티가 가능한 한 빨리 인터럽트 요청을 처리하게 하거나; 또는 처리 엔티티가 서비스 불능인 경우, 가상 프로세서는 모든 가상 프로세서들에 의해 공유될 수 있는 저장 영역에 인터럽트 요청을 기록하고, 추가로 중계 가상 프로세서(가상 프로세서 자체일 수 있음)를 결정하고, IPI 인터럽트를 중계 가상 프로세서에 전송할 수 있다. 중계 가상 프로세서는 IPI 인터럽트를 수신한 후에 호스트로 트랩 아웃한다. 그 후, 호스트는 처리 엔티티를 스왑 인한다. 스왑 인된 후에, 처리 엔티티는 인터럽트 요청을 처리한다. 중계 가상 프로세서가 가상 프로세서 자체인 경우, 가상 프로세서는 처리 엔티티의 식별자를 호스트에 전송하고, 트랩 아웃하여, 호스트가 처리 엔티티를 스왑 인하게 한다.

단계 S404의 일부 다른 구현들이 또한 존재한다: 인터럽트 제어기의 인터럽트 친화성 속성이 본 출원에서 제공되는 방법에 따라 구성된 후에, 인터럽트 요청의 처리 엔티티가 다른 가상 프로세서라고 결정되면, 처리 엔티티가 서비스 가능인지를 결정할 필요가 없는데, 그 이유는 처리 엔티티가 명확히 서비스 불능이기 때문이다. 따라서, 인터럽트 요청은 모든 가상 프로세서들에 의해 공유될 수 있는 저장 영역에 기록될 수 있다. 전술한 단락에서 설명된 방식과 마찬가지로, 호스트 머신은 또한, 인터럽트 요청이 가능한 한 빨리 처리되는 것을 보장하기 위해, 처리 엔티티를 스왑 인하도록 능동적으로 트리거될 수 있다.

전술한 실시예들로부터, 본 발명의 실시예들에서 제공되는 인터럽트 요청 처리 방법에 따라, 가상 프로세서(또는 가상 프로세서에 의해 서빙되는 가상 머신)가 하드웨어에 의해 생성된 인터럽트 요청을 직접 수신할 수 있다는 것을 알 수 있다. 애플리케이션 인터럽트 요청의 경우, 가상 프로세서는, 호스트에 의한 포워딩 또는 가상 프로세서의 트랩-인 및 트랩-아웃 없이, 가상 머신 내의 인터럽트 서비스 루틴을 직접 호출하여 애플리케이션 인터럽트 요청을 처리할 수 있다. 이것은 애플리케이션 인터럽트 요청의 처리 효율을 크게 개선시키고, 애플리케이션 인터럽트 요청의 처리 지연을 감소시킨다. 분명히, 게스트 운영 체제 인터럽트 요청에 대해서도 동일한 효과가 달성된다.

또한, 현재의 가상 프로세서에 의해 처리되지 않을 인터럽트 요청의 경우, 현재의 가상 프로세서가 트랩 아웃될 필요가 없는 동안 인터럽트 요청이 기록될 수 있거나, 현재의 가상 프로세서가 트랩 아웃될 필요가 없는 동안 인터럽트 요청이 다른 가상 프로세서에 전송되어, 다른 가상 프로세서가 인터럽트 요청을 가능한 한 빨리 처리할 수 있게 한다. 이것은 인터럽트 요청의 처리 효율을 추가로 개선시킨다.

또한, 호스트에 의해 처리될 필요가 있는 인터럽트 요청의 경우, 인터럽트 요청은 호스트에 역방향으로 전송될 수 있어, 인터럽트 요청이 적시에 처리되게 한다. 이러한 방식으로, 본 발명의 실시예들에서 제공되는 방법은 호스트에 의해 처리될 필요가 있는 인터럽트 요청이 명확히 존재하는 복잡한 시스템에 적용될 수 있고, 본 발명의 실시예들은 더 광범위하게 적용된다.

도 5는 더 상세한 실시예를 도시한다. 본 실시예에서, 프로세서는 중앙 처리 유닛(central processing unit, CPU)(210)이고, 가상 프로세서는 vCPU이고, 인터럽트 제어기는 진보된 프로그램가능 인터럽트 제어기(Advanced Programmable Interrupt Controller, APIC)(260)이고, 2개의 가상 머신은 가상 머신(29-1) 및 가상 머신(29-2)이다. APIC(260)는 보통 하나의 io-APIC, 및 4개의 물리적 코어에 각각 대응하는 4개의 local-APIC를 포함한다.

호스트 인터럽트 관리 유닛(281)은 인터럽트 구성 유닛(2811), 스케줄링 실행 유닛(2812), 및 인터럽트 수신 유닛(2813)을 포함한다. 게스트 인터럽트 관리 유닛(291)은 인터럽트 스케줄링 유닛(2911), 인터럽트 분배 유닛(2912), 및 인터럽트 트리거 유닛(2913)을 포함한다. 인터럽트 벡터 테이블(31) 및 실행 엔티티 테이블(32)은 인터럽트 요청을 처리하기 위해 요구되는 정보를 저장한다. 정보 관리를 용이하게 하기 위해, 이 실시예에서, 2개의 테이블 모두는 모든 가상 머신들(모든 가상 프로세서들) 및 호스트에 액세스가능한 저장 영역에 위치한다. 이것은 또한 모든 다음의 실시예들에서 제공되는 방법들의 구현을 용이하게 한다. 일부 다른 실시예들에서, 2개의 테이블의 형태 및 콘텐츠는 상황에 따라 조정되도록 허용된다.

인터럽트 벡터 테이블(31)은 주로 애플리케이션 인터럽트 요청의 식별자, 및 애플리케이션 인터럽트 요청에 대응하는 처리 엔티티와 인터럽트 서비스 루틴을 기록하는 데 사용되고, IPI 인터럽트 요청 및/또는 게스트 운영 체제 인터럽트 요청에 관한 정보를 추가로 기록할 수 있다.

인터럽트 벡터 테이블(31)은 IPI 인터럽트와 같은 게스트 운영 체제 인터럽트 요청의 식별자, 대응하는 처리 엔티티, 및 대응하는 인터럽트 서비스 루틴을 추가로 포함할 수 있다.

실행 엔티티 테이블(32)은 주로 VM들에 포함된 모든 vCPU들의 현재 상태들, 예를 들어, vCPU들이 서비스 가능인지를 기록하고, vCPU들에 의해 처리될 인터럽트 요청들을 기록하는 데 사용된다.

표 1 및 표 2는 각각 인터럽트 벡터 테이블(31) 및 실행 엔티티 테이블(32)의 예들이다.

표 1은 애플리케이션 인터럽트 요청의 IRQ ID, 및 애플리케이션 인터럽트 요청에 대응하는 처리 엔티티와 인터럽트 서비스 루틴만을 저장한다. 인터럽트 요청의 IRQ ID가 테이블에 있지 않은 경우, 디폴트로 인터럽트 요청이 호스트에 의해 처리될 필요가 있고, 인터럽트 요청이 호스트에 전송(또는 주입되는 것으로 지칭됨)되어, 호스트가 인터럽트 요청을 처리하게 하는 것이 고려된다.

일부 다른 실시예들에서, 표 1은 대안적으로 모든 인터럽트 요청의 식별자들을 저장할 수 있고, 여기서 처리 엔티티는 가상 머신 또는 호스트로서 기록되거나; 또는 모든 인터럽트 요청들의 식별자들을 저장할 수 있고, 여기서 VM ID가 비어 있다는 것은 처리 엔티티가 호스트인 것을 표시할 수 있거나; 또는 이와 유사하다. 정보 저장 방식들의 다양한 변형들이 본 기술분야의 통상의 기술자에 의해 용이하게 이해되며, 여기서는 일일이 설명되지 않는다.

본 발명의 이 실시예에서, vCPU LIST의 특정 데이터 구조는 비트맵으로서 구현될 수 있고, 비트맵 내의 각각의 비트(bit)는 하나의 vCPU를 나타낸다.

표 1에서의 PRIORITY는 인터럽트 요청의 우선순위를 기록한다. 인터럽트 요청의 우선순위를 설정하는 방식은 VMM에서의 vCPU의 우선순위(표 2 참조)를 설정하는 방식과 유사할 필요가 있고, 따라서 2개의 우선순위가 후속하여 비교될 수 있다. 인터럽트 요청의 우선순위는 인터럽트 요청을 처리하는 vCPU의 우선순위와 상이할 수 있다. 2개의 우선순위의 비교 결과는 일부 실시예들에서 어느 vCPU가 인터럽트 요청에 의해 선점되어 인터럽트 요청이 도달한 후에 실행되는지를 결정하기 위한 기준으로서 사용될 수 있다.

PRIORITY는 관련 VM이 시작되기 전에 구성된다. 구체적으로, 사용자는 인터럽트 구성 유닛(2811)의 균일한 구성 인터페이스(sysfs 인터페이스 또는 proc 인터페이스)를 사용하여 구성을 수행할 수 있다. 인터럽트 타입 TYPE이 또한 유사한 방식으로 구성될 수 있다.

본 출원의 일부 실시예들에서, 인터럽트 벡터 테이블(31) 및 실행 엔티티 테이블(32)에 저장된 콘텐츠는 표 1 및 표 2의 예들보다 더 많거나 더 적을 수 있다. 예를 들어, 2개의 테이블 내의 VM ID가 저장되지 않을 수 있다. 그러나, 일부 시나리오들에서 VM ID가 저장되는 경우 편의성이 향상될 수 있다. 예를 들어, 인터럽트 요청은 VM의 모든 vCPU들에 의해 처리될 수 있다. 이 경우, VM ID만이 결정될 필요가 있다. 일부 실시예들에서, PRIORITY 및/또는 TYPE 정보는 저장되지 않을 수 있다.

구성 채널(33) 및 주입 채널(34)이 각각의 가상 머신(29-1 및 29-2)과 호스트 사이에 구성된다. 구성 채널(33)은 인터럽트 벡터 테이블(31)을 채우기 위해 게스트 인터럽트 관리 유닛(291)에 의해 주로 사용된다. 주입 채널(34)은 호스트에 의해 처리될 인터럽트 요청을 호스트에 주입하여 호스트 인터럽트 관리 유닛(281)이 인터럽트 요청을 처리하게 하기 위해 게스트 인터럽트 관리 유닛(291)에 의해 주로 사용된다.

가상 머신 및 호스트는 각각 호출된 후에 인터럽트 요청을 처리하는 데 사용되는 복수의 인터럽트 서비스 루틴(292 및 283)을 포함한다. 가상 머신 내의 인터럽트 서비스 루틴(292)은 보통 가상 머신 상에 설치된 애플리케이션에 의해 배치되고, 애플리케이션 인터럽트 요청을 처리하는 데 사용된다. 분명히, 일부 인터럽트 서비스 루틴들(292)은 게스트 운영 체제(290)에 의해 배치되고, 게스트 운영 체제 인터럽트 요청을 처리하는 데 사용된다.

호스트는 게스트 인터럽트 관리 유닛(291)으로부터 호스트 인터럽트 관리 유닛(281)(구체적으로는, 인터럽트 수신 유닛(2813))에 의해 수신되는 인터럽트 요청을 수신하고, 인터럽트 요청에 대응하는 인터럽트 서비스 루틴(283)을 호출하도록 구성되는 호스트 인터럽트 분배 유닛(282)을 추가로 포함한다. 호스트 인터럽트 분배 유닛(282)은 또한 일부 기존의 가상화 아키텍처들에 존재하고, 이 실시예에서는, APIC(260)로부터 직접 수신하기보다는 호스트 인터럽트 관리 유닛(281)으로부터 인터럽트 요청을 수신하도록 구성된다. 도 5의 다른 모듈들은 도 4에서와 유사하고, 상세사항들은 여기서 다시 설명되지 않는다.

이하에서는 도 5에 기초한 상세한 방법 구현 프로세스를 설명한다.

(1) 호스트 인터럽트 관리 유닛의 초기화

호스트 인터럽트 관리 유닛(281)이 VMM에 위치하는 예가 이 실시예에서 예로서 사용된다. 도 6은 호스트 인터럽트 관리 유닛(281)을 초기화하는 개략적인 흐름도이다. 호스트 인터럽트 관리 유닛(281)의 초기화는 VMM의 초기화와 함께 수행된다.

인터럽트 구성 유닛(2811)을 초기화하는 단계(S501)는: 구성 채널(33)을 준비하는 단계(S5011) 및 인터럽트 벡터 테이블(31)을 준비하는 단계(S5012)를 포함한다. 구성 채널(33)을 준비하는 단계(S5011)는: 구성 채널(33)로서 사용되는 하이퍼콜 함수(hypercall function)를 VMM의 하이퍼콜 프레임워크에 장착하여, 가상 머신들(29-1 및 29-2)이 하이퍼콜을 통해 함수를 호출함으로써 구성 채널(33)을 사용할 수 있게 하는 단계를 포함한다. 인터럽트 벡터 테이블(31)을 준비하는 단계(S5012)는: 공유 메모리 영역을 결정하는 단계, 인터럽트 벡터 테이블(31)의 엔트리들을 분할하는 단계 등을 포함한다(표 1 참조). 공유 메모리 영역은 인터럽트 벡터 테이블의 내용을 저장하도록 구성된다. 실행 스케줄링 유닛(2812)을 초기화하는 단계(S502)는: 실행 엔티티 테이블(32)을 준비하는 단계(S5021)를 포함한다. 실행 엔티티 테이블(32)을 준비하는 단계(S5021)는: 다른 공유 메모리 영역을 결정하는 단계, 실행 엔티티 테이블(32)의 엔트리들을 분할하는 단계 등을 포함한다(표 2 참조). 공유 메모리 영역은 실행 엔티티 테이블(32)의 내용을 저장하도록 구성된다.

이 실시예에서 제공되는 "공유 메모리 영역"은 모든 가상 머신들(29-1 및 29-2) 및 호스트에 액세스가능한 저장 영역의 세그먼트이다.

인터럽트 수신 유닛(2813)을 초기화하는 단계(S503)는: 주입 채널(34)을 준비하는 단계(S5031)를 포함하고, 구체적으로는: 인터럽트 주입을 위해 사용되는 하이퍼콜 함수를 VMM의 하이퍼콜 프레임워크에 장착하여, 가상 머신들(29-1 및 29-2)이 하이퍼콜을 통해 함수를 호출할 수 있게 하는 단계를 포함한다.

전술한 3개의 유닛의 초기화는 VMM의 코어 모듈의 초기화가 완료되기 전 또는 후에 수행될 수 있거나; 또는 VMM의 코어 모듈의 초기화가 부분적으로 완료되고 나서, VMM의 코어 모듈의 나머지 초기화 프로세스가 계속해서 완료된 후에 수행될 수 있다. 전술한 3개의 유닛의 초기화는 병렬로 또는 직렬로 실행될 수 있고, 실행 시퀀스는 본 발명의 이 실시예에서 제한되지 않는다.

(2) 게스트 인터럽트 관리 유닛의 초기화

VMM이 초기화되어 시작된 후에, 호스트 인터럽트 관리 유닛(281)의 초기화도 완료된다. 그 후, VMM은 2개의 가상 머신(29-1 및 29-2)을 생성하고 시작한다. 가상 머신들(29-1 및 29-2)의 생성 및 시작 동안, 게스트 인터럽트 관리 유닛(291)의 초기화가 완료된다.

도 7을 참조하면, 가상 머신의 전체 시작 프로세스는 2개의 부분: vCPU 트랩-인 이전 및 vCPU 트랩-인 이후로 분할된다.

S601: VMM(180)은 VM 객체를 생성하고 초기화한다.

S602 및 S602-d: VMM(180)은 VM 객체에 대한 주요 vCPU 및 보조 vCPU를 생성한다.

도 5에서, 하나의 가상 머신은 3개의 vCPU를 가지며, 여기서 하나의 vCPU는 주요 vCPU이고, 다른 2개의 vCPU는 보조 vCPU들이다. 이 실시예는 주요 vCPU 및 하나의 보조 vCPU를 예들로 사용하여 설명된다. 다른 보조 vCPU의 초기화 프로세스는 설명된 보조 vCPU의 초기화 프로세스와 유사하다.

S603: VMM(180)은 맞춤형 파라미터들(custom parameters)에 기초하여 주요 vCPU 및 보조 vCPU에 대한 인터럽트 수신 모드 및 APIC(260) 동작 모드를 구성한다. 구성의 목적은, vCPU가, 게스트 모드에서(다시 말해서, 트랩 인 이후에), APIC에 의해 전송된 인터럽트 요청을 수신하고, 게스트 모드에서 APIC(260)를 동작시키는 것을 가능하게 하는 것이다. 본 명세서에서의 맞춤형 파라미터들은 본 출원에서 정의되고, 이러한 파라미터들은 전술한 구성에 따라 VM을 구성하도록 VMM에 지시하기 위해 사용된다. vCPU의 이들 2가지 모드는 vCPU에 대응하는 레지스터 내의 상이한 비트들에 의해 표시된다.

구체적으로, 물리적 CPU의 HCR_EL2(hypervisor configuration register EL2) 레지스터의 2개의 비트, 즉, FMO 및 IMO가 ARM64 플랫폼 상에서 디스에이블된 후에, vCPU는 트랩 아웃 없이 인터럽트 요청을 수신하고 물리적 APIC를 동작시킬 수 있다. X86 플랫폼 상에서, VMCS(virtual machine control structure)의 Pin-Based VM-Execution Controls 제어 비트들의 비트 0(external-interrupt exiting)이 0으로 설정된 후에, 인터럽트 요청은 트랩-아웃 없이 수신될 수 있고; VMCS의 Pin-Based VM-Execution Controls 제어 비트들의 비트 7(process posted interrupts)이 0으로 설정되고, VMCS의 Primary Processor-Based VM-Execution Controls 제어 비트들의 비트 21(Use TPR Shadow)이 0으로 설정되고, VMCS의 Secondary Processor-Based VM-Execution Controls 제어 비트들의 비트 8(APCI-register virtualization) 및 비트 9(Virtual-interrupt delivery)가 0으로 설정되고, VMCS의 VM-execution control의 MSR-Bitmap에서의 LAPIC-관련 비트들이 0으로 설정된 후에, vCPU는 물리적 APIC를 직접 동작시킬 수 있다.

그러나, 단계 S603에서, 인터럽트 수신 모드와 APIC(260) 동작 모드에 관련된 메모리 객체들의 값들은 구성되지만(본질적으로, 값들은 메모리들에 기록되지만), 물리적 레지스터는 실제로 수정되지 않는다.

단계 S603은 호스트 인터럽트 관리 유닛(281) 내의 인터럽트 구성 유닛(2811)에 의해 구현될 수 있다.

S604 및 S604-d: VMM(180)은 주요 vCPU 및 보조 vCPU를 물리적 코어들로 개별적으로 스케줄링한다. 그러나, 이 경우, 주요 vCPU 및 보조 vCPU는 싱크 인되지 않는다.

S605: VMM(180)은 실행 엔티티 테이블(32)을 업데이트한다.

VMM(180)은, 실행 엔티티 테이블(32)에서, 현재의 vCPU의 VM ID 및 vCPU ID, vCPU에 대응하는 물리적 코어의 CORE ID, 및 vCPU의 우선순위를 기록한다. vCPU의 우선순위는 보통 VMM에서 설정되고, 따라서 VMM은 vCPU의 우선순위를 획득할 수 있다. 복수의 vCPU가 존재하는 경우, 복수의 vCPU는 트랩 인 이전에 실행 엔티티 테이블(32)을 개별적으로 업데이트한다.

vCPU가 단계들 S604 및 S604-d 이후에 스왑 인되었기 때문에, vCPU를 실행하는 물리적 코어의 실제 CORE ID가 실행 엔티티 테이블(32)에 기록된다. 이 경우, vCPU는 싱크 인되지 않았고, 다시 말해서, vCPU는 서비스 불능이다. 그러나, 이 실시예에서, vCPU는 실행 엔티티 테이블이 업데이트된 후에 즉시 트랩 인하도록 구성된다. 따라서, 여기서 기록된 CORE ID의 의미는 표 2에서의 CORE ID의 의미와 일관된다.

단계 S605는 호스트 인터럽트 관리 유닛(281)에서 스케줄링 실행 유닛(2812)에 의해 구현될 수 있다. 스케줄링 실행 유닛(2812)은 초기화 단계에서 실행 엔티티 테이블(32)을 업데이트할 필요가 있고, 또한 실행 엔티티 테이블(32)에 기록된 vCPU의 서비스 가능 또는 서비스 불능 상태가 정확하다는 것을 보장하기 위해, vCPU가 스왑 인된 후 vCPU가 게스트 모드로 트랩 인하기 전마다, 그리고 vCPU가 스왑 아웃되기 전마다, 실행 엔티티 테이블(32)을 업데이트할 필요가 있다.

S606 및 S606-d: 주요 vCPU 및 보조 vCPU는 게스트 모드로 트랩 인한다. 트랩-인 동안, 주요 vCPU 및 보조 vCPU는, 주요 vCPU 및 보조 vCPU에 개별적으로 대응하는 메모리들로부터, 인터럽트 수신 모드 및 APIC 동작 모드에 대응하고 단계 S603에서 설정되는 속성 값들을 판독하고; 속성 값들에 기초하여 주요 vCPU 및 보조 vCPU에 개별적으로 대응하는 레지스터들을 수정한다. 여기서 수정된 레지스터들은 vCPU들을 실행하는 물리적 코어들에 대응하는 물리적 레지스터들이다.

게스트 모드로 트랩 인 후에, 주요 vCPU 및 보조 vCPU는 상이하게 초기화된다. 게스트 운영 체제(guest OS) 초기화는 주요 vCPU에 대해 수행되고, 제2 vCPU의 초기화만이 보조 vCPU에 대해 수행된다.

게스트 운영 체제 및 보조 vCPU의 초기화-이전 단계(S607 및 S607-d)가 완료된 후에, 게스트 인터럽트 관리 유닛(291)의 초기화가 시작된다(S608 및 S608-d). 게스트 인터럽트 관리 유닛(291)의 초기화는 다음의 단계들을 포함한다.

S609: 인터럽트 분배 유닛(2912)은 인터럽트 구성 유닛(2811)에 의해 제공되는 구성 채널(33)을 사용하여 인터럽트 벡터 테이블(31)의 어드레스 정보를 획득한다(이 단계는 주요 vCPU에 대해서만 수행될 필요가 있다). 어드레스 정보는 구체적으로 인터럽트 벡터 테이블(31)의, 메모리에서의, 시작 어드레스 및 종료 어드레스일 수 있다.

S610: 인터럽트 분배 유닛(2912)은 인터럽트 구성 유닛(2811)에 의해 제공되는 구성 채널(33)을 사용하여 VM ID를 획득하고, VM ID를 변수에 저장한다(이 단계는 주요 vCPU에 대해서만 수행될 필요가 있다). 대안적으로, VM ID는 일부 다른 실시예들에서 획득되지 않을 수 있다.

S611: 인터럽트 분배 유닛(2912)은 현재의 vCPU ID를 획득하고, 현재의 vCPU ID를 변수에 저장한다. 이 단계는 주요 vCPU와 보조 vCPU 둘 다에 대해 수행될 필요가 있고, vCPU ID들은 주요 vCPU 및 보조 vCPU의 변수들에 개별적으로 저장된다.

S612: 인터럽트 분배 유닛(2912)은 각각의 vCPU에 대응하는 레지스터에 게스트 인터럽트 관리 유닛(291)의 엔트리포인트 함수(entrypoint function)의 어드레스를 구성하여, 인터럽트 요청을 수신한 후에, 각각의 vCPU가 레지스터에서 엔트리포인트 함수의 어드레스를 직접 판독함으로써 게스트 인터럽트 관리 유닛(291)의 기능을 획득 및 실행할 수 있게 한다. 이 실시예에서는, 인터럽트 분배 유닛(2912)이 먼저 작동하기 때문에, 게스트 인터럽트 관리 유닛(291)의 엔트리포인트 함수는 이 실시예에서 인터럽트 분배 유닛(2912)의 엔트리포인트 함수이다.

상이한 프로세서들은 인터럽트 처리 엔트리포인트 함수를 저장하는 데 사용될 레지스터를 결정하기 위해 상이한 규칙들을 가질 수 있다. X86 시스템에서, 이것은 lidt 명령어를 사용하여 인터럽트 디스크립터 테이블 레지스터(interrupt descriptor table register, IDTR)를 수정함으로써 구현될 수 있다. 구체적으로, 인터럽트 디스크립터 테이블(interrupt descriptor table, IDT)이 lidt 명령어를 사용하여 IDTR에 로딩된다. 인터럽트 처리 엔트리포인트 함수의, IDT 테이블에서의 어드레스가 인터럽트 분배 유닛(2912)의 엔트리포인트 함수로 채워진다. ARM64 시스템에서, 이것은 msr 명령어를 사용하여 레지스터 vbar_el1(vector base address register el1)을 수정함으로써 구현된다.

프로그램(기능 유닛 또는 모듈)의 "엔트리포인트 함수"는 프로그램(또는 기능 유닛 또는 모듈)이 실행될 때 처음 호출되는 함수라는 점에 유의해야 한다. "인터럽트 처리 엔트리포인트 함수"는, vCPU가 인터럽트 요청에 의해 인터럽트된 후에 vCPU에 의해 실행되는 첫번째 명령어를 포함하는 함수이다. 예를 들어, vCPU가 인터럽트 요청에 의해 인터럽트된 후에, vCPU에 의해 실행될 필요가 있는 첫번째 명령어는 인터럽트 분배 유닛(2912)의 명령어이고, 인터럽트 처리 엔트리포인트 함수는 인터럽트 분배 유닛(2912)의 엔트리포인트 함수로 설정되어야 한다.

게스트 인터럽트 관리 유닛(291)의 초기화가 완료된 후에, 게스트 운영 체제의 초기화가 완료될 때까지, 게스트 운영 체제는 초기화 프로세스의 다음 단계(S613 및 S613-d)에 진입한다. 또한, 게스트 운영 체제는 애플리케이션(또는 서비스)이 실행될 수 있는 상태에 진입한다. 그 후, 애플리케이션은 게스트 운영 체제에 배치될 수 있고, 애플리케이션은 인터럽트 분배 유닛(2912)에 의해 제공되는 인터페이스를 사용하여 ISR 등록을 수행할 수 있다(S614 및 S614-d). ISR 등록 동안, 인터럽트 분배 유닛(2912)은 구성 채널(33)을 사용하여 인터럽트 구성 유닛(2811)에 통지한다. 그 다음, vCPU는 트랩 아웃한다(S615). 그 후 인터럽트 구성 유닛(2811)은 인터럽트 벡터 테이블(31)에서 등록 정보를 채우기 위해 인터럽트 벡터 테이블(31)을 수정한다. 그 다음, vCPU는 즉시 다시 트랩 인한다(S616).

본 기술분야의 통상의 기술자는, 가상화된 디바이스에서, 가상 머신 내의 각각의 유닛의 기능이, vCPU가 유닛의 프로그램 또는 명령어를 판독하고 실행한 후에 구현되는 것으로서 이해될 수 있다는 것을 이해해야 한다. 예를 들어, 인터럽트 분배 유닛(2912)이 구성 채널(33)을 사용하여 인터럽트 구성 유닛(2811)에 통지하는 것은: vCPU가 인터럽트 분배 유닛(2912)의 프로그램을 판독하고, 프로그램에 따라 구성 채널(33)의 하이퍼콜 함수를 호출하는 것으로서 간주될 수 있다(이후 vCPU는 호스트 모드로 트랩 아웃한다). 다음으로, 호스트(vCPU에 대응하는 호스트 스레드)는 인터럽트 구성 유닛(2811)의 프로그램을 판독하고, 프로그램에 따라 인터럽트 벡터 테이블을 수정한다. 수정이 완료된 후에, vCPU는 다시 게스트 모드로 트랩 인한다. 또한, 본 실시예에서, 호스트 인터럽트 관리 유닛(281)은 VMM에 위치하고, 따라서 호스트 인터럽트 관리 유닛(281)에 의해 수행되는 동작은 또한 VMM에 의해 수행되는 동작으로서 이해될 수 있다. 동작이 가상 머신 내의 vCPU 또는 유닛에 의해 수행되는지 또는 동작이 호스트 내의 VMM 또는 유닛에 의해 수행되는지에 관계없이, 동작은 궁극적으로 소프트웨어 프로그램을 실행하는 물리적 프로세서에 의해 수행된다.

인터럽트 구성 유닛(2811)은 VMM에 의해 생성된 vCPU 객체 내로 구성을 기입한다(단계 S603 참조). 따라서, 후속하여 vCPU가 트랩 인할 때마다, vCPU에 대응하는 물리적 레지스터의 값이 구성에 기초하여 설정될 수 있어, 트랩 인 이후에, vCPU가 트랩 아웃 없이 APIC로부터 모든 인터럽트 요청들을 직접 수신하고, vCPU가 물리적 APIC를 직접 동작시킬 수 있다는 효과를 달성할 수 있다.

(3) 인터럽트 요청 처리 절차

전술한 단계들 후에, 가상화된 디바이스가 실행 상태에 진입하였고, 가상화된 디바이스 상에 배치된 가상 머신 및 가상 머신 상의 애플리케이션이 실행되고 있다. 이하에서는 본 실시예에서 제공되는 가상화된 디바이스가 실행 동안 인터럽트 요청을 처리하는 절차를 상세히 설명한다.

도 8a에 도시된 바와 같이, 먼저, 하드웨어는 인터럽트 요청을 생성하고, 인터럽트 요청을 APIC(260)에 전송한다(S701a). 예를 들어, 하드웨어 네트워크 인터페이스 카드가 인터럽트 요청을 생성하고, 인터럽트 요청을 APIC(260)에 전송한다. APIC(260)는 특정 규칙에 따라 인터럽트 요청을 물리적 코어에 전송하고, 게스트 모드에서 물리적 코어 상에서 실행되는 vCPU의 실행이 인터럽트된다(S702a). vCPU는 트랩 아웃 없이 게스트 모드에서 인터럽트를 수신할 수 있도록 이전에 구성되었다. 따라서, vCPU의 실행이 인터럽트된 후에, vCPU는 레지스터에 저장된 인터럽트 분배 유닛(2912)의 엔트리포인트 함수의 실행으로 직접 이동하고, 인터럽트 요청을 인터럽트 분배 유닛(2912)에 전송한다(S703a). 이러한 방식으로, 게스트 인터럽트 관리 유닛(291)의 기능들이 점진적으로 작용한다. 일부 인터럽트 요청은 APIC(260)에 의해 복수의 물리적 코어에 전송된다. 각각의 물리적 코어의 처리 방식은 전술한 방식과 유사하고, 상세사항들은 각각의 물리적 코어에 대해 일일이 설명되지 않는다.

인터럽트 요청을 전송하는 프로세스는 상이한 컴퓨터 아키텍처들에서 달라질 수 있다는 점에 유의해야 한다. 예를 들어, X86 시스템에서, APIC(260)는 io-APIC 및 local-APIC를 포함한다. io-APIC는 하드웨어에 의해 생성된 모든 인터럽트 요청을 수집하고, 그에 대응하여 인터럽트 요청을 local-APIC에 전송하는 것을 담당한다. 그 다음, local-APIC는 인터럽트 요청들을 대응하는 물리적 코어들에 포워딩한다. 이 실시예에서, 설명의 단순화를 위해, 이 프로세스는, APIC(260)에 의해, 물리적 코어에 인터럽트 요청을 전송하는 것으로서 간략하게 설명된다.

이 실시예에서, 인터럽트 요청이 물리적 코어에 전송되지만, 물리적 코어의 vCPU가 서비스 불능인 경우, 다시 말해서, 물리적 코어가 호스트 모드에 있고 호스트 상에서 기능 유닛을 실행하고 있는 경우 - 기능 유닛은 보통 VMM임 - , 물리적 코어(즉, VMM)는 인터럽트 요청을 처리하지 않는데, 그 이유는 호스트 모드의 인터럽트 응답 비트가 디스에이블되기 때문이다. 후속 실시예는 보상 방법을 제공하고, 호스트 모드의 인터럽트 응답 비트가 디스에이블되지 않을 때 VMM이 인터럽트 요청을 처리하는 방법을 설명한다.

전술한 단계(S703a)를 참조하면, 도 8b에 도시된 바와 같이, 인터럽트 분배 유닛(2912)은 인터럽트 요청의 IRQ ID를 식별하고, IRQ ID를 인터럽트 스케줄링 유닛(2911)에 전송한다(S701b). 인터럽트 스케줄링 유닛(2911)은, IRQ ID에 기초하여 인터럽트 벡터 테이블로부터, 인터럽트 요청의 처리 엔티티 및 인터럽트 요청에 대응하는 ISR의 어드레스, 즉, 전술한 표 1의 IRQ ID에 대응하는 vCPU LIST 및 ISR ADDR을 질의한다(S702b). 인터럽트 스케줄링 유닛(2911)은 질의를 통해 ISR ADDR이 획득될 수 있는지를 결정한다(S703b).

ISR ADDR이 없으면, 이는 인터럽트 요청이 애플리케이션 인터럽트 요청도 게스트 운영 체제 인터럽트 요청도 아니며, 인터럽트 요청의 처리 엔티티는 가상 머신이 아님을 나타낸다. 따라서, 인터럽트 스케줄링 유닛(2911)은 질의 결과를 인터럽트 분배 유닛(2912)에 반환한다(S704b). 그 후, 인터럽트 분배 유닛(2912)은 주입 채널(34)을 사용하여 인터럽트 요청을 호스트에 주입한다(S705b). 구체적으로, 인터럽트 분배 유닛(2912)은 주입 채널(34)을 사용하여 인터럽트 요청을 호스트 내의 인터럽트 수신 유닛(2813)에 전송할 수 있다. 인터럽트 수신 유닛(2813)은 인터럽트 요청을 호스트 인터럽트 분배 유닛(282)에 전송한다. 그 다음, 호스트 인터럽트 분배 유닛(282)은 인터럽트 요청에 대응하고 호스트 내에 있는 ISR을 호출한다. 호스트 인터럽트 분배 유닛(282)에 의해 수행되는 처리는 종래 기술에 속하고, 상세사항들은 여기서 설명되지 않는다.

ISR ADDR이 있으면, 인터럽트 스케줄링 유닛(2911)은 현재의 vCPU(즉, 실행이 인터럽트된 vCPU)가 질의를 통해 획득된 vCPU LIST에 포함되는지를 결정하고, 다시 말해서, 현재의 vCPU가 인터럽트 요청의 처리 엔티티들 중 하나인지를 결정한다(S706b).

이 실시예에서, 인터럽트 벡터 테이블(31)은 애플리케이션 인터럽트 요청 및 게스트 운영 체제 인터럽트 요청을 저장한다는 점에 유의해야 한다. 따라서, 전술한 방법들은 처리 엔티티를 결정하는 데 사용될 수 있다. 다른 실시예에서, 인터럽트 벡터 테이블(31)의 내용이 변경되면, 처리 엔티티를 결정하기 위한 방법이 또한 적응적으로 변경될 수 있다.

현재의 vCPU가 질의를 통해 획득된 vCPU LIST에 포함되는 경우, 인터럽트 스케줄링 유닛(2911)은 인터럽트 분배 유닛(2912)에 질의를 통해 획득된 ISR ADDR을 반환한다(S707b). 그 후 인터럽트 분배 유닛(2912)은 ISR ADDR에 의해 표시된 인터럽트 서비스 루틴을 호출하도록 인터럽트 트리거 유닛(2913)에 지시하고(S708b), 인터럽트 서비스 루틴은 인터럽트 요청을 처리하는데 사용된다. 이 경우, 인터럽트 요청의 처리가 완료되고, vCPU는 vCPU의 실행이 인터럽트된 위치로 복귀하고, 실행을 계속한다.

현재의 vCPU가 질의를 통해 획득된 vCPU LIST에 포함되지 않는 경우, 실행 엔티티 테이블(32)을 질의하여 vCPU LIST가 서비스 가능 vCPU를 포함하는지를 결정할 수 있다(S709b).

현재의 vCPU가 질의를 통해 획득된 vCPU LIST에 포함되지 않고, vCPU LIST가 적어도 하나의 서비스 가능 vCPU를 포함하는 경우, 인터럽트 스케줄링 유닛(2911)은 서비스 가능 vCPU로부터 하나의 vCPU를 선택하고, IPI 인터럽트를 선택된 vCPU에 전송한다(S710b). IPI 인터럽트는 인터럽트 요청의 식별자(IRQ ID)를 운반하여, 선택된 vCPU가 인터럽트 요청을 처리하게 한다. 여기서 선택은 랜덤 선택일 수 있거나, vCPU LIST 내의 모든 vCPU들의 우선순위들에 기초하여 가장 낮은 우선순위를 갖는 vCPU를 선택하는 것일 수 있다.

현재의 vCPU가 질의를 통해 획득된 vCPU LIST에 포함되지 않고 vCPU LIST 내의 vCPU들 중 어느 것도 서비스 가능이 아니면, 인터럽트 스케줄링 유닛(2911)은 vCPU LIST로부터 타겟 vCPU를 선택하고, 실행 엔티티 테이블(32)을 업데이트한다(S711b). 구체적으로, 실행 엔티티 테이블(32)을 업데이트하는 것은: 타겟 vCPU에 대응하는 PENDING 비트를 실행 엔티티 테이블(32)에 기록하고, 비트의 값을 인터럽트 요청의 IRQ ID로서 기록하여, 타겟 vCPU가 인터럽트 요청을 처리하게 하는 것을 포함한다. "타겟 vCPU"는 vCPU LIST 내의 모든 vCPU를 포함할 수 있거나, 랜덤으로 선택된 vCPU일 수 있다. 또한, 실행 엔티티 테이블(32)을 업데이트하는 것에 부가하여, 인터럽트 스케줄링 유닛(2911)은 타겟 vCPU의 스왑-인을 능동적으로 트리거할 수 있고(S712b), 따라서 인터럽트 요청은 가능한 한 빨리 처리된다. 어느 vCPU가 타겟 vCPU로서 선택되어야 하는지 및 vCPU의 스왑-인을 능동적으로 트리거할지의 여부는 인터럽트 요청의 우선순위 및 vCPU의 우선순위에 기초하여 결정될 수 있다. 구체적인 방법은 이하의 실시예에서 상세히 설명된다.

"타겟 vCPU"에 의해 인터럽트 요청을 처리하는 절차는 구체적으로: 타겟 vCPU가 호스트에 의해 스왑 인된 후에 그리고 타겟 vCPU가 게스트 모드로 트랩 인하기 전에, 호스트 내의 스케줄링 실행 유닛(2812)이 실행 엔티티 테이블(32) 내의 PENDING 비트를 판독하고, 타겟 vCPU에, 인터럽트 요청과 동일한 IRQ ID를 갖는 인터럽트 요청을 전송하여, 타겟 vCPU가 게스트 모드로 트랩 인한 후에 인터럽트 요청을 처리할 수 있게 하는 것을 포함한다. 하나 이상의 "타겟 vCPU"가 있을 수 있다. 인터럽트 요청이 하나의 vCPU에 의해서만 처리될 필요가 있다면, 인터럽트가 제1 타겟 vCPU에 전송된 후에, 다른 vCPU에 대응하는 PENDING 비트가 클리어되어, 트랩 인 이후에 다른 vCPU가 다시 인터럽트를 처리하는 것을 방지한다.

vCPU가 인터럽트 요청을 수신한 후에, vCPU는 인터럽트된 작업의 상태를 저장하고 일부 다른 동작들을 수행할 필요가 더 있을 수 있어서, 인터럽트 요청의 처리가 완료된 후에, vCPU는 인터럽트된 작업을 계속 수행하도록 복귀할 수 있다는 점에 유의해야 한다. 이들은 종래의 인터럽트 처리 프로세스에 속하고, 본 실시예에서 상세사항들은 여기서 설명되지 않는다.

일부 다른 실시예들에서, 현재의 vCPU가 질의를 통해 획득된 vCPU LIST에 포함되지 않는다고 결정하는 경우, 인터럽트 스케줄링 유닛(2911)은 실행 엔티티 테이블(32)을 직접 업데이트하여, vCPU LIST에 포함된 모든 vCPU들의 PENDING 비트들을 인터럽트 요청의 IRQ ID로 설정할 수 있다.

전술한 실시예들로부터, 인터럽트 수신 모드가 vCPU에 대해 구성되어, vCPU가 게스트 모드에서 APIC에 의해 전송된 거의 모든 인터럽트 요청들을 직접 수신할 수 있고, 다시 말해서, 인터럽트가 가상 머신의 게스트 인터럽트 관리 유닛(291)에 직접 전송될 수 있다는 것을 알 수 있다. 따라서, vCPU는, 애플리케이션 인터럽트 요청을 처리할 때, 전환, 예를 들어, 트랩 인/트랩 아웃될 필요가 없고, 애플리케이션 인터럽트 요청과 같은 서비스-계층 인터럽트 요청은 더 짧은 응답 및 처리 경로를 가지며, 애플리케이션 인터럽트 요청의 처리 지연이 감소한다. 본 출원에서 제공되는 방법은, 높은 서비스 용량 및 높은 동시성을 갖는 실행 환경에서의 서비스 인터럽트 요청의 초-저 응답 및 처리 지연 요건을 보장할 수 있고, 5G(5th-Generation)와 같은 초-저 지연에 기초할 필요가 있는 서비스 시나리오에 더 적용될 수 있다.

또한, 주입 채널(34)을 사용하여 호스트 계층에 비-서비스 계층 인터럽트 요청이 주입된다. 그 후 호스트 인터럽트 관리 유닛(281) 및/또는 호스트 내의 호스트 인터럽트 분배 유닛(282)은 처리 또는 추가 분배를 수행한다. 이것은 애플리케이션 인터럽트 요청의 효율적인 처리를 보장하고, 또한 다른 인터럽트 요청의 적시 처리를 보장한다.

또한, 인터럽트 요청을 수신하는 vCPU가 인터럽트 요청의 처리 엔티티가 아닐 때, 인터럽트 요청은 복수의 vCPU에 의해 공유되는 실행 엔티티 테이블(32)에 기록되고, 타겟 vCPU는 스왑 인된 후에 인터럽트 요청을 보고 처리할 수 있다. 이것은 VMM에 의해 인터럽트 요청을 포워딩하는 프로세스를 회피하고, 추가로 인터럽트 요청의 처리 효율을 향상시킨다. 또한, 일시적으로 서비스 불능인 vCPU는 인터럽트 요청을 수신 및 처리하는 것을 지연시킬 수 있다. 이것은 복수의 vCPU가 코어를 공유하고 vCPU가 코어를 배타적으로 점유하지 않는 시나리오에서 인터럽트 요청의 손실을 효과적으로 회피한다.

또한, 인터럽트 요청을 수신하는 vCPU가 인터럽트 요청의 처리 엔티티가 아닐 때, 실행 엔티티 테이블이 업데이트되고, 인터럽트 요청의 처리 엔티티의 스왑-인이 더 트리거될 수 있다. 이것은 인터럽트 요청의 처리 효율을 추가로 개선시킨다.

전술한 실시예의 단계 S702a에서 설명된 바와 같이, 인터럽트 요청을 수신한 후에, APIC는 특정 규칙에 따라 인터럽트 요청을 하나(또는 그 이상)의 물리적 코어에 전송하고, 물리적 코어 상에서 실행되는 vCPU가 인터럽트 요청을 처리한다. 특별한 규칙이 설정되지 않는 경우, 예를 들어, APIC가 인터럽트 요청을 랜덤하게 전송하거나 종래 기술에 따라 인터럽트 요청을 전송하는 경우, 초과 할당 시나리오에서(복수의 vCPU가 하나의 코어를 공유함), 인터럽트 요청이 인터럽트 요청을 처리할 수 없는 vCPU에 아마도 전송될 수 있다. 따라서, 이하의 실시예는 인터럽트 친화성을 구성하기 위한 방법을 제공하며, 따라서 전술한 단계들 S709b 및 S710b와 같은 단계들을 수행하지 않고 인터럽트를 처리할 수 있는 현재 서비스 가능인 vCPU에 최대 확률로 인터럽트 요청이 전송될 수 있다. 이것은 인터럽트 처리 효율을 더 개선한다.

인터럽트 제어기의 속성으로서, 인터럽트 친화성은 인터럽트 제어기에 저장되고, 인터럽트 요청과 물리적 코어 사이의 친화성을 나타낸다. 인터럽트 요청은 인터럽트 요청과 친화성을 갖는 물리적 코어에 인터럽트 제어기에 의해 전송된다. 구체적으로, 인터럽트 요청의 친화성은 인터럽트에 대응하는 친화성 리스트로서 구현될 수 있고, 친화성 리스트는 인터럽트 요청을 수신할 수 있는 모든 물리적 코어들의 CORE ID들을 포함한다. 예를 들어, X86 시스템에서, 하나의 io-APIC가 있을 때, 즉, 인터럽트 요청들을 생성하는 모든 하드웨어가 io-APIC에 접속될 때, 모든 인터럽트 요청들의 인터럽트 친화성들이 io-APIC에 저장되거나; 또는 복수의 주변 인터럽트 제어 컴포넌트가 있을 때, 상이한 하드웨어에 의해 생성된 인터럽트 요청들의 인터럽트 친화성들이 상이한 인터럽트 제어 컴포넌트들에 저장되고, 인터럽트 친화성들은 다음의 실시예들에서 설명되는 방식들에 따라 개별적으로 업데이트될 수 있다.

이 실시예에서, 인터럽트 친화성의 구성은 vCPU가 VMM에 의해 스왑 인된 후에 그리고 vCPU가 게스트 모드로 트랩 인되기 전에 수행되고; vCPU가 VMM에 의해 스왑 아웃될 때 수행된다. 구성은 호스트 인터럽트 관리 유닛(281) 내의 스케줄링 실행 유닛(2812)에 의해 구현될 수 있다. 도 9a 및 도 9b는 인터럽트 친화성을 구성하는 프로세스를 설명한다.

도 9a를 참조하면, vCPU가 스왑 인된 후에 그리고 vCPU가 게스트 모드로 트랩 인하기 전에, 스케줄링 실행 유닛(2812)은 VMM의 외부 인터럽트 응답을 디스에이블한다(S801a). 구체적으로, 외부 인터럽트를 디스에이블할 것을 지시하도록 호스트 모드에서 vCPU의 레지스터 비트를 수정하여, VMM이 인터럽트 요청을 수신 또는 처리할 수 없게 한다. 그 후, 함수를 호출하여 vCPU를 실행하는 물리적 코어의 CORE ID가 얻어진다(S802a). 예를 들어, 리눅스 시스템에서는, smp_processor_id() 함수를 호출하여 CORE ID가 획득된다. 본 명세서에서의 레지스터 비트는 ARM64 아키텍처에서 프로그램 상태 레지스터(current program status register, cprs)의 비트 i이고, X64 아키텍처에서 cli 명령어를 사용하여 구현된다.

분명히, vCPU가 스왑 인되기 때문에, 실행 엔티티 테이블은 또한 이 경우에 업데이트될 필요가 있다. 구체적으로, vCPU가 속하는 VM ID 및 vCPU ID와, CORE ID가 실행 엔티티 테이블에 기록된다(S803a).

실행 엔티티 테이블을 업데이트하는 것에 더하여, 인터럽트 친화성의 구성을 구현하기 위해, 스케줄링 실행 유닛(2812)은 먼저 vCPU ID에 기초하여 인터럽트 벡터 테이블로부터, vCPU에 의해 처리될 수 있는 모든 인터럽트 요청들(IPI가 설정될 필요가 없음)을 획득하고 나서, APIC에 액세스하고, APIC에서 인터럽트 요청들의 친화성들에 vCPU를 실행하는 물리적 코어(즉, 이전에 획득된 CORE ID)를 추가하여(S804a), APIC가 인터럽트 요청들을 수신한 후에 인터럽트 요청들을 물리적 코어에 전송할 수 있게 한다.

vCPU가 코어에 바인딩되는 시나리오에서, S804a에서의 친화성 구성 동작은 VM이 시작되고 vCPU가 처음으로 스왑 인될 때 수행될 수 있고, vCPU를 실행하는 물리적 코어가 고정되기 때문에, 인터럽트 제어기는 vCPU가 스왑 인될 때마다 수정될 필요가 없다는 점에 유의해야 한다.

vCPU가 트랩 인하기 전에, 스케줄링 실행 유닛(2812)은 추가로 실행 엔티티 테이블(32)에 대해 질의할 필요가 있다. PENDING 비트의 값이 -1이 아니라고 발견되면, 그것은 인터럽트 요청이 처리되지 않는다는 것을 나타낸다. 그 후, 스케줄링 실행 유닛(2812)은, PENDING 비트의 IRQ ID에 기초하여 vCPU에, 동일한 특성을 갖는 인터럽트 요청을 능동적으로 전송한다. 호스트 모드(또는 호스트)의 인터럽트 수신이 디스에이블되기 때문에, vCPU는 트랩 인 이후에만 인터럽트 요청을 수신하고 처리할 수 있다.

도 9a 및 전술한 내용은 vCPU가 트랩 인할 때 인터럽트 친화성이 업데이트될 필요가 있다는 것을 설명하였다. 대응하여, 인터럽트 친화성은 또한 vCPU가 스왑 아웃될 때 업데이트될 필요가 있다. 도 9b를 참조하면, vCPU가 트랩 아웃한 후에 그리고 vCPU가 VMM에 의해 스왑 아웃되기 전에, 스케줄링 실행 유닛(2812)은 vCPU를 실행하는 물리적 코어의 CORE ID를 획득하고(S801b), 그 다음에, vCPU의 vCPU ID에 대응하고 실행 엔티티 테이블(32) 내에 있는 CORE ID의 엔트리를 -1로 업데이트한다(S802b). 실행 엔티티 테이블(32)을 업데이트하는 것에 더하여, 인터럽트 친화성의 구성이 또한 업데이트될 필요가 있다(S803b). 구체적으로, 스케줄링 실행 유닛(2812)은 먼저 vCPU ID에 기초하여 인터럽트 벡터 테이블(31)로부터 vCPU에 의해 처리될 수 있는 모든 인터럽트 요청들(IPI가 설정될 필요가 없음)을 획득하고, 그 다음에 APIC에 액세스하고, APIC 내의 인터럽트 요청들의 친화성들로부터 vCPU를 실행하는 물리적 코어를 제거한다. 인터럽트 요청의 친화성 리스트가 비어 있는 경우, 친화성 리스트는 -1로 채워진다. 이것은 모든 물리적 코어들이 인터럽트 요청을 수신할 수 있다는 것을 의미한다. 다른 실시예에서, 단계 S801b는 대안적으로 수행되지 않을 수 있다. 수정될 CORE ID는 또한 일부 방식들로 vCPU ID를 사용하여 발견될 수 있다.

vCPU가 코어에 바인딩되는 시나리오에서, S803b에서의 동작은 VM이 종료한 후에 한번만 수행될 수 있다는 점을 유의해야 한다.

전술한 방법을 사용하여 친화성이 구성된 후에, vCPU들 사이에 일부 인터럽트 요청들을 분배할 필요성이 제거된다. 따라서, vCPU가 코어에 바인딩되지 않는 시나리오에서, 인터럽트 요청이 최대 확률로 타겟 vCPU에 히트(hit)할 수 있어, 인터럽트 요청을 처리하기 위한 시간을 더 단축시키고 인터럽트 지연을 감소시킨다.

도 8b의 전술한 실시예를 참조하면, 인터럽트 친화성이 설정된 후에, 현재의 vCPU가 vCPU LIST에 포함되지 않는다고 결정하면(S706b), 인터럽트 스케줄링 유닛(2911)은 모든 vCPU들이 서비스 불능이기 때문에 단계 S709b를 수행할 필요가 없다. 단계 S710도 수행될 필요가 없다. 인터럽트 스케줄링 유닛(2911)은 vCPU LIST 내의 모든 vCPU들이 서비스 불능인 경우에 기초하여 직접 처리를 계속할 수 있다.

전술한 실시예에서, 인터럽트 요청을 수신하는 vCPU가 인터럽트 요청의 처리 엔티티가 아니고, 처리 엔티티들 중 어느 것도 서비스 가능이 아닐 때, 인터럽트 요청을 처리하기 위한 타겟 vCPU가 인터럽트 요청의 처리 엔티티들로부터 결정될 필요가 있다. 다음의 실시예는 타겟 vCPU를 결정하는 방법 및 타겟 vCPU가 결정된 후에 타겟 vCPU가 인터럽트 요청을 처리하는 방법을 상세히 설명한다. 이 실시예에서 제공되는 방법은 인터럽트 친화성이 구성되지 않는 실시예에 적용될 수 있거나, 또는 인터럽트 친화성이 구성되는 실시예에 적용될 수 있다.

표 1 및 표 2는 각각 인터럽트 요청의 우선순위 및 vCPU의 우선순위를 기록한다. 인터럽트 요청을 수신하는 vCPU가 인터럽트 요청의 처리 엔티티가 아니라고 결정될 때, 인터럽트 스케줄링 유닛(2911)은 표 1에 질의하여 인터럽트 요청의 우선순위를 획득한다.

이 실시예에서, 인터럽트 요청의 우선순위의 값이 0 이상이면, 서비스 가능 vCPU를 선점할지를 결정하기 위해 인터럽트 요청의 우선순위가 서비스 가능 vCPU의 우선순위와 비교될 필요가 있다. 값이 음수일 때, 인터럽트 요청의 우선순위는 서비스 가능 vCPU의 우선순위와 비교될 필요가 없다. 구체적으로, 값이 -1일 때, 서비스 가능 vCPU는 결코 선점되지 않거나; 또는 값이 -2일 때, 현재 인터럽트 요청을 수신하고 있는 현재의 vCPU가 직접 선점된다. 인터럽트 우선순위가 디폴트로 -2이다. 우선순위를 설정하고 결정하는 많은 방식들이 존재하고, 그 방식들은 본 출원에서 일일이 열거되지 않는다. 다음의 방법은 단지 이러한 방식을 예로 사용하여 설명된다.

또한, 여기서 vCPU의 우선순위는 vCPU 상의 현재의 작업의 우선순위이다. 초기화 동안, 인터럽트 스케줄링 유닛(2911)은 게스트 운영 체제의 작업 핸드오버 HOOK을 등록하고, 게스트 운영 체제는 작업 핸드오버 시에 HOOK을 실행한다. HOOK은 게스트 운영 체제의 스왑-인될 작업의 우선순위를 표 2의 PRIORITY로 업데이트하는데 사용된다.

방법의 상세한 설명들은 다음과 같다.

인터럽트 요청의 우선순위가 -1일 때, 이것은 인터럽트 요청의 우선순위가 매우 낮고, 인터럽트 요청의 우선순위가 서비스 가능 vCPU의 우선순위와 비교되지 않고, PENDING 비트가 전술한 바와 같이 직접 기록될 수 있다는 것을 나타낸다.

인터럽트 요청의 우선순위가 0 이상이고, 모든 서비스 가능 vCPU들의 우선순위들이 인터럽트 요청의 우선순위 이상이라고 결정되면, 인터럽트 스케줄링 유닛(2911)은, 표 1에 기초하여, 인터럽트 요청에 대응하는 vCPU LIST 내의 모든 vCPU들을 타겟 vCPU들로서 사용하고, 그 다음에 타겟 vCPU들에 대응하고 표 2에 있는 PENDING 비트들을 인터럽트 요청의 IRQ ID로 수정한다. 이러한 방식으로, vCPU LIST 내의 임의의 vCPU가 트랩 인하기 전에, 스케줄링 실행 유닛(2812)은, 질의를 통해, 대응하는 PENDING 비트의 인터럽트 요청이 처리되지 않은 것을 발견하고 나서, 동일한 인터럽트 요청을 vCPU에 전송할 수 있다. vCPU는 트랩 인 후에 인터럽트 요청을 수신하고 처리할 수 있다. 인터럽트 요청이 복수의 코어에 의해 처리될 필요가 있는 인터럽트 요청이 아닌 한, 인터럽트 요청이 하나의 vCPU에 전송되는 경우, 다른 vCPU의 PENDING 비트가 클리어될 필요가 있다. 이것은 모든 vCPU들이 인터럽트 요청을 반복적으로 처리하는 것을 방지한다.

인터럽트 요청의 우선순위가 0 이상이고, 임의의 vCPU의 우선순위가 인터럽트 요청의 우선순위보다 낮다고 결정되면, 인터럽트 스케줄링 유닛(2911)은 가장 낮은 우선순위를 갖는 vCPU를 "중계 vCPU"로서 선택하고, 인터럽트 요청에 대응하는 vCPU LIST로부터 가장 높은 우선순위를 갖는 vCPU를 타겟 vCPU로서 선택하고, 타겟 vCPU에 대응하고 표 2에 있는 PENDING 비트를 인터럽트 요청의 IRQ ID로 수정한다. 그 후, 인터럽트 스케줄링 유닛(2911)은 IPI 인터럽트를 중계 vCPU에 전송하도록 인터럽트 분배 유닛(2912)에 지시하고(다시 말해서, 현재의 vCPU가 IPI 인터럽트를 중계 vCPU에 전송함), 여기서 IPI 인터럽트는 타겟 vCPU의 vCPU ID를 운반한다. IPI 인터럽트는 처리될 인터럽트 요청의 IRQ ID를 추가로 운반할 수 있지만, 이것은 필수적이지 않으며, 그 이유는 처리될 인터럽트 요청의 IRQ ID가 전술한 단계에서 타겟 vCPU의 PENDING 비트에 기록되었기 때문이다. IRQ ID가 방법의 전술한 단계에서 기록되지 않은 경우, 스왑-인된 타겟 vCPU가 타겟 vCPU가 인터럽트 요청을 처리할 필요가 있다는 것을 알도록, IRQ ID가 여기서 운반될 필요가 있다.

중계 vCPU가 서비스 가능 vCPU로부터 선택되기 때문에, 중계 vCPU는 현재 서비스 가능이다. IPI 인터럽트를 수신한 후에, 중계 vCPU는 IPI 인터럽트에 대응하는 ISR을 실행한다(ISR은 또한 표 1에 등록되고, 인터럽트 트리거 유닛(2913)에 의해 등록될 수 있다). IPI 인터럽트에 대응하는 ISR의 구현은 다음과 같다: IPI 인터럽트 내에 운반되는 타겟 vCPU의 vCPU ID가 (이 실시예에서의 경우와 같이) 중계 vCPU의 vCPU ID와 상이하다고 결정될 때, 주입 채널(32)을 사용하여 호스트의 인터럽트 수신 유닛(2813) 상에서 역방향 주입(reverse injection)이 수행되고, 여기서 파라미터는 타겟 vCPU의 vCPU ID이다(선택적으로, 파라미터는 IRQ ID를 추가로 포함할 수 있다). 주입 후에, 중계 vCPU는 트랩 아웃한다. 주입을 수신한 후에, 인터럽트 수신 유닛(2813)은, 주입이 타겟 vCPU의 vCPU ID를 운반한다고 결정하고(인터럽트 요청의 처리 엔티티가 호스트가 아님을 나타냄), 따라서 타겟 vCPU의 vCPU ID를 VMM에 있고 vCPU 스케줄링을 수행하기 위해 사용되는 스케줄러에 전송하여, VMM이 타겟 vCPU를 스왑 인하고 중계 vCPU를 스왑 아웃하게 한다.

중계 vCPU가 본 실시예에서 가장 낮은 우선순위를 갖는 vCPU이기 때문에 중계 vCPU는 여기서 스왑 아웃되고, 중계 vCPU를 스왑 아웃하는 것은 현재의 작업에 대한 인터럽트 요청의 영향을 최소화할 수 있다는 점에 유의해야 한다. 다른 실시예에서, 다른 vCPU는 상황에 따라 스왑 아웃될 수 있다. 이것은 본 출원에서 제한되지 않는다.

타겟 vCPU가 스왑 인된 후에 그리고 타겟 vCPU가 게스트 모드로 트랩 인하기 전에, 스케줄링 실행 유닛(2812)은 실행 엔티티 테이블(32) 내의 PENDING 비트에 대해 질의하고, 타겟 vCPU가 처리되지 않은 인터럽트 요청을 갖는다고 결정하고, 타겟 vCPU에, 처리되지 않은 인터럽트 요청과 동일한 인터럽트 요청을 능동적으로 전송하여, 타겟 vCPU가 게스트 모드로 트랩 인한 후에 인터럽트 요청을 처리하게 한다.

인터럽트 요청의 우선순위가 -2일 때, 이것은 인터럽트 요청이 매우 긴급하고, 인터럽트 요청의 우선순위도 vCPU의 우선순위와 비교될 필요가 없다는 것을 나타낸다. 인터럽트 스케줄링 유닛(2911)은 즉시 타겟 vCPU로서 vCPU LIST로부터 가장 높은 우선순위를 갖는 vCPU를 선택하고(또는 vCPU를 랜덤하게 선택하고), 그 다음에 IPI에 대응하고 표 1에 있는 ISR(타겟 vCPU의 vCPU ID를 운반함)을 호출한다. ISR의 특정 구현은 다음과 같다: 타겟 vCPU의 vCPU ID가 현재의 vCPU의 것과 상이하다고 결정되면, 주입 채널(32)을 사용하여 호스트의 인터럽트 수신 유닛(2813) 상에서 예비 주입(reserve injection)이 수행되고, 여기서 파라미터는 타겟 vCPU ID이다. 주입 후에, 현재의 vCPU는 즉시 트랩 아웃한다. 역방향 주입을 수신한 후에, 인터럽트 수신 유닛(2813)은, 주입이 타겟 vCPU의 vCPU ID를 운반한다고 결정하고(인터럽트 요청의 처리 엔티티가 호스트가 아님을 나타냄), 타겟 vCPU의 vCPU ID를 VMM에 있고 vCPU 스케줄링을 수행하는데 사용되는 스케줄러에 전송하여, VMM이 타겟 vCPU를 스왑 인하고 현재의 vCPU를 스왑 아웃하게 한다. 전술한 방법에서와 유사하게, IRQ ID가 운반될 수 있거나, 운반되지 않을 수 있다.

모든 서비스 가능 vCPU 상의 현재의 작업들의 우선순위들이 인터럽트 요청의 우선순위 이상일 때, 일시적으로, 이러한 vCPU들 중 어느 것도 스왑 아웃될 수 없다는 것을 알 수 있다. 현재의 작업들의 실행에 대한 영향을 피하기 위해, vCPU의 스왑-아웃 및 스왑-인은 능동적으로 트리거될 수 없다. 따라서, 인터럽트 요청이 먼저 기록되고, 적절한 시간에 타겟 vCPU들 중 하나가 스왑 인된 후에 처리된다. 인터럽트 요청의 우선순위가 비교적 높거나 매우 높을 때, 낮은 우선순위를 갖는 vCPU가 능동적으로 선점될 수 있다. 이러한 방식으로, 인터럽트 요청의 처리는 가속화되면서, vCPU의 현재의 작업에 대한 영향은 최소화된다. 방법을 구현하는 프로세스에서, 전체 시스템 내의 모든 vCPU들의 상태들 및 우선순위들은 실행 엔티티 테이블(32)을 사용하여 학습된다. 따라서, 이러한 관리는 시스템 레벨에 있고, 시스템의 정상 실행을 어느 정도 보장할 수 있다.

전술한 실시예는 하나의 vCPU에 의해 다른 vCPU에 IPI 인터럽트를 전송하는 것을 설명하였다. 다음의 실시예는 하나의 vCPU가 IPI 인터럽트를 다른 vCPU에 전송하는 방법을 상세히 설명한다. 2개의 vCPU는 동일한 VM에 위치할 수 있거나, 상이한 VM들에 위치할 수 있다. 설명의 용이함을 위해, 2개의 vCPU는 다음의 실시예에서 vCPU A 및 vCPU B로 지칭된다. 전술한 실시예에서 IPI 인터럽트가 사용되는 부분에 대해서는, 대응하여 이 실시예를 참조한다.

vCPU A가 게스트 모드에 있으면, vCPU A가 IPI 인터럽트를 vCPU B에 전송할 필요가 있다고 결정한 후에, vCPU A는 vCPU A가 속하는 VM 내의 인터럽트 분배 유닛(2912)에서 IPI 전송 기능을 호출한다. 인터럽트 분배 유닛(2912)은 스케줄링을 수행하도록 인터럽트 스케줄링 유닛(2911)에 지시한다. 인터럽트 스케줄링 유닛(2911)은, vCPU B가 서비스 가능인지를 결정하기 위해, vCPU B에 대응하는 CORE ID 엔트리에 대해 실행 엔티티 테이블(32)을 검색한다.

vCPU B가 서비스 가능이라고 결정하는 경우, 인터럽트 스케줄링 유닛(2911)은 vCPU B를 실행하는 물리적 코어에 IPI 인터럽트를 전송하도록 APIC를 직접 동작시킨다. 전술한 실시예에서 설명된 중계 vCPU는 서비스 가능 vCPU들로부터 선택된 vCPU이고, 따라서 이 단계에 적용가능하다. 예를 들어, X86 시스템에서, 인터럽트 스케줄링 유닛(2911)은 vCPU A를 실행하는 물리적 코어에 대응하는 local-APIC를 직접 동작시켜, vCPU B를 실행하는 물리적 코어에 대응하는 local-APIC에 IPI 인터럽트를 전송한다.

vCPU B가 서비스 불능이라고 결정되면, IPI 인터럽트는 실행 엔티티 테이블(32) 내의 vCPU B-관련된 PENDING 비트에 기록되어, vCPU B가 스왑 인된 후에 IPI 인터럽트를 처리하게 한다. 구체적으로, vCPU B가 스왑 인된 후에 그리고 vCPU B가 트랩 인하기 전에, vCPU B가 PENDING 비트에 대해 질의하고, 이어서 동일한 IPI 인터럽트를 vCPU B 자체에 전송하고, 트랩 인 후에 IPI 인터럽트를 처리한다.

IPI 인터럽트 요청은 특별한 인터럽트이지만, IPI 인터럽트 요청의 처리 절차는 전술한 실시예에서의 인터럽트 요청과 부분적으로 유사하다는 점에 유의해야 한다. 따라서, 전술한 실시예가 참조될 수 있다. 세부사항들은 여기서 다시 설명되지 않는다.

실행 엔티티 테이블은 상이한 vCPU들 사이에서 공유되고, vCPU는 전술한 실시예에서 초기화 동안 구성되어, vCPU가 인터럽트 제어기를 직접 동작시켜, 트랩 아웃 없이 IPI 인터럽트를 전송할 수 있게 하고, IPI 인터럽트 처리를 가속화시킨다.

전술한 단계들은 임의의 IPI 인터럽트 요청에 적용될 수 있다.

또한, 전송된 IPI가 전술한 실시예에서 사용되는 IPI와 동일한 타입인 경우, IPI는 IRQ ID를 운반하거나, IRQ ID와 vCPU ID 둘 다를 운반할 수 있다. 운반된 vCPU ID는 반드시 vCPU B의 ID일 필요는 없을 수 있다. IRQ ID는, IPI가 IRQ ID에 의해 표시된 인터럽트 요청을 처리하도록 다른 vCPU에 지시하는 데 사용된다는 것을 의미한다. vCPU ID는 인터럽트 요청을 처리할 필요가 있는 vCPU(즉, 전술한 실시예에서의 타겟 vCPU)를 표시한다.

대응하여, IPI 인터럽트를 수신한 후에, vCPU B는 표 1에 질의하여 IPI 인터럽트에 대응하는 ISR을 호출하여 IPI 인터럽트를 처리한다. ISR의 구체적인 구현은 다음과 같다: 운반된 vCPU ID가 vCPU B의 ID와 동일하거나 또는 vCPU ID가 존재하지 않는다고 결정되면(vCPU B가 인터럽트 요청의 처리 엔티티임을 나타냄), vCPU B는 표 1에 질의하여 운반된 IRQ ID에 대응하는 ISR을 호출하여 인터럽트 요청을 처리하거나; 또는 운반된 vCPU ID가 vCPU B의 ID와 상이하다고 결정되면, vCPU B는 주입 채널(34)을 사용하여 타겟 vCPU의 vCPU ID를 호스트에 전송한다. 그 다음, vCPU B는 트랩 아웃한다. 호스트는 vCPU 스케줄링을 수행하기 위해 사용되고 VMM 내에 있는 스케줄러에 vCPU ID를 전송하여, VMM이 vCPU ID에 의해 표시된 vCPU를 스왑 인하게 한다. 특정 프로세스에 대해서는, 우선순위 구성을 포함하는 전술한 실시예를 참조한다.

하나의 vCPU가 트랩 아웃 없이 IPI 인터럽트를 다른 vCPU에 전송할 것으로 예상되는 경우, 호스트는 vCPU에 대한 인터럽트 제어기 동작 모드를 구성할 필요가 있어, vCPU가 트랩 아웃 없이 IPI 인터럽트를 다른 vCPU에 전송하도록 인터럽트 제어기를 동작시킬 수 있다. 구체적인 구성 방법에 대해서는, 전술한 실시예를 참조한다.

인터럽트 요청의 타입이 복수의 vCPU에 의해 처리될 필요가 있고, 구체적으로는, 표 1에서 TYPE=1로 표현될 수 있다. 전형적인 예들로는, ARM64 아키텍처에서 클록 인터럽트 및 N2N 주변 인터럽트가 있다. 물리적 CPU가 초과 할당되는 경우, 이러한 타입의 인터럽트는 인터럽트 요청을 처리할 필요가 있는 각각의 vCPU에 도달하지 않을 수 있는데, 그 이유는 이들 vCPU들이 동시에 서비스 가능이 아닐 수 있기 때문이다. 이 경우, 이 인터럽트는 "복제(replication)"의 방식으로 포워딩될 필요가 있다. 다음의 실시예는 본 출원에서 제공되는 "인터럽트 복제" 방법을 설명한다.

도 10에 도시된 바와 같이, 호스트 및 가상 머신에 의해 공유되는 vCPU 대기열(35)이 각각의 물리적 코어에 대해 도입된다. 물리적 코어의 vCPU 대기열(35)은 물리적 코어 상에서 이전에 실행되는 vCPU를 포함한다. vCPU가 VMM에 의해 물리적 코어로부터 스왑 아웃되는 경우, 스케줄링 실행 유닛(2812)은 vCPU를 vCPU 대기열(35)에 추가한다. vCPU가 VMM에 의해 실행을 위한 다른 물리적 코어로 스케줄링되는 경우, 스케줄링 실행 유닛(2812)은 vCPU 대기열(35)로부터 vCPU를 삭제한다.

먼저, 초기화가 수행된다. 구체적으로는, 호스트 인터럽트 관리 유닛(281)의 초기화 동안, 각각의 물리적 코어에 대해 대응하는 vCPU 대기열(35)이 생성된다. 이 대기열들은 호스트 및 가상 머신에 의해 공유될 수 있는 저장 영역에 저장된다. 각각의 vCPU는, vCPU가 처리할 것으로 예상되는 TYPE=1 인터럽트 요청을 인터럽트 벡터 테이블(31)에 등록한다. 상세한 등록 프로세스에 대해서는, 전술한 실시예에서의 응용에 의해 인터럽트 요청을 등록하는 프로세스를 참조한다.

게스트 모드에서의 vCPU에 대해, vCPU에 의해 처리될 필요가 있는 인터럽트 요청을 수신한 후에, vCPU는 인터럽트 요청을 직접 처리할 수 있다(새로운 타임아웃 대기(new timeout waiting)를 개시하도록 물리적 인터럽트 제어기를 직접 동작시키는 것을 포함함). 처리 방법에 대해서는, 전술한 실시예를 참조한다. 추가로, 도 11을 참조하면, 이 실시예에서, 인터럽트 스케줄링 유닛(2911)은 추가로 인터럽트 요청의 IRQ ID에 기초하여 인터럽트 벡터 테이블 내의 TYPE 엔트리에 대해 질의하고(S901), TYPE 엔트리의 값이 1인지를 결정(S902)할 필요가 있다. 인터럽트 요청이 복수의 vCPU에 의해 처리될 필요가 있다고 결정될 때, vCPU를 실행하는 물리적 코어의 vCPU 대기열(35) 및 인터럽트 벡터 테이블(31)이 검색되고(S903), vCPU 대기열(35) 내의 vCPU가 IRQ ID에 대응하는 vCPU LIST 내에 있는지가 순차적으로 결정된다(S904). vCPU가 vCPU LIST 내에 있는 경우, vCPU에 대응하는 PENDING 비트가 실행 엔티티 테이블(32)에 기록되고, 중계 vCPU가 결정되고, IPI 인터럽트가 중계 vCPU에 전송되어 최종적으로 VMM이 vCPU를 스케줄링하는 것을 가능하게 하고, vCPU는 스케줄링되고 스왑 인된 후에 인터럽트 요청을 처리한다(S905). vCPU의 스왑-인을 트리거하는 것에 관한 더 상세한 내용에 대해서는, 전술한 실시예를 참조한다.

각각의 물리적 CPU에 대해 교차층 공유된 vCPU 대기열(cross-layer shared vCPU queue)을 설정함으로써 복수의 vCPU에 의해 처리될 필요가 있는 인터럽트 요청의 인터럽트 처리 지연이 감소할 수 있다. 클록 인터럽트가 예로서 사용된다. 클록 인터럽트는 운영 체제에 대한 특수하고 매우 중요한 인터럽트이다. 클록 인터럽트가 게스트 모드에서 vCPU에 의해 직접 수신될 수 있다면, 클록 인터럽트의 응답 시간이 크게 단축될 수 있고, 클록 인터럽트의 정밀도도 크게 개선될 수 있다. 예를 들어, 현재, vCPU가 보통 인터럽트 요청을 수신하기 위해 트랩 아웃 및 트랩 인할 필요가 있고, 인터럽트 지연이 10㎲ 초과이다. 이것은 5㎲ 클록 인터럽트를 설정(5㎲의 주파수에서 300ns를 소비하는 이벤트와 같은 경량 이벤트를 수행)하는 것이 불가능하다는 것을 의미한다. 본 발명의 실시예들에서 제공되는 방법에 따르면, 클록 인터럽트가 게스트 모드에서 직접 수신될 수 있고, 복수의 vCPU가 클록 인터럽트를 주기적으로 수신 및 처리할 수 있다. 이것은 클록 인터럽트의 지연을 크게 감소시키고, 설정을 가능하게 한다.

전술한 실시예들 중 일부에서, VMM의 인터럽트 응답은 vCPU가 스왑 인될 때마다 디스에이블된다. 그러나, 일부 복잡한 가상화된 컴퓨터 시스템에서, 인터럽트 응답은 디스에이블되도록 허용되지 않는다. 다음의 실시예는 이러한 시스템이 애플리케이션 인터럽트 요청의 처리를 가속화하기 위한 보상 메커니즘을 제공한다.

도 12를 참조하면, 인터럽트 매핑 테이블(284) 및 VMM 인터럽트 서비스 루틴(2814)이 호스트 계층에 추가된다. VMM 인터럽트 서비스 루틴(2814)은 인터럽트 매핑 테이블(284)에 등록되어, 애플리케이션 인터럽트 요청을 수신한 후에, VMM이 인터럽트 매핑 테이블(284)을 검색함으로써 VMM 인터럽트 서비스 루틴(2814)을 찾을 수 있게 한다.

호스트 모드(예를 들어, vCPU가 예외로 인해 트랩 아웃됨)에서, VMM 또는 호스트의 다른 코드는 애플리케이션 인터럽트 요청을 수신하고, 애플리케이션 인터럽트 요청은 그 다음에 호스트 인터럽트 분배 유닛(282)에 들어간다. 호스트 인터럽트 분배 유닛(282)은 인터럽트 매핑 테이블(284)에 질의하여, 애플리케이션 인터럽트 요청에 대응하는 처리 함수, 즉, VMM 인터럽트 서비스 루틴(2814)을 호출한다. 이어서, VMM 인터럽트 서비스 루틴(2814)은 인터럽트 벡터 테이블(31) 및 실행 엔티티 테이블(32)에 기초하여 다음의 동작들을 수행한다:

애플리케이션 인터럽트 요청에 대응하는 vCPU LIST 내의 vCPU들 중 어느 것도 서비스 가능이 아닌 경우, 전술한 실시예들에서 PENDING 비트를 수정하는 처리 방식을 참조한다. 모든 vCPU들의 PENDING 비트들이 수정될 수 있거나, 전술한 실시예들을 참조하여 인터럽트 우선순위에 기초하여 처리가 수행될 수 있다. 이러한 방식으로, vCPU는 스왑 인된 후에 인터럽트 요청을 처리할 수 있다. 관련 vCPU가 서비스 가능인 경우, 인터럽트 처리를 수행하기 위해 전술한 실시예에 따라 서비스 가능 vCPU에 IPI가 전송될 수 있다.

본 기술분야의 통상의 기술자는 전술한 실시예들에서 VMM 인터럽트 서비스 루틴(2814)의 기능들이 게스트 인터럽트 관리 유닛(291)의 일부 기능들과 유사하다는 것을 이해할 수 있다. 따라서, 더 구체적인 구현들에 대해서는, 전술한 실시예들을 참조한다. 인터럽트 벡터 테이블의 구조 및 타입은 인터럽트 매핑 테이블의 것들과 동일할 수 있다. 본 출원에서, 2개의 테이블은 2개의 테이블을 구별하기 위해 상이하게 명명된다. 용어 "벡터" 및 "매핑"은 제한을 구성하는 것으로 의도되지 않는다.

VMM 인터럽트 서비스 루틴(2814)은 호스트의 인터럽트 매핑 테이블(284)에 등록되고, VMM 인터럽트 서비스 루틴(2814)의 기능들은 애플리케이션 인터럽트 요청이 수신될 때 구현되어, 애플리케이션 인터럽트 요청이 호스트 모드에서 수신되더라도, vCPU는, 트랩 인 없이, 다른 실시예들과 유사한 본 발명의 메커니즘을 사용하여, 애플리케이션 인터럽트 요청을 처리를 위해 대응하는 vCPU에 안내할 수 있다. 이러한 방식으로, 본 출원에서 제공되는 해결책들은 인터럽트 처리가 명확히 호스트 모드에서 인에이블될 필요가 있는 복잡한 컴퓨터 시스템에 적용될 수 있다. 분명히, 게스트 운영 체제 인터럽트 요청의 처리는 또한 동일한 효과를 달성할 수 있다.

네트워크 기술들의 발전으로, 5G는 미래의 주류 기술이 되고 있다. 5G 시나리오에서, 네트워크 디바이스의 서비스 인터럽트 지연에 더 엄격한 요건이 부과된다. 본 출원에서 제공되는 방법은 높은 서비스 용량 및 높은 동시성을 갖는 실행 환경에서 서비스 인터럽트 요청의 초-저 응답 및 처리 지연을 보장할 수 있고, 5G와 같은, 시스템 지원으로서 초-저 지연을 사용하는 서비스 시나리오에 더 적용될 수 있다.

전술한 실시예들에서의 유닛 또는 모듈 분할은 예일 뿐이고, 유닛들의 설명된 기능들은 설명을 위한 예들일 뿐이고, 본 출원은 이에 제한되지 않는다는 점에 유의해야 한다. 프로그램 설계자는 요건에 따라 2개 이상의 유닛의 기능들을 조합하거나, 유닛의 기능을 분할하여 더 미세한 입도의 유닛들을 획득할 수 있고, 다른 변형 방식을 사용할 수 있다.

전술한 실시예들에서 설명된 동일하거나 유사한 부분에 대해서는, 각각의 실시예를 참조한다.

설명된 장치 실시예들은 예들일 뿐이다. 별도의 부분들로서 설명된 유닛들은 물리적으로 분리될 수 있거나 그렇지 않을 수 있으며, 유닛들로서 도시된 부분들은 물리적 유닛들일 수 있거나 아닐 수 있으며, 한 위치에 위치할 수 있거나 복수의 네트워크 유닛 상에 분산될 수 있다. 모듈들의 일부 또는 전부는 실시예들의 해결책들의 목적을 달성하기 위한 실제의 필요성에 따라 선택될 수 있다. 또한, 본 발명에 의해 제공되는 장치 실시예들의 첨부 도면들에서, 모듈들 사이의 접속 관계들은 모듈들이 서로 통신 접속들을 갖는다는 것을 나타내고, 이것은 구체적으로 하나 이상의 통신 버스 또는 신호 케이블들로서 구현될 수 있다. 본 기술분야의 통상의 기술자는 창의적인 노력들 없이도 본 발명의 실시예들을 이해하고 구현할 수 있다.

전술한 실시예들의 설명들에 따르면, 본 기술분야의 통상의 기술자는 본 발명의 실시예들에서 설명된 도면 장치가 소프트웨어 및 요구되는 범용 하드웨어에 의해 구현될 수 있거나, 명백히 주문형 집적 회로, 전용 CPU, 전용 메모리, 및 전용 컴포넌트와 같은 전용 소프트웨어에 의해 구현될 수 있다는 것을 분명히 이해할 수 있다. 일반적으로, 컴퓨터 프로그램에 의해 수행될 수 있는 임의의 기능들은 대응하는 하드웨어를 사용하여 용이하게 구현될 수 있다. 또한, 동일한 기능을 달성하기 위해 사용되는 특정 하드웨어 구조는 다양한 형태들, 예를 들어, 아날로그 회로, 디지털 회로, 또는 전용 회로의 형태로 될 수 있다.

전술한 설명들은 본 발명의 일부 특정 실시예들일 뿐이고, 본 발명의 보호 범위는 이에 제한되지 않는다.

Claims

가상화된 디바이스(virtualized device)로서,
상기 가상화된 디바이스는 하드웨어 계층, 호스트, 및 가상 컴퓨터를 포함하고; 상기 가상 컴퓨터는 상기 가상 컴퓨터를 서빙(serving)하는 가상 프로세서를 포함하고;
상기 호스트는 상기 하드웨어 계층으로부터 인터럽트 요청을 수신할 수 있도록 상기 가상 컴퓨터의 상기 가상 프로세서를 구성하도록 구성되고;
상기 가상 컴퓨터는 상기 하드웨어 계층으로부터 인터럽트 요청을 수신하고, 정보에 기초하여 상기 수신된 인터럽트 요청의 처리 엔티티를 결정하도록 구성되고; 상기 수신된 인터럽트 요청의 상기 처리 엔티티가 상기 가상 컴퓨터의 현재의 가상 프로세서를 포함할 때, 상기 가상 컴퓨터는 상기 정보에 기초하여 상기 수신된 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 호출하여 상기 인터럽트 요청을 처리하고, 상기 정보는 상기 인터럽트 요청, 상기 처리 엔티티, 및 상기 인터럽트 서비스 루틴 사이의 대응관계를 포함하는, 가상화된 디바이스.
제1항에 있어서,
상기 호스트는 물리적 인터럽트 제어기를 동작시킬 수 있도록 상기 가상 컴퓨터의 상기 가상 프로세서를 구성하도록 추가로 구성되고;
상기 가상 컴퓨터는: 상기 수신된 인터럽트 요청의 상기 처리 엔티티가 다른 가상 프로세서이고 상기 다른 가상 프로세서 중 적어도 하나가 서비스 가능(in service)이라고 결정될 때, 상기 다른 가상 프로세서의 하나 이상의 서비스 가능 가상 프로세서에 IPI 인터럽트 요청을 전송하도록 상기 물리적 인터럽트 제어기를 동작시키도록 추가로 구성되고, 상기 IPI 인터럽트 요청은 상기 수신된 인터럽트 요청의 식별자를 운반하고, 상기 다른 가상 프로세서는 상기 가상 컴퓨터의 상기 현재의 가상 프로세서를 포함하지 않는, 가상화된 디바이스.
제1항 또는 제2항에 있어서,
상기 가상 컴퓨터는: 상기 수신된 인터럽트 요청의 상기 처리 엔티티가 다른 가상 프로세서이고 상기 다른 가상 프로세서 중 어느 것도 서비스 가능이 아니라고 결정될 때, 상기 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하고, 상기 수신된 인터럽트 요청의 식별자를 상기 현재의 가상 프로세서와 상기 호스트 둘 다에 액세스가능한 저장 영역에 기록하도록 추가로 구성되고, 상기 다른 가상 프로세서는 상기 가상 컴퓨터의 상기 현재의 가상 프로세서를 포함하지 않고;
상기 호스트는: 상기 타겟 가상 프로세서가 스왑 인(swap in)된 후에 그리고 상기 타겟 가상 프로세서가 트랩 인(trap in)하기 전에, 상기 저장 영역에 기록된 상기 식별자에 기초하여 상기 타겟 가상 프로세서에 인터럽트 요청을 전송하여, 상기 타겟 가상 프로세서가 트랩 인 후에 상기 인터럽트 요청을 처리하게 하도록 추가로 구성되는, 가상화된 디바이스.
제3항에 있어서,
상기 호스트는 상기 인터럽트 요청의 우선순위를 설정하고, 상기 우선순위를 상기 호스트와 상기 가상 컴퓨터 둘 다에 액세스가능한 저장 영역에 기록하도록 추가로 구성되고;
상기 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하는 양태에서, 상기 가상 컴퓨터는 상기 수신된 인터럽트 요청의 우선순위 및 상기 가상 프로세서의 우선순위에 기초하여 상기 타겟 가상 프로세서를 결정하도록 구체적으로 구성되고, 상기 가상 프로세서의 우선순위는 모든 가상 컴퓨터들에 액세스가능한 저장 영역에 저장되는, 가상화된 디바이스.
제4항에 있어서,
상기 수신된 인터럽트 요청의 우선순위 및 상기 가상 프로세서의 우선순위에 기초하여 상기 타겟 가상 프로세서를 결정하는 양태에서, 상기 가상 컴퓨터는:
상기 수신된 인터럽트 요청의 식별자에 기초하여, 상기 호스트와 상기 가상 컴퓨터 둘 다에 액세스가능한 저장 영역을 검색하여, 상기 수신된 인터럽트 요청의 우선순위를 획득하고; 상기 수신된 인터럽트 요청의 우선순위를 모든 서비스 가능 가상 프로세서들의 우선순위들과 비교하고; 상기 모든 서비스 가능 가상 프로세서들의 우선순위들이 상기 수신된 인터럽트 요청의 우선순위 이상인 경우, 상기 수신된 인터럽트 요청을 처리할 수 있는 모든 가상 프로세서들을 상기 타겟 가상 프로세서로서 결정하거나; 또는
하나 이상의 서비스 가능 가상 프로세서의 우선순위가 상기 수신된 인터럽트 요청의 우선순위 미만인 경우, 상기 수신된 인터럽트 요청을 처리할 수 있는 모든 가상 프로세서들 중에서 가장 높은 우선순위를 갖는 가상 프로세서를 상기 타겟 가상 프로세서로서 결정하도록 구체적으로 구성되는, 가상화된 디바이스.
제5항에 있어서, 하나 이상의 서비스 가능 가상 프로세서의 우선순위가 상기 수신된 인터럽트 요청의 우선순위 미만인 경우,
상기 가상 컴퓨터는 상기 모든 서비스 가능 가상 프로세서들 중에서 가장 낮은 우선순위를 갖는 가상 프로세서를 중계 가상 프로세서로서 결정하고, 상기 중계 가상 프로세서에 IPI 인터럽트 요청을 전송하도록 추가로 구성되고, 상기 IPI 인터럽트 요청은 상기 타겟 가상 프로세서의 식별자를 운반하여, 상기 중계 가상 프로세서가 상기 IPI 인터럽트 요청에 따라 트랩 아웃(trap out)하게 하고;
상기 호스트는 상기 중계 가상 프로세서를 스왑 아웃(swap out)하고 상기 타겟 가상 프로세서를 스왑 인하도록 추가로 구성되는, 가상화된 디바이스.
제3항에 있어서,
상기 수신된 인터럽트 요청의 상기 처리 엔티티가 상기 다른 가상 프로세서이고 상기 다른 가상 프로세서 중 어느 것도 서비스 가능이 아니라고 결정될 때,
상기 가상 컴퓨터는 상기 타겟 가상 프로세서의 식별자를 상기 호스트에 전송하고, 상기 타겟 가상 프로세서를 트랩 아웃하도록 추가로 구성되고, 상기 타겟 가상 프로세서는 상기 처리 엔티티 내의 임의의 가상 프로세서 또는 상기 처리 엔티티 내의 가장 높은 우선순위를 갖는 가상 프로세서이고;
상기 호스트는 상기 타겟 가상 프로세서의 식별자에 기초하여 상기 가상 컴퓨터의 현재의 가상 프로세서를 스왑 아웃하고 상기 타겟 가상 프로세서를 스왑 인하도록 추가로 구성되는, 가상화된 디바이스.
제1항에 있어서, 상기 하드웨어 계층은 인터럽트 제어기를 포함하고;
상기 인터럽트 제어기는 인터럽트 친화성(interrupt affinity)에 기초하여 인터럽트 요청을 대응하는 물리적 프로세서에 전송하도록 구성되고, 상기 인터럽트 친화성은 인터럽트 요청과 물리적 프로세서 사이의 대응관계를 포함하고;
상기 하드웨어 계층으로부터 인터럽트 요청을 수신하는 양태에서, 상기 가상 컴퓨터는 상기 인터럽트 제어기로부터 상기 인터럽트 요청을 수신하도록 구체적으로 구성되고;
상기 호스트는 상기 인터럽트 제어기의 상기 인터럽트 친화성을 구성하여, 인터럽트 요청이 상기 인터럽트 요청의 처리 엔티티에 포함된 가상 프로세서에 전송될 수 있게 하도록 추가로 구성되는, 가상화된 디바이스.
제8항에 있어서, 상기 인터럽트 제어기의 상기 인터럽트 친화성을 구성하는 양태에서, 상기 호스트는: 가상 프로세서가 스왑 인된 후에 그리고 상기 가상 프로세서가 트랩 인하기 전에, 상기 인터럽트 친화성에서, 상기 스왑-인된 가상 프로세서를 실행할 물리적 프로세서와 처리 엔티티가 상기 가상 프로세서를 포함하는 모든 인터럽트 요청들 사이의 대응관계를 확립(establish)하도록 구체적으로 구성되는, 가상화된 디바이스.
제8항 또는 제9항에 있어서,
상기 가상 컴퓨터는: 상기 수신된 인터럽트 요청의 상기 처리 엔티티가 다른 가상 프로세서일 때, 상기 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하고, 상기 인터럽트 요청의 식별자를 현재의 가상 프로세서와 상기 호스트 둘 다에 액세스가능한 저장 영역에 기록하도록 추가로 구성되고, 상기 다른 가상 프로세서는 상기 가상 컴퓨터의 상기 현재의 가상 프로세서를 포함하지 않고;
상기 호스트는: 상기 타겟 가상 프로세서가 스왑 인된 후에, 상기 저장 영역에 기록된 식별자에 기초하여 상기 타겟 가상 프로세서에 인터럽트 요청을 전송하여, 상기 타겟 가상 프로세서가 트랩 인 후에 상기 인터럽트 요청을 처리하게 하도록 추가로 구성되는, 가상화된 디바이스.
제10항에 있어서,
상기 호스트는 상기 인터럽트 요청의 우선순위를 설정하고, 상기 우선순위를 상기 호스트와 상기 가상 컴퓨터 둘 다에 액세스가능한 저장 영역에 기록하도록 추가로 구성되고;
상기 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하는 양태에서, 상기 가상 컴퓨터는 상기 수신된 인터럽트 요청의 우선순위 및 상기 가상 프로세서의 우선순위에 기초하여 상기 타겟 가상 프로세서를 결정하도록 구체적으로 구성되고, 상기 가상 프로세서의 우선순위는 모든 가상 프로세서들에 액세스가능한 저장 영역에 저장되는, 가상화된 디바이스.
제11항에 있어서,
상기 수신된 인터럽트 요청의 우선순위 및 상기 가상 프로세서의 우선순위에 기초하여 상기 타겟 가상 프로세서를 결정하는 양태에서, 상기 가상 컴퓨터는:
상기 수신된 인터럽트 요청의 식별자에 기초하여, 상기 호스트와 상기 가상 컴퓨터 둘 다에 액세스가능한 저장 영역을 검색하여, 상기 수신된 인터럽트 요청의 우선순위를 획득하고; 상기 수신된 인터럽트 요청의 우선순위를 모든 서비스 가능 가상 프로세서들의 우선순위들과 비교하고; 상기 모든 서비스 가능 가상 프로세서들의 우선순위들이 상기 수신된 인터럽트 요청의 우선순위 이상인 경우, 상기 수신된 인터럽트 요청을 처리할 수 있는 모든 가상 프로세서들을 상기 타겟 가상 프로세서로서 결정하거나; 또는
하나 이상의 서비스 가능 가상 프로세서의 우선순위가 상기 수신된 인터럽트 요청의 우선순위 미만인 경우, 상기 수신된 인터럽트 요청을 처리할 수 있는 모든 가상 프로세서들 중에서 가장 높은 우선순위를 갖는 가상 프로세서를 상기 타겟 가상 프로세서로서 결정하도록 구체적으로 구성되는, 가상화된 디바이스.
제12항에 있어서, 하나 이상의 서비스 가능 가상 프로세서의 우선순위가 상기 수신된 인터럽트 요청의 우선순위 미만인 경우,
상기 가상 컴퓨터는 상기 모든 서비스 가능 가상 프로세서들 중에서 가장 낮은 우선순위를 갖는 가상 프로세서를 중계 가상 프로세서로서 결정하고, 상기 중계 가상 프로세서에 IPI 인터럽트 요청을 전송하도록 추가로 구성되고, 상기 IPI 인터럽트 요청은 상기 타겟 가상 프로세서의 식별자를 운반하여, 상기 중계 가상 프로세서가 상기 IPI 인터럽트 요청에 따라 트랩 아웃하게 하고;
상기 호스트는 상기 중계 가상 프로세서가 트랩 아웃한 후에 상기 타겟 가상 프로세서를 스왑 인하도록 추가로 구성되는, 가상화된 디바이스.
제10항에 있어서, 상기 수신된 인터럽트 요청의 상기 처리 엔티티가 상기 다른 가상 프로세서일 때,
상기 가상 컴퓨터는 상기 타겟 가상 프로세서의 식별자를 상기 호스트에 전송하고, 상기 타겟 가상 프로세서를 트랩 아웃하도록 추가로 구성되고, 상기 타겟 가상 프로세서는 상기 처리 엔티티 내의 임의의 가상 프로세서 또는 상기 처리 엔티티 내의 가장 높은 우선순위를 갖는 가상 프로세서이고;
상기 호스트는 상기 타겟 가상 프로세서의 식별자에 기초하여 상기 가상 컴퓨터의 현재의 가상 프로세서를 스왑 아웃하고 상기 타겟 가상 프로세서를 스왑 인하도록 추가로 구성되는, 가상화된 디바이스.
인터럽트 요청 처리 방법으로서,
상기 방법은 가상화된 디바이스에 적용되고, 상기 방법은:
프로세서에 의해, 호스트 모드에서 레지스터를 구성하여, 상기 프로세서가 게스트 모드에서 실행되는 가상 프로세서를 실행할 때 상기 가상화된 디바이스의 다른 하드웨어로부터 인터럽트 요청을 수신할 수 있게 하는 단계; 및
상기 프로세서에 의해, 상기 게스트 모드에서 다음의 동작들:
상기 프로세서에 의해, 상기 다른 하드웨어로부터 인터럽트 요청을 수신하는 동작; 및
상기 프로세서에 의해, 정보에 기초하여 상기 수신된 인터럽트 요청의 처리 엔티티를 결정하고; 상기 수신된 인터럽트 요청의 처리 엔티티가 상기 프로세서 상에서 현재 실행되는 가상 프로세서를 포함할 때, 상기 정보에 기초하여 상기 프로세서에 의해, 상기 수신된 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 호출하여 상기 인터럽트 요청을 처리하는 동작
을 수행하는 단계
를 포함하고,
상기 정보는 상기 인터럽트 요청, 상기 처리 엔티티, 및 상기 인터럽트 서비스 루틴 사이의 대응관계를 포함하는, 방법.
제15항에 있어서,
상기 호스트 모드에서 상기 프로세서에 의해, 상기 가상화된 디바이스의 물리적 인터럽트 제어기를 동작시킬 수 있도록 상기 프로세서 상에서 실행될 상기 가상 프로세서를 구성하는 단계; 및
상기 프로세서에 의해, 상기 게스트 모드에서 다음의 동작:
상기 수신된 인터럽트 요청의 상기 처리 엔티티가 다른 가상 프로세서이고 상기 다른 가상 프로세서 중 적어도 하나가 서비스 가능이라고 결정될 때, 상기 다른 가상 프로세서의 하나 이상의 서비스 가능 가상 프로세서에 IPI 인터럽트 요청을 전송하도록 상기 물리적 인터럽트 제어기를 동작시키는 동작을 추가로 수행하는 단계
를 추가로 포함하고, 상기 IPI 인터럽트 요청은 상기 수신된 인터럽트 요청의 식별자를 운반하고, 상기 다른 가상 프로세서는 상기 프로세서 상에서 현재 실행되는 상기 가상 프로세서를 포함하지 않는, 방법.
제15항에 있어서, 상기 프로세서에 의해, 상기 호스트 모드에서 상기 가상화된 디바이스의 인터럽트 제어기의 인터럽트 친화성을 구성하여, 인터럽트 요청이 상기 인터럽트 요청의 처리 엔티티에 포함된 가상 프로세서에 전송될 수 있게 하는 단계를 추가로 포함하고, 상기 인터럽트 친화성은 인터럽트 요청의 식별자와 프로세서의 식별자 사이의 대응관계를 포함하고;
대응하여, 상기 프로세서에 의해, 하드웨어로부터 인터럽트 요청을 수신하는 것은: 상기 프로세서에 의해, 상기 인터럽트 친화성에 기초하여 상기 인터럽트 제어기에 의해 상기 프로세서에 전송되는 인터럽트 요청을 수신하는 것을 포함하는, 방법.
제17항에 있어서,
상기 프로세서에 의해, 상기 호스트 모드에서 인터럽트 제어기의 인터럽트 친화성을 구성하는 것은: 상기 프로세서가 상기 호스트 모드에서 가상 프로세서를 스왑 인한 후에, 상기 프로세서에 의해, 상기 인터럽트 친화성에서, 상기 프로세서와 처리 엔티티가 상기 스왑-인된 가상 프로세서를 포함하는 모든 인터럽트 요청들 사이의 대응관계를 확립하는 것을 포함하는, 방법.
제17항 또는 제18항에 있어서,
상기 수신된 인터럽트 요청의 상기 처리 엔티티가 다른 가상 프로세서일 때, 상기 프로세서에 의해, 상기 게스트 모드에서 상기 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하고, 상기 게스트 모드와 상기 호스트 모드 둘 다에서 상기 프로세서에 액세스가능한 저장 영역 내의 상기 인터럽트 요청의 식별자를 기록하는 단계 - 상기 다른 가상 프로세서는 상기 프로세서 상에서 현재 실행되는 상기 가상 프로세서를 포함하지 않음 - ; 및
상기 타겟 가상 프로세서가 스왑 인된 후에 그리고 상기 타겟 가상 프로세서가 트랩 인하기 전에, 상기 호스트 모드에서 상기 프로세서에 의해, 상기 저장 영역에 기록된 상기 식별자에 기초하여 상기 타겟 가상 프로세서에 인터럽트 요청을 전송하여, 상기 타겟 가상 프로세서가 트랩 인 후에 상기 인터럽트 요청을 처리하게 하는 단계
를 추가로 포함하는 방법.
제19항에 있어서,
상기 프로세서에 의해, 상기 호스트 모드에서 상기 인터럽트 요청의 우선순위를 설정하고, 상기 호스트 모드와 상기 게스트 모드 둘 다에서 상기 프로세서에 액세스가능한 상기 저장 영역에 상기 우선순위를 기록하는 단계를 추가로 포함하고;
상기 프로세서에 의해, 상기 게스트 모드에서 상기 다른 가상 프로세서로부터 타겟 가상 프로세서를 결정하는 것은:
상기 프로세서에 의해, 상기 수신된 인터럽트 요청의 우선순위 및 상기 가상 프로세서의 우선순위에 기초하여 상기 타겟 가상 프로세서를 결정하는 것을 포함하고, 상기 가상 프로세서의 우선순위는 모든 가상 프로세서들에 액세스가능한 저장 영역에 저장되는, 방법.
제19항에 있어서, 상기 수신된 인터럽트 요청의 상기 처리 엔티티가 상기 다른 가상 프로세서일 때, 상기 방법은: 상기 프로세서에 의해, 상기 게스트 모드에서 상기 타겟 가상 프로세서의 식별자를 역방향으로 주입하는 단계; 다음으로, 상기 프로세서에 의해, 상기 게스트 모드를 퇴장하고 상기 호스트 모드에 진입하는 단계 - 상기 타겟 가상 프로세서는 상기 다른 가상 프로세서 또는 상기 다른 가상 프로세서에서 가장 높은 우선순위를 갖는 가상 프로세서 중 어느 하나임 - ; 및 상기 프로세서에 의해, 상기 타겟 가상 프로세서의 식별자에 기초하여 상기 호스트 모드에서 상기 프로세서 상의 가상 프로세서를 스왑 아웃하고, 상기 타겟 가상 프로세서를 스왑 인하는 단계를 추가로 포함하는, 방법.
제15항 내지 제21항 중 어느 한 항에 있어서,
상기 프로세서에 의해, 상기 호스트 모드에서 상기 정보를 수정하여 인터럽트 요청의 식별자, 상기 인터럽트 요청의 처리 엔티티, 및 인터럽트 서비스 루틴 사이의 대응관계를 추가하는 단계를 추가로 포함하고, 상기 정보는 상기 호스트 모드와 상기 게스트 모드 둘 다에서 상기 프로세서에 액세스가능한 저장 영역에 저장되고;
상기 프로세서에 의해, 상기 게스트 모드에서 상기 정보에 기초하여 상기 수신된 인터럽트 요청의 상기 처리 엔티티 및 상기 인터럽트 서비스 루틴을 결정하는 것은:
상기 프로세서에 의해, 상기 정보에 액세스하고, 상기 수신된 인터럽트 요청에서 운반된 상기 식별자에 기초하여, 상기 인터럽트 요청의 상기 처리 엔티티 및 상기 인터럽트 요청에 대응하는 상기 인터럽트 서비스 루틴을 결정하는 것을 포함하는, 방법.
인터럽트 요청 처리 장치로서,
상기 처리 장치는 가상화된 디바이스에 적용되고; 상기 가상화된 디바이스는 하드웨어 계층, 호스트, 및 가상 컴퓨터를 포함하고; 상기 처리 장치는 상기 호스트 상에 배치된 호스트 인터럽트 관리 유닛 및 상기 가상 컴퓨터 상에 배치된 게스트 인터럽트 관리 유닛을 포함하고;
상기 호스트 인터럽트 관리 유닛은 상기 하드웨어 계층으로부터 인터럽트 요청을 수신할 수 있도록 상기 가상 컴퓨터의 가상 프로세서를 구성하도록 구성되고;
상기 게스트 인터럽트 관리 유닛은 상기 하드웨어 계층으로부터 인터럽트 요청을 수신하고, 정보에 기초하여 상기 수신된 인터럽트 요청의 처리 엔티티를 결정하도록 구성되고; 상기 수신된 인터럽트 요청의 상기 처리 엔티티가 상기 가상 컴퓨터의 현재의 가상 프로세서를 포함할 때, 상기 가상 컴퓨터는 상기 정보에 기초하여 상기 수신된 인터럽트 요청에 대응하는 인터럽트 서비스 루틴을 호출하여 상기 인터럽트 요청을 처리하고, 상기 정보는 상기 인터럽트 요청, 상기 처리 엔티티, 및 상기 인터럽트 서비스 루틴 사이의 대응관계를 포함하는, 장치.
가상화된 디바이스로서, 프로세서 및 메모리를 포함하고, 상기 메모리는 컴퓨터 판독가능 명령어를 저장하도록 구성되고, 상기 프로세서는 상기 컴퓨터 판독가능 명령어를 판독하여 제15항 내지 제22항 중 어느 한 항에 따른 방법을 구현하도록 구성되는, 가상화된 디바이스.
컴퓨터 판독가능 명령어를 저장하도록 구성되는 판독가능 저장 매체로서, 상기 컴퓨터 판독가능 명령어가 프로세서에 의해 판독될 때, 상기 프로세서는 제15항 내지 제22항 중 어느 한 항에 따른 방법을 구현할 수 있게 되는, 판독가능 저장 매체.
IPI 인터럽트 요청 처리 방법으로서,
소스 가상 프로세서에 의해, 정보에 기초하여, 목적지 가상 프로세서를 실행하는 물리적 프로세서를 결정하는 단계 - 상기 정보는 상기 소스 가상 프로세서에 액세스가능한 저장 영역에 기록되고, 상기 정보는 상기 목적지 가상 프로세서를 실행하는 상기 물리적 프로세서를 나타내는 정보를 포함함 - ; 및
상기 소스 가상 프로세서에 의해, 상기 목적지 가상 프로세서를 실행하는 상기 물리적 프로세서에 IPI 인터럽트 요청을 전송하도록 인터럽트 제어기를 동작시키는 단계
를 포함하고,
호스트가 상기 소스 가상 프로세서에 대한 인터럽트 제어기 동작 모드를 구성하여, 상기 소스 가상 프로세서가 상기 목적지 가상 프로세서를 실행하는 상기 물리적 프로세서에 상기 IPI 인터럽트 요청을 전송하도록 상기 인터럽트 제어기를, 트랩 아웃 없이, 동작시킬 수 있게 하는, 방법.
제26항에 있어서, 상기 IPI 인터럽트 요청은 다른 인터럽트 요청의 식별자를 운반하거나, 상기 IPI 인터럽트 요청은 다른 인터럽트 요청의 식별자 및 가상 프로세서의 식별자를 운반하고; 상기 방법은:
상기 목적지 가상 프로세서가 상기 IPI 인터럽트 요청이 가상 프로세서의 식별자를 운반하지 않는다고 결정하거나, 상기 IPI 인터럽트 요청에서 운반된 상기 가상 프로세서의 식별자가 상기 목적지 가상 프로세서의 식별자와 일치한다고 결정하는 경우, 상기 목적지 가상 프로세서에 의해, 상기 다른 인터럽트 요청의 식별자에 대응하는 인터럽트 서비스 루틴을 호출하여 상기 다른 인터럽트 요청을 처리하는 단계를 추가로 포함하는 방법.
제26항에 있어서, 상기 IPI 인터럽트 요청은 가상 프로세서의 식별자를 운반하고, 상기 방법은:
상기 목적지 가상 프로세서가 상기 IPI 인터럽트 요청에서 운반된 상기 가상 프로세서의 식별자가 상기 목적지 가상 프로세서의 식별자와 불일치한다고 결정하는 경우, 상기 목적지 가상 프로세서에 의해, 상기 가상 프로세서의 식별자를 상기 호스트에 전송하고, 트랩 아웃하여, 상기 호스트가 상기 가상 프로세서의 식별자에 의해 표시된 상기 가상 프로세서를 스왑 인하게 하는 단계를 추가로 포함하는 방법.
제26항 내지 제28항 중 어느 한 항에 있어서, 상기 소스 가상 프로세서는 상기 목적지 가상 프로세서가 서비스 가능이라고 결정할 때에만 상기 IPI 인터럽트 요청을 전송하고;
상기 소스 가상 프로세서에 의해, 상기 목적지 가상 프로세서가 서비스 가능이라고 결정하는 것은:
상기 소스 가상 프로세서에 의해, 상기 정보를 질의하여 상기 목적지 가상 프로세서가 서비스 가능인지를 결정하는 것을 포함하고, 상기 정보는 상기 목적지 가상 프로세서가 서비스 가능인지를 나타내는 정보를 추가로 포함하는, 방법.
가상화된 디바이스로서,
상기 가상화된 디바이스는 소스 가상 프로세서 및 목적지 가상 프로세서를 포함하고, 상기 소스 가상 프로세서 및 상기 목적지 가상 프로세서는 동일한 가상 컴퓨터 또는 상이한 가상 컴퓨터들을 서빙하고;
상기 소스 가상 프로세서는, 정보에 기초하여, 상기 목적지 가상 프로세서를 실행하는 물리적 프로세서를 결정하고, 상기 정보는 상기 소스 가상 프로세서에 액세스가능한 저장 영역에 기록되고, 상기 정보는 상기 목적지 가상 프로세서를 실행하는 상기 물리적 프로세서를 나타내는 정보를 포함하고;
상기 소스 가상 프로세서는 상기 목적지 가상 프로세서를 실행하는 상기 물리적 프로세서에 IPI 인터럽트 요청을 전송하도록 인터럽트 제어기를 동작시키고;
상기 호스트는 상기 소스 가상 프로세서에 대한 인터럽트 제어기 동작 모드를 구성하여, 상기 소스 가상 프로세서가 상기 목적지 가상 프로세서를 실행하는 상기 물리적 프로세서에 상기 IPI 인터럽트 요청을 전송하도록 상기 인터럽트 제어기를, 트랩 아웃 없이, 동작시킬 수 있게 하는, 가상화된 디바이스.