Xtratum : a Hypervisor for Safety Critical Embedded Systems

Xtratum : a Hypervisor for Safety Critical Embedded Systems

M. Masmano, I. Ripoll, and A. Crespo

Instituto de Informatica Industrial, Universidad Politecnica de Valencia (Spain)

Abstract

Xtratum은 극도의 안정성 요구사항을 만족하도록 디자인되었다. 기본적으로 x86아키텍쳐 디자인되었다(버젼 2.0)

그리고 Xtratum은 SPARC v8을 아키텍쳐의 LEON2 프로세서에 특화하여 재디자인 되었다. 2.2 버젼에는 ARINC 653와 AUTOSTAR 표준 기반의 안정성을 구축하기 위한 모든 기능이 포함되었다. 하지만 Xtratum은 표준에 준수하는 API를 제공하지 않고 있지만, 파티션들은 쉽게 응용프로그램들에게 API를 제공할수 있다. Xtratum은 우주항공 분야에서 사용되기 시작되었다. Xtratum은 ARINC 653의 스케쥴링 정책을 제공하고 있다, 파티션 관리, IPC, 헬스모니터, logbook, traces 그리고 다른 서비스를 쉽게 ARINC 653표준에 맞게 adapt 할수 있다. 시스템의 환경설정은 XML 형식의 configuration파일로 지정한다 그리고 이것은 하드웨어 보드에 최종적으로 배포될 container(Xtratum과 파티션 코드)를 만들때 정적으로 컴파일 된다. As far as we know 우리가 아는대로 SPARC v8 아키텍쳐의 첫 하이퍼 바이져이다. 

이논문에서는 메인 디자인 측명에 대한 설명과 내부 구조에 대한 설명이 되어있다. 가장중요한 지표의 평가도 제공한다. 

1. Introduction 

가상화가 60년대 메인프레임 시스템에서 사용되어 왔지만 90년대 데스크탑의 성능 향상으로 인하여 PC시장에서 가상화사용이 열리고 있다. 현재는 임베디드 시장또한 진보가 준비되고 있다. 최근 대부분의 가상화는 데스크탑 시스템에서 이루어지고 있다.  이러한 결과다 바로 임베디드 시장으로 이어지지 않아 보일수 있다,

현재 가상화 기술은 몇몇기술들과 융합(convergence)되고 있는 상태이다. : operating system design, compilers, interpreters, hardware support 등등 이로한 이종의(heterogeneous)origin은 빠른 진화와 함께 용어의 혼란을 발생했시켰다. 

같은 용어는 다른 아이디어를 참조하는 데 사용되며, 동일한 개념은 다른 엔지니어 배경에 따라 이름이 지정된다. 

VM은 실제 머신과 같이 동작하는 소프트웨어 동작 머신이고, Hypervisor(VMM이라고도 불리운다.)는 하나의 싱글 컴퓨터에서 몇몇의 독립된 실행을 가능하게 하는 소프트웨어(or 하드웨어/소프트웨어 조합) 레이어이다.

하이퍼바이저나 다른 종류의 가상화(자바 버츄얼머신 이나 소프트웨어 에뮬레이션)의 key는 바로 성능(Performance)이다.

하이퍼 바이자의 VM의 성능은 본 하드웨어 환경에서의 성능에 매우 근접하였다. 하이퍼 바이저는 새롭고 약속된 기술이다. 하지만 타겟 어플리케이션에 맞추어 적응및 요구사항을 맞게 custonize 해야한다. 우리가 아는 대로 hypervisors for spatial systems에 대한 이전 경험이 없다. when 리얼타임 임베디드 시스템을 위한 하이퍼 바이저 다음과 같은 이슈가 고려 되야 한다.

- Temporal and spatial isolation.

// 시간과 공간적인 분리

- Basic resource virtualisation: clock and timers, interrupts, memory, cpu time, serial i/o.

// 기본 자원의 가상화 시간, 인터럽트, 메모리, cpu 시간, 시리얼 I/O

- Real-time scheduling policy for partition scheduling.

// 파티션 스케쥴링을 위한 리얼타임 스케쥴링 정책

- Effcient context switch for partitions.

- Deterministic hypervisor system calls.

// 하이퍼콜을 어떤걸 구현하는가? (어떤 시스템 콜을 하이퍼 콜로 바꿔야 할것인가?)

- Effcient inter-partition communication.

- Low overhead

- Low footprint

// 작은 발자국(하이퍼 바이저를 설치하느데 적은 자원을 사용해야 한다.)

이 논문에서 LEON2 processor의 디자인과 구현 그리고 측정 결과를 나타낼것이다. 

2. Virtualising technologies overview

// 통상적이 하이퍼 바이저 이야기 이다.

하이퍼 바이저는 두가지 부류로 나누어 진다. type1과 type2이다. 

type1은 바로 native 하드웨어서 동작한다.( native or bare-matal hypervisor라고 불리운다.) 

type2는 호스트 운영체제위에서 동작하며 가상 실행환경을 게스트 오퍼레이션 이라고 한다.  

두기술은 다르지만 실행환경을 오리지널 환경이 아닌곳에서 재생성 가능하게 한다는 같은 목표를 가지고 있다. 

가상화는 핫한 연구 분야이지만 아직 clear solution이 존재 하지 않는다. 

"Virtualization: State of the Art" 논문 읽어보기 

Separation kernel 

이 접근 방법은 프로세서or 프르세서 그룹 간 서로 간의 강력한 isolation을 운영체제의 확장을 통하여 지원하는것이다. 

간 프로세서간의 파티션을 고려하는것이다. 이 해결책은 운영체제는 파티션을 꼭 사용하고 같은 운영체제에서 몇개의 instance가 실행한다 

Micro-kernel 

복잡한 운영체제를 개선하기 위해서 생겨난 개념이지만 가상화에 적용이 가능하다. 

Bare-metal hypervisor 

the virtual machine will be close to the native hardware in order to directly use the native hardware as much as possible

without jeopardizing the temporal and spatial isolation. 

2.1 Para-virtualization

Para-virtualization기술은 conflicting instruction(instructions that operate directly on the native hardware and may break the isolation.)를 제어 할수 있는 기능을 하이퍼 바이저가 제공하고 있다. 이 경우 파티션 코드가 가상화 환경에서 하이퍼 바이저의 서비스를 사용하는데 한계가 있다. 이 서비스는 Hypercall로 제공 되게 된다.

 여전히 하이퍼 바이저는 시스템의 하드웨어 자원에 대한 관리에 대한 책임을 가지고 있고 시간적 공간적 독립성이나 직접 하드웨어를 접근하는것을 허용하지 않습니다. 

Para-virtualization기술은  임베디드 시스템에 fit한 기술이다. 빠르고 간단하고 작고 그리고 customization of the guest operating system is not a problem because the source code is available. 또한이 이 기술은 프로세서의 특별한 기능이 필요하지 않기 때문에 단가 면에서도 좋다. 

2.2 Dedicated devices

보통 가상화는 디바이스 하드웨어 자원에 바로 접근하는것을 막는데 이방법은 서버 같은 컴퓨터에 많은 디바이스를 VM에 할당할 수 있을 때 사용한다.  디바이스 드라이버가 복잡해진다.

3. Xtratum Overview

Xtratum[1.0]은 RTLinux를 바탕으로 시간적 공간적 요구상항을 목표로 디자인 되었다. Xtratum 는 나노커널 수준의 OS들을 가상화 하기 위해서 디자인 되었다. 그냥 RTLinux에 Xtratum을 LKM형식으로 구현하였다 빠른 프로토 타입을 위해서 리눅스 root도메인과 Xtratum을 같은 메모리 공간을 공유하였고 그럼에도 불구하고 도메인의 나머지 부분 은 공간 격리를 제공 하는 다른 매모리 맵에서 실행하였다.(게스트 운영체제의 공간 파티션을 지원했다는 이야기)

Xtratum[2.2]에서는 리눅스와 bootable에 독립적으로 하기위한 재디자인하였다. 이 버젼은 payload on-board software를 위한 TSP-based solution으로 빌드 되었다.  highly generic and reusable(일반화와 재사용성) 하자는 의미로 프로젝트 이름을 LVCUGEN으로 하였다. TSP (Time and Space Partitioning) based architecture has been identied as the best solution to ease and secure reuse

Xtratum은 type1 하이퍼 바이저이다. 파라 버추얼라이즈 기술을 사용하는 파라 버추얼 라이제이션은 네이티와 유사한 성능 을 가져갈수 있다. 그러므로 이미 네이티브 하드웨어에서 동작하던 간단한 테스크 를 포팅할수 있다 : OS의 HAL이나 상은하는 hypercall를 교페한다면.

ARINC-653은 IMA환경에서 사용되는 응용 프로그램의 기본 표준이다. 명시적 으로 표준에서 언급되지 않았지만 커널의 분리를 위한 파티션을 구현하는 과정에서 고려 되었다. 이것은 하이퍼 바이저의 표준은 아니지만 ARINC-653의 APEX의 기능은 하이퍼 바이저의 기능에 매우 유사하다. 이런 이유로 이것은 Xtratum디자인 하는되 참조되어 사용되었다. ARINC-653의 호환시스템으로 Xtratum변환하는 것이 의도는 아니다 (APEX모듈이 하이퍼 바이져에 유리하다는 판단에서 나온 결정이다 APEX가 정확이 먼지 규명하기) 

이것은 API와 파티션을 위한 동작이 정의 되어있다. 그리고 프로세서나 쓰레드를 각각의 파티션에서 관리하는가에 대한 내용이 있다.

Xtratum에서 파티션은 VM이라기 보다는 a group of strongly isolated processes 이다. 멀티 쓰레딩이 지원이 필요한 파티션이라면 운여체제나 런타임 지원 라이브러리가 어플리케이션 쓰레드에 지원되어야 할것이다. Xtratum에서는 지원이 가능하다.(APEX를 사용하므로 가능해 진다는 이야기 같다.)

XtratuM was designed to meet safety critical real-time requirements. The most relevant features are:

      - Bare hypervisor.

      - Employs para-virtualisation techniques.

- An hypervisor designed for embedded systems: 

some devices can be directly managed by a designated partition.

     - Strong temporal isolation: fixed cyclic scheduler.

     - Strong spatial isolation: all partitions are executed in processor user mode, and do not share memory.

     - Fine grain hardware resource allocation via a configuration file. 

     // 작은 떨어진 곡식깥은 자원들을 남김없이 사용한다 설정 파일을 통하여

     - Robust communication mechanisms (XtratuM sampling and queuing ports).

     // APEX 에 대한 스터디가 필요하다 매우 매우 

4. Architecture and design

이 구조의 메인 구성요소들은 다음과 같다. 

Hypervisor Xtratum은 파티션에게 가상 서비스를 제공한다. 이것은 supervisor processor mode로 실행되고 cpu, memory, interrupts 와 주변 장치 들이 가상화 된다. Xtratum의 내부 구성은 메모리 관리자 , 스케쥴러(고정 사이클 스케쥴러), 인터럽트 관리자, 시간과 타이머 관리자, 파티션 커뮤니케이션 관리자(ARINC-653 통신 모델), 헬스 모니터 

// 각 구성요소의 자세한 설명이 있는 논문을 찾아야 겠다. 

Partitions 파티션은 하이퍼바이저의 가상화 서비스를 받는 환경에서 동작한다. 각각의 파티션은 하나 혹은 그이상의 프로세서를 가진다. 응용 프로그램의 요구사항에 따라 프로세서 리소스에 대한 접근을 공유한다. 

The partition code can be :

- An application compiled to be executed on a bare-machine (bare-application).

- A real-time operating system (or runtime support) and its applications.

- A general purpose operating system and its applications.

Partitions need to be virtualised to be executed on top of an hypervisor.Depending on the type of execution environment, the virtualisation implications in each case can be summarised as:

Bare application 응용 프로그램은 Xtratum가 제공하는 서비스를 사용하여 가상화 될수 있다. 어플리케이션이 바로 하드웨어 위에서 동작하도록 설계 되었있다면 이것을 기억하고 있어야 한다. (운영체제 없이 돌아가는 응용 프로그램을 가상화 하는것을 말하는거 같고 그런 경우 바로 하드웨어 에 접근 하기때문에 그 분분에 대한 파티션이 필요하다.)

Operating system application 응용 프로그램이 운영체제위에서 동작하고 있을때 운영체제의 서비스를 제공받는다 그리고 가상화 할필요가 없다. 그러나 운영체제는 가상화와 거래를(주고 받아야 한다 하드웨어 자원에 대한 접근) 운영체제는 가상화 할수 있다. (ported on top of Xtratum)

두가지 다른 타입의 파티션이 정의 되어있다 : supervisor() and user ().

파티션은 다른 파티션에서 send/receive messages를 보낸수 있다. 이 기본 매커니즘은 ARINC-653에 정의된 sampling a queuing ports 사용한다.

4.1 Design issues

Xtratum은 리얼 타임을 강제하도록 특별하게 설계 되었다 그리고 매우 효율적이다. 주요 포함 요구사항은 다음과 같다 :

Data structures are static: 

모든 structures는 configuration파일에 있는 내용에따라 미리 정의 된다 빌드 할때 그러므로 1) 더 효율적인 알고리즘은 사용할수 있다. 2)  Xtratum이 정확한 자원 사용량을 알수 있다. 

XtratuM code is non-preemptive: 

이 기능은 대부분의 운영체제에서 바람직한 기능이지만 이것은 작은 하이퍼 바이저에서에 이득이 없다. 코드는 심플해지고 빨라진다. 

All services(hypercalls) are deterministic and fast: 

Xtratum은 최소한의 서비스를 제공한다 to 파티션의 시간/공간적 isolatioon을 보장하기위한.

Peripherals are managed by partitions:

 Xtratum은 오직 환경설정 파일에 정의된 슈퍼바이저 만이 IO포트에 접근할수 있다. 

Interrupt occurrence isolation: 

파티션이 실행중일때 인터럽트 메니징은 오직 파티션을 사용해서 가능하다. 이것은 내부 파티션간의 인터페이스를 최소화 할수 있다. 

Full control of the resources used by XtratuM and the partitions: 

모든 시스템의 자원은 환경 파일에 명시된되로 파티션에 할당된다. 

One-shot timer:

이것은 1 마이크로초 간격으로 제공된다., 타이머와 시간을 위해서 이것은 매우 낮은 어버해드를 가진다.

4.2 LEON2 virtualisation issues

SPARC V8 구조는 가상화를 지원하지않는다. 이것은 두가지 특권 단계로 구현되어있다: supervisor 와 user; 운영체제에서 사용자 응용 프로그램을 제어하기 위해 있는거다 isolation을 보장하기 위해서 사용할수 있다. 파티션코드는 유저 모드에서 동작하고 슈퍼바이저 모드는 Xtratum만이 접근할수 있다. 

추가적으로 Xtratum은 LEON2 의한 디자인을 설명하기 위해 레지스터 윈도우 개념과 MPU에 대하여 설명한다. LEON2는 MMU가 없지만 LOEN4는 있다. 

5. System configuration and deployment 

통합자와 파티션 개발자는 함꺠 각각의 파티션에 어떻게 자원을 할당하지 정의해야 한다. XF_CF.xml파일에 Xtratum의 파라미터 파티션에 할당된 정보가 있다. 이것은 다음과 같은 정보를 포함하고 있다 : memory requirements, processor sharing,

peripherals, health monitoring actions, etc.

- Memory requirements: 

보드에 물리적 메모리의량 그리고 각각의 파티션에 할당되 메모리의량

- Processor sharing: 

얼마나 각각의 파티션에 프로세서가 할당되어야 하는지 : 스케쥴링 계획

- Native peripherals: 

주변 장치는 Xtratum의 관리 하지 않고 파티션이 관리한다. 파라 버츄얼이기 때문이다. 

- Health monitoring: 

어떻게 오류를 감지하고 관리 할것인가: direct action, delivered to the offending partition, create a log entry, etc. //먼가 기능으 이름같은데 바로 처리, 파티션에 전달?, 로그 

- Inter-partition communication: 

The ports that each partition can use and the channels that link the source and destination ports.

XM_CF.xml 파일은 각각의 파티션에 할당된 자원이 정의 되어있다. 이 파일은 통합자와 파티션개발자와의 contract를 나타낸다. 혼자서 설정 파일을 변경할 수 없다. 둘다 모드 동의 해야지만 변경할 수 있다. 통합과정에서의 문제 발새을 피하기 위해서이다.

Xtratum의 복장성을 줄이기 위해서 XM_CF.xml은 분석되어 변형된다 바인너리로 이것은 Xtratum코드가 바로 사용할수 있다. 이 과정은 xmcparser and xmcbuilder 툴을 사용하여 진행된다. 

shared symbols때문에 각각의 파티션(하이퍼바이저)이 영향을 주지않는다는 것을 보장 하기위해서. 파티션 바이너리 파일은 하나의 ELF파일이 아니다. 이것은 낮은 수준의 바이너리 파일이고 머신코드와 초기 데이터를 포함하고 있다.  

시스템의 이미지는 하나의 싱글 파일이다 이것은 포함하고 있다 모든 코드와 데이터 그리고 설정 정보를 그리고 이것은 타겍 보드에 로드되게 된다. 툴 xmpack은 모든 실행이미지를 읽고 그리고 설정 파일을 만들어 시스템 이미지를 만든다. 그리고 시스템을 boot하기 위한 코드가 있다. 시스템 이미지파일은 보드의 ROM에 쓰여질 수 있다. 

6. Performance Evaluation

//하이퍼 바이저의 성능을 평가 하기위해서 어떠한 것들을 측정했는지에 대한 내용이 중요한것같다. 

-Partition context switch: Time needed by the hypervisor to switch between partitions. Three main activities can be identied:

1. Save the context

2. Timer interrupt management

3. Scheduling decision

4. Load the context of the new partition

- Clock interrupt management: Time needed to process a clock interrupt

- Effective slot duration: Time where the partition is executing partition code during a slot.

- Partition performance loss: This measurement provides a measure of the overhead introduced by XtratuM. It is measured at partition level.

- Hypercall cost: Time spent in some of the hypercalls