ARMv9 아키텍처 진화와 실행 모델

ARMv9가 바꾼 것을 먼저 한눈에 본다

ARMv9는 ARMv8을 버리고 새로 만든 CPU 언어가 아니다. 기존 AArch64의 EL0~EL3, page table, exception과 memory-ordering 구조를 이어받고, 더 넓은 vector·matrix 계산과 confidential computing, memory·control-flow 보안을 단계적으로 강화했다.

읽을 때의 기준: ARMv9라는 제품명보다 Armv9.x-A + FEAT_* + CPU revision + Linux HWCAP을 본다. 같은 ARMv9 CPU라도 선택 기능과 vector length, cache·PMU 구현이 다를 수 있기 때문이다.

ARMv9는 Armv8과 겹치며 진화한다

핵심: ARMv9.0-A는 Armv8.5-A의 기능을 바탕으로 ARMv9 전용 요구사항을 더한다. ARMv9.1~v9.4는 각각 Armv8.6~v8.9와 같은 연차의 공통 확장을 공유한다. 따라서 “v9에서 처음 생긴 기능”과 “v8.x에서 먼저 도입돼 v9 기준선에 포함된 기능”을 구분해야 한다.

Mandatory, Optional, 제품 구현을 분리한다

ARMv9.x는 단순한 기능 체크리스트가 아니다. 각 버전에는 필수 기능과 선택 기능이 섞여 있고, 일부 기능은 특정 조건이나 더 높은 Exception Level 구현 여부에 따라 달라진다. 실제 시스템 판단은 다음 네 층을 모두 통과해야 한다.

예: FEAT_SVE2, FEAT_SME, FEAT_RME, FEAT_MTE, FEAT_GCS라는 이름이 문서에 등장한다고 해서 특정 CPU에 전부 들어 있다는 뜻은 아니다. ID register의 필드, Linux HWCAP, 제품 TRM을 함께 기록해야 재현 가능한 사양이 된다.

Exception Level과 Security state는 서로 다른 축이다

Exception Level은 권한 높이를, Security state 또는 World는 접근 가능한 자원과 신뢰 경계를 나타낸다. “EL2이므로 Secure하다”처럼 두 축을 합쳐 이해하면 Realm과 가상화 구조를 설명할 수 없다.

PE(Processing Element)는 명령을 실행하는 아키텍처 처리 주체다. 같은 PE가 예외와 monitor 호출을 통해 EL과 World를 바꿀 수 있다. AArch64와 AArch32는 실행 상태이며, EL이나 World 자체가 아니다.

응용 프로그램의 요청이 kernel까지 가는 과정

가장 쉬운 그림부터 보면, EL0는 일반 사용자가 일하는 공간이고 EL1은 운영체제가 하드웨어를 대신 관리하는 공간이다. 응용 프로그램이 파일을 열거나 메모리를 요청하면 EL0에서 직접 장치를 만지지 않고 SVC 명령으로 EL1에 서비스를 요청한다.

CPU는 현재 명령 다음 주소를 ELR_EL1에, 이전 실행 상태를 SPSR_EL1에 저장한다. 예외 종류는 ESR_EL1에 기록하고, 주소 fault라면 FAR_EL1에 문제가 된 virtual address도 남긴다. 그 뒤 VBAR_EL1이 가리키는 vector table의 정해진 entry로 이동한다.

kernel은 register에 담긴 system-call 번호와 인자를 검사하고 작업을 수행한다. 끝나면 반환값을 register에 넣고 ERET를 실행한다. CPU는 ELR_EL1과 SPSR_EL1을 이용해 EL0의 다음 명령과 이전 상태를 복원한다.

핵심: EL 숫자가 높아지는 것은 “더 빠른 코드”가 된다는 뜻이 아니다. 더 넓은 제어 권한과 더 큰 책임을 가진 software로 실행 주체가 바뀐다는 뜻이다.

ARMv9의 AArch32는 EL0에서만 선택적이다

ARMv9-A는 privileged level에서 AArch32를 제거하고, AArch32 EL0 지원만 구현 선택으로 남겼다. 32비트 앱을 계속 실행하려면 CPU의 FEAT_AA32EL0, kernel의 compat 지원, 32비트 동적 로더와 라이브러리가 모두 필요하다.

1. lscpu의 CPU op-mode와 /proc/cpuinfo만으로 결론을 내리지 말고 kernel의 compat 설정을 함께 본다.
2. 혼합 CPU 시스템에서는 모든 online CPU가 안전하게 제공할 수 있는 기능만 kernel ABI로 노출될 수 있다.
3. 관련 Linux 동작은 asymmetric 32-bit support 문서와 함께 읽는다.

VA, IPA, PA와 translation regime

translation regime은 어느 EL·World의 주소 변환 규칙과 레지스터 집합을 사용하는지를 뜻한다. 일반 프로세스는 Stage 1에서 VA를 PA로 바꾸고, 가상머신 guest는 Stage 1에서 VA를 IPA로, host가 관리하는 Stage 2에서 IPA를 PA로 바꾼다.

Linux 구현 비교는 page-table format과 address-space switch에서 TTBR, ASID, PTE bit까지 이어진다.

4KB page에서 주소 하나가 번역되는 실제 예

주소 변환표는 거대한 전화번호부를 여러 권으로 나눈 것과 비슷하다. 48-bit virtual address와 4KB translation granule을 사용하는 일반적인 AArch64 구성을 예로 들면, 주소를 9-bit 색인 네 개와 12-bit page 내부 offset으로 나눈다. 각 9-bit 색인은 512개 entry 중 하나를 고른다.

47                39 38       30 29       21 20       12 11        0
+------------------+-----------+-----------+-----------+-----------+
| L0 index = 36    | L1 = 209  | L2 = 179  | L3 = 393  | off=0xabc |
+------------------+-----------+-----------+-----------+-----------+

VM 안에서는 이 결과가 바로 DRAM 주소가 아니라 IPA다. 다시 VTTBR_EL2에서 시작하는 Stage 2 walk가 IPA를 PA로 바꾸고, VTCR_EL2와 Stage 2 descriptor가 guest의 read/write/execute 권한을 제한한다. Realm에서는 그 뒤 GPC가 PA의 World 소유권까지 추가로 검사한다.

LPA2가 바꾸는 점: 4KB·16KB granule에서도 52-bit output address를 표현하도록 descriptor와 table walk 규칙을 확장한다. 단순히 주소 register 한 개가 길어지는 기능이 아니라 CPU, page-table 형식, kernel memory layout이 함께 지원해야 한다.

TLB 무효화는 범위와 공유 영역을 지정한다

page table을 고친 것만으로 다른 PE가 새 mapping을 즉시 보는 것은 아니다. 올바른 barrier, TLBI 범위, broadcast와 완료 대기를 결합해야 한다. ARMv9.7의 TLBI Domain은 시스템 전체 broadcast 대신 관련 도메인만 겨냥해 큰 시스템의 비용을 줄이는 방향이다.

실제 Linux shootdown 흐름은 TLBI와 IPI 비교 문서에 연결했다.

메모리 순서, LSE와 MOPS

cache/barrier 비교, atomic/locking 비교, Linux MOPS 문서에서 구현과 ABI를 더 깊게 볼 수 있다.

왜 barrier가 필요한지 두 CPU로 이해한다

CPU0이 data를 적고 “준비 완료” flag를 세우며, CPU1이 flag를 본 뒤 data를 읽는 상황을 생각하자. source code 순서만으로는 다른 CPU가 같은 순서로 관찰한다고 보장되지 않는다. store buffer, cache와 interconnect가 서로 다른 시점에 값을 전달할 수 있기 때문이다.

// CPU0                              // CPU1
data = 42;                           if (ready == 1)
ready = 1;                               print(data);  // 0을 볼 수도 있음

// CPU0                              // CPU1
data = 42;
store_release(&ready, 1);            if (load_acquire(&ready) == 1)
                                         print(data);  // 42 보장

LSE의 CAS·LDADD 계열은 원자 read-modify-write를 한 architecture 명령으로 표현한다. LSE가 없는 CPU에서는 LDXR/STXR exclusive loop로 같은 계약을 구현한다. 둘은 결과의 원자성은 같지만 contention 때 retry·공정성·성능이 다를 수 있다.

MOPS는 큰 memcpy()나 memset()의 준비·주 반복·마무리 단계를 architecture 명령으로 표현해 CPU 구현이 내부 복사 폭과 cache 동작을 최적화하도록 한다. overlap을 허용하는 memmove(), fault 재시작과 userspace 접근 검사는 별도 software 계약이므로 “MOPS가 있으면 모든 복사 함수를 한 명령으로 바꾼다”는 뜻은 아니다.

Coherency와 MPAM은 다른 문제다

cache coherency는 여러 agent가 같은 메모리의 일관된 값을 관찰하게 하는 규칙이다. MPAM은 cache capacity와 memory bandwidth 같은 공유 자원을 partition·monitor하는 제어 체계다. MPAM Domain과 MPAMv2는 시스템 규모와 자원 표현을 확장하지만, coherency를 대신하지 않는다.

Linux 소스로 내려가기

이 문서의 실행 상태와 주소 변환 개념을 실제 Linux v6.18.37 코드에서 이어서 읽는다. 진입 어셈블리부터 C handler, page fault와 page table 구성까지 호출 흐름을 끊지 않고 추적했다.

Arm 공식 자료

• ArchitectureDDI 0487: A-profile Architecture Reference Manual
• RegistersDDI 0601: A-profile System Registers
• v9.3A-profile architecture developments 2021
• v9.4A-profile architecture developments 2022
• v9.5A-profile architecture developments 2023
• v9.6A-profile architecture developments 2024
• v9.7A-profile architecture developments 2025