XtratuM for LEON3: an Open Source Hypervisor for High Integrity System

XtratuM for LEON3: an Open Source Hypervisor for High Integrity System 

Miguel Masmano, Ismael Ripoll, Alfons Crespo and Salvador Peiro

Instituto de Inform´ atica Industrial. Universidad Polit ´ecnica de Valencia.

abstract 

우주 온보드 컴퓨터의 사양이 높아 지고 있다. 그렇기 때문에 가상화, 마이크로 커널, 분활 커널 솔류션의 사용이 가능하다. 

XtratuM은 높은 리얼 타임 시스템 오픈소스 하이퍼 바이저 목표로 하고 있다. LEON3를 Securely Partitioning pacecraft

Computing Resources project 하는 것이 목표 이다. 이 논문은 현제 LEON3를 위한 Xtratum의 구현 상태를 설명한다. 

Introduction 

이논문은 이전  LEON2 를 위한 Xtratum을 LEON3에 맞추어 추가 구현한 내용을 담고 있다 그중에서 가장 큰 변화인 MMU와 관련된 구현을 설명하고 있다. 

XtratuM hypervisor

Xtratum이 처음에 RTLinux를 사용하여 구현한 이유는 크게 두가지 가 있다. 

1. RT 리눅스를 사용하여 가상화관련되 특허와 보호되고 있는 메커니즘 때문에 발생하는 법적 문제를 피하기 위하여

2. 그리고 기술적인 한계를 극복하기 위하여

이것은 두개의 커널을 동시에 돌리는 것과 같다. (RTlinux의 성질) 그리고 이렇게 함으로써 boot sequence를 신경 쓰지 않아도 된다. 그렇기 때문에 첫번째 프로토 타입의 구현이 빨라진다. 그러나 이것은 완전하게 만족될수 없다 이유는 Xtratum과 linux가 여전히 같은 메모리를 공유하고 둘다 슈퍼 바이저 모드로 동작하기 때문이다. 

그다음 버전에서는 그 둘을 분리 하는 작업을 하였다. 

다음과 같은 관련 요구사항을 가진다. 

 

- Bare-metal hypervisor.

– Implements para-virtualisation techniques.

– Designed for embedded systems: low footprint,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 XML configuration file.

– Robust communication mechanisms (ARINC 653-1 based sampling and queueing ports).

– Health monitoring capabilities.

– Two security levels: standard and system partitions

2.1 Architecture and design 

두가지 서로 다른 파티션이 정의 되어 사용되어 진다.

system 그리고 user 

시스템 파티션은 여저 파티션의 상태(suspend/resume/halt/reset)나 전체 시스템의 상태를 변경할수 있다.

2.2 LEON2 version limitations

- SPARC architecture는 어떤 종류의 가상화도 지원하지 않는다. 

      it 두가지 privilege level 로 구현되었다. supervisor 와 user

그렇기 때문에 isolation를 보장하기 위해서 파티션 코드는 user 모드 Xtratum 코드는 supervisor 모드로 실행 되어야 한다.  

>> 이 요구 사항은 두 가지 모드를 필요로하는 운영 체제에 한계를 부과한다. (파티션OS와 에플리케이션 코드)

- MMU 가지고 있지않다. 그래서 Xtratum 구현에 방해가 된다. 

[ Full spatoal isolation ] 그럼에도 불구하고 LEON2’s memory write protection registers를 통하여 일부 공간 분리를 제공한다. 파티션은 타른 파티션의 메모리 공간에 덮어 사용할수 없다. 그러나 이것은 어떠한 메모리 영역도 읽을수 있다.(쓰기는 memory write protection registers를 이용하여 해결이 가능하나 읽기는 해결할수 없다.)

게다가 보호영역에 메모리에 쓰기를 할경우 트랩이 발생하는데 이것은 MMU의 트랩과 달리 동기식 이기때문에 수신 받기 위해서 는 여러 싸이클이 필요하다. (성능적으로 좋지 않다.)

그리고 잘못된 파티션을 죽이는 상황을 처리 하기 더 힘들다 ? 

[ Shared memory between partitions ] 공유 메모리의 사용을 효율적으로 구현하는 데 사용할 수 있다.

zero-copy inter-partition(파티션 간) communication mechanisms 지금(LEON2 버전) Xtratum은 queuing과 sampling port를 사용하고 있다 이것은 둘다 데이터를 두번 복사 해야만 한다. (sender ! XtratuM ! receiver)

공유 메모리를 사용하면 파티션간의 통신을 더욱 효과적으로 할수있다. zero-copy를 통하여 

게다가 공유메모리의 부재는 Xtratum의 파티션간의 공유된 구역에도 방해가 된다. 

예를 들어 만약 두개의 파티션들이 Linux를 이용하고 있다면 메모리에 두개의 리눅스 코드를 반드시 복사해야한다. (공유 메모리를 사용하면 2개의 파티션이 리눅스 코드를 공유하여 메모리 공간을 아낄수 있다.)

3 XtratuM for LEON3 processor

이번전은 SMP와 MMU가 추가 되었다.

MMU를 사용하게 됨으로서 Xtratum은 다음과 같은 것이 가능하게 되었다. 

- [ Implement full spatial isolation ] 파티션은 더이상 다른 메모리역역을 읽을수 가 없다. 

- [ Support inter-partition shared memory ] XML Configuration에 명시한데로 메미리공유 영역을 만들어서 파티간의 통신이 가능해진다. 더 효율적이다. 그리고 코드 영역의 공유를 통하여 중복되는 코드를 줄일 수 있다.

이 프로세서에 Xtratum를 적용하기 위해서 MMU의 가상화로 구성되어 있다.  

each partition has its own virtual memory map where the top area is reserved for XtratuM. XtratuM itself is mapped on this area with supervisor permissions. 나머지는 파티션의 정의된(XML configuration file)되로 채워진다. 또한, 파티션은 새로운 메모리 맵을 정의하고이를 업데이트하는 기능이 있습니다. 또한 하이퍼 콜을 제공하여 파티션이 메모리 맵을 관리 할 수 있도록 한다. 

그림 2는 두개 의 가상 메모리 맵을 보여준다. build by XtratuM as a result of the following XML con-

figuration file:

This XML configuration file defines two partitions P1 and P2 and allocates two memory areas to each partition. One of them, the area starting at 0x30000, shared. In addition, the configuration establishes that the areas non-shared, the area starting at 0x10000 and the area starting at 0x20000, are mapped at the same virtual memory address, that is, 0x8000.

3.1 memory management virtualisation

컴퓨터를 효율적으로 가상화 할때 가장 어려운것이 메모리 메니지 메니지먼트이다, 메커니즘 관점에서 하이퍼 바이저와 OS둘 다 수정이 요구된다. 

메모리를 가상화 하기 위하여 Xtratum은 XEN의 approach를 따른다. 다음과 같은 

1.  각각의 파티션은 스스로 page table를 managing한다. (초기화는 Xtratum이 생성한다.)

2.  Xtratum은 모든 메모리 맵의 top에 매핑된다. 그러므로  TLB flush가 방지된다 when 하이퍼 바이저를 진입할때와 떠날때 

메모리 맵의 초기화는 XML configuration file 에 명시한 내용으로 생성되면 파티션이 이를 업데이트 할 수 없다, 만약 파티션이 새로운 메모리 맵이 필요하면 그것은 자신의 메모리에서 페이지 설정을 등록하여 새 메모리 맵을 정의 할 수 있습니다.

일단 등록되면, 이 페이지는 읽기 전용이되어 있으므로 후속 업데이트는 XtratuM에 의해 검증되어야합니다.

3.2 Chang in the XtratuM core

세 가지 변화가 XtratuM 코어에서 수행된다:

- Xtratum은 virtual memory manager라고 불리우는 새로운 모듈을 만들고 이것은 virtual map를 관리 그리고 create/release그리고 map/unmap physical pages가 가능하다. 

- 위 설명을 위해, Xtratum은 3가지 새로운 하이퍼 콜이 추가 된다. 

XM set page type() : 이는 새로운 메모리 맵을 등록 할 파티션을 허용한다.

XM update page32() : 이는 파티션이 이미 존재하는 메모리 맵 항목을 update 할 수 있습니다.

XM write register32(PTD1 REG32,) : 파티션이 현제 매모리 메모리를 새걸로 바꿀수 있게 해준다. 

3.3 Changes in the XML configuration file

이전 버젼에서는 MMU를 고려 하지 않았다 그렇기 때문에 MMU지원 부분을 반드시 추가 해야 했다. 그러나 지난 문법과의 호환이 되어야 한다. We have included two new attributes to the definition of the physical memory area element::

- @flags

(/Partition/PhysicalMemoryAreas/Area/@flags)

- @mappedAt

(/Partition/PhysicalMemoryAreas/Area/@mappedAt)

@flags 속성은 각각의 메모리 영역에 속성을 부여하는 시스템 통합을 가능하게합니다. 이러한 속성은 다음과 같습니다 :

- Uncacheable

이 속성이 사용될때는 메모리 영역이 가상 메모리 맵에 not cached 되어 남아있을때 이다. (remain)

이 메모리 영역의 캐시되어야하는 정의보다 세밀하게 제어 할 수 있습니다. 기본적으로 메모리 영역이 캐시됩니다.

- Read-only

when set, the memory area is always mapped as read-only. The partition is unable to modify its content. By default memory areas have read/write permissions.

- Unmapped

지정된 경우, 메모리 영역은 초기 메모리 맵에 매핑되지 않습니다. 그럼에도 불구하고,이 속성은 메모리 영역을 매핑 할 파티션을 방지하지 않습니다.By default all memory areas are mapped on the initial memory map.

- Shared

this property enables the system integrator to allocate the same memory area to one or more partitions. By default memory areas are private and can be only allocated to one partition.

@mappedAt 속성은 기본적으로 시스템의 메모리 영역을 맵핑 할때 사용한다. If this attribute is not specified, the memory area is mapped 1:1 물리적 메모리와 

4. Assessment

This section provides the initial evaluation of XtratuM for LEON3 processor. A development board

GR-CPCI-XC4V (LEON3) processor at 50MHz with 16MB of flash PROM and 128MB of RAM has been

used during this evaluation. // 실험 환경 

성능 지표 

- Loss of performance due to scheduling

파티션이 하드웨어 위에서 도는거랑 Xtratum 위에서 도는것의 손실 측정

- Loss of performance due to the number of partitions.

파티션의 증가로 인한 성능의 손실 측정

- Partition context switch time (PCS)

하나의 파티션이 정지하고 다음 파티션이 동작하는 시간 

4.1 Scenario description

4.2 Evaluation result 

논문 참고

5. Conclusion and future work

LEON2 에서는 full spatial partitioning를 지원할 수 없었다 . 하지만 LEON3에서는 MMU를 지원하기 때문에 full spatial

partitioning의 구현이 가능하다. 

이들의 연구 결과상 SPARC V8이 MMU를 지원하는것이 더 효율적이라고 한다. 

하지만 MMU의 과 사용은 오버헤드 일 수 있다. 그예

[ Translation from virtual to physical space ]

변환에 추가적인 사이클이 필요한것인데 하지만 TLB가 완화 시켜준다 그러나 TLB의 작은 사이즈 때문에 페이지 크기에 신경을 써야 한다.

[ Physical memory access ]

MMU가 없다면 모든 물리적 주소에 접근이 가능하다 그러나 MMU를 사용하면 공간 제약이 있기 때문에 더 이상 모든 물리주소를 맵할 수 없다. 예를 들면 Xtratum에 맵핑되지 않은 영역에 접근 하고 싶다면 그영역을 맵핑 해야 하므로 그만큼의 지연이 발생한다. 

[ TLB faulting ]

LEON3는 작은 TLB를 가지고 있다. // LEON4 는 어떻게 되어 있는지 확인이 필요하다. 

[ TLB flushing ]

SPARCv8의 컨텍스트 의 구현 컨셉은 각각의 컨텍스트 스위치후 TLB Flushing의 필요성을 피한다. (컨텍스트 스위칭을 하고 TLB를 플래싱 하지 않는다) 하지만 이것은 컨택스트 스위칭의 오버해드로 간주 해야만한다.