ARMv9 CPU 문서·Toolchain·Linux 실전

설계 규칙과 실제 제품은 다르다

ARMv9는 CPU 한 종류의 이름이 아니라 여러 CPU가 지켜야 할 architecture 규칙이다. Cortex-A725와 Neoverse V3는 모두 ARMv9 계열일 수 있지만 cache 크기, pipeline, vector 구현과 전력 목표는 다르다.

따라서 “이 CPU가 ARMv9니까 SME를 쓸 수 있나?”라는 질문은 architecture 이름만으로 답할 수 없다. 제품 TRM의 구현 feature, Linux HWCAP, compiler target을 차례로 확인해야 한다.

문서마다 답하는 질문이 다르다

문제에 따라 첫 문서가 달라진다

실무 습관: 문서 제목뿐 아니라 issue/revision과 확인 날짜를 기록한다. /latest/ URL은 나중에 다른 issue를 가리킬 수 있고, erratum은 특정 rNpM revision에만 적용될 수 있다.

Cortex와 Neoverse 문서군

제품 이름만으로 architecture revision을 단정하지 않는다. 같은 ARMv9 세대에서도 mobile Cortex와 infrastructure Neoverse는 vector·cache·RAS·PMU·power 목표가 다르고, optional feature 구성도 다르다.

문서 공개 범위: 모든 제품이 같은 형태의 공개 TRM을 제공하지는 않는다. 제품 페이지의 Technical Documentation에서 최신 공개 문서를 확인하고, 접근 제한 문서를 공개 문서처럼 링크하지 않는다.

Core 바깥의 system component 문서

component TRM의 register offset은 block 내부 상대 주소다. 완성 SoC에서 실제 base address, clock, reset과 interrupt는 SoC manual·ACPI·Device Tree에서 찾아야 한다.

Software Optimization Guide를 architecture manual처럼 읽지 않는다

Optimization guide는 pipeline width, execution resource, branch와 cache 특성에 맞춘 권고를 제공한다. “정확히 이렇게 동작해야 한다”는 normative 계약이 아니라 특정 microarchitecture에서 성능을 얻기 위한 지침이다.

1. 먼저 정확성을 architecture와 ABI 문서로 확정한다.
2. target core의 optimization guide에서 instruction scheduling, alignment와 prefetch 권고를 찾는다.
3. compiler가 실제 생성한 assembly를 확인하고 perf stat·SPE로 병목을 측정한다.
4. big.LITTLE에서는 한 core 최적화가 다른 core에서 손해가 되지 않는지 별도로 측정한다.

CPU revision과 errata는 기능표 뒤에 붙는 부록이 아니다

같은 product name이라도 r0p0, r1p0처럼 revision이 다르면 erratum 적용 여부와 workaround 비용이 달라진다. Linux는 MIDR 범위와 firmware 정보를 보고 일부 기능을 비활성화하거나 alternative instruction을 적용한다.

-march, -mcpu, -mtune

# 넓은 ARMv9 기준선
cc -O2 -march=armv9-a app.c

# 특정 core에서만 실행할 image
cc -O2 -mcpu=cortex-a720 app.c

# ISA 호환 범위는 유지하고 scheduling만 조정
cc -O2 -march=armv9-a -mtune=neoverse-n2 app.c

같은 C 코드가 target에 따라 달라지는 예

배열 합계를 작성했다고 하자. compiler는 target이 명확하지 않으면 넓은 CPU에서 실행되도록 보수적인 명령을 고른다. 높은 -march 기준선을 주면 SVE2 같은 명령을 사용할 수 있고, -mcpu는 그 core의 pipeline에 맞춰 instruction 순서와 unroll 비용까지 조정한다.

int sum(const int *p, size_t n) {
    int total = 0;
    for (size_t i = 0; i < n; ++i)
        total += p[i];
    return total;
}

cc -O3 -march=armv8-a    -S sum.c -o sum-v8.s
cc -O3 -march=armv9-a    -S sum.c -o sum-v9.s
cc -O3 -mcpu=neoverse-n2 -S sum.c -o sum-n2.s

cc --version
grep -E "while|ld1|addv|ldr|add" sum-*.s

배포 binary 전체를 높은 -march로 빌드하면 낮은 CPU에서 program 시작 전에 illegal instruction이 날 수 있다. 공통 baseline 본체와 SVE2·SME 최적화 함수를 별도 object로 만들고 runtime dispatch하는 방식이 안전하다.

ACLE, AAPCS64와 AAELF64

명령이 존재해도 ABI가 없으면 library와 debugger가 상태를 교환할 수 없다. 특히 SVE·SME, PAC·BTI·GCS는 compiler attribute, ELF property, loader와 kernel ABI를 함께 확인한다.

HWCAP/HWCAP2와 process ABI

Linux arm64는 userspace가 안전하게 사용할 수 있는 feature를 auxiliary vector의 HWCAP bit로 공개한다. raw ID register를 직접 읽어 architecture feature를 추측하는 대신 kernel이 정규화한 ABI를 우선한다.

전체 대응표: Linux v6.18.37 원문 순서를 보존한 ELF HWCAP 전문 번역에 AT_HWCAP과 AT_HWCAP2의 모든 항목, 대응 ID register 조건이 표로 정리돼 있다. 이 페이지에서는 ARMv9 실전 흐름만 요약하고 전체 표를 중복 복제하지 않는다.

CPU feature registers와 SVE·SME·MTE·GCS 등 각 feature 문서를 함께 읽는다.

HWCAP으로 안전하게 최적화 함수를 고른다

/proc/cpuinfo 문자열을 직접 해석하기보다 kernel이 현재 process에 보장한 auxiliary vector를 사용한다. 아래 구조는 baseline 함수가 항상 존재하고, SVE2가 있을 때만 최적화 함수를 선택한다.

#include <sys/auxv.h>
#include <asm/hwcap.h>

static int sum_scalar(const int *p, size_t n);
static int sum_sve2(const int *p, size_t n);

int sum_auto(const int *p, size_t n) {
    unsigned long hwcap2 = getauxval(AT_HWCAP2);

    if (hwcap2 & HWCAP2_SVE2)
        return sum_sve2(p, n);
    return sum_scalar(p, n);
}

SME는 HWCAP만 확인하고 끝나지 않는다. process별 streaming vector length를 prctl(PR_SME_GET_VL)로 읽고, 함수 ABI가 streaming/ZA state를 올바르게 선언했는지도 확인해야 한다. MTE·GCS 역시 hardware bit에 더해 process opt-in과 loader policy가 필요하다.

Linux source 연결 지도

source 경로는 kernel revision에 따라 이동할 수 있다. 이 홈페이지의 번역 문서는 Linux v6.18.37 원문을 기준으로 하므로, 다른 kernel에서 볼 때는 symbol search로 재확인한다.

SVE 기능 하나를 문서에서 Linux source까지 추적한다

1. Architecture: DDI 0487·0601에서 ID_AA64PFR0_EL1.SVE, Z/P/FFR state와 trap control을 확인한다.
2. Boot detection: arch/arm64/kernel/cpufeature.c에서 ID field가 system capability로 등록되는 조건을 찾는다.
3. Kernel enable: CPACR_EL1.ZEN 또는 EL2 trap 설정이 언제 풀리는지 FPSIMD/SVE context code를 따라간다.
4. Userspace ABI: UAPI의 HWCAP_SVE, prctl VL interface와 signal context macro를 연결한다.
5. Runtime: application의 getauxval() 결과와 PR_SVE_GET_VL 반환값을 확인한다.
6. Context switch: task가 실제 SVE state를 사용한 뒤 kernel이 thread flag와 register ownership을 어떻게 바꾸는지 추적한다.

이 순서를 MTE·GCS·SME에도 반복하면 “CPU는 지원한다고 하는데 application에서는 왜 안 되지?”라는 문제를 architecture, firmware, kernel detection, process ABI 중 어느 층에서 막혔는지 분리할 수 있다.

FVP와 QEMU에서 기능별로 검증한다

Arm FVP는 architecture와 platform model을 firmware부터 검증하는 데 적합하고, QEMU는 자동화된 OS·userspace 기능 시험에 편리하다. 둘 다 특정 실제 Cortex의 성능을 재현하는 cycle-accurate benchmark 도구로 취급하지 않는다.

1. 실험하려는 feature와 EL 구성을 지원하는 FVP 또는 QEMU machine·CPU model을 고른다.
2. TF-A, UEFI 또는 direct kernel boot 중 firmware 경계를 시험 목적에 맞게 선택한다.
3. kernel config에서 KVM, SVE/SME, MTE, CCA, PMU와 device driver를 명시적으로 확인한다.
4. boot log의 ID register 해석과 HWCAP을 저장하고 작은 self-test로 instruction·ABI를 검증한다.
5. Realm은 RMM, host KVM, guest kernel과 attestation flow를 한 버전 조합으로 기록한다.

uname -a
lscpu
cat /proc/cpuinfo
dmesg | grep -Ei 'arm64|sve|sme|mte|gcs|kvm|rme|realm|errat'
perf list
getconf LONG_BIT

실제 탐지 출력은 이렇게 읽는다

재현 가능한 보고에는 CPU product와 MIDR, SoC·firmware version, kernel config·version, compiler version·option, HWCAP, vector length와 workload command line을 함께 남긴다.

Features : ... sve sve2 bti mte ...

sve2 있음  → kernel이 현재 system의 SVE2를 userspace에 공개
mte 있음   → instruction 가용성; 현재 process의 tag-check mode는 별도
bti 있음   → CPU 가용성; ELF property와 loader의 binary 보호는 별도

Linux v6.18.37 소스 분석 8편

Architecture 문서에서 얻은 개념을 실제 구현으로 검증하는 묶음이다. 각 페이지는 핵심 구조체, 호출 경로, 오류 분기, 재현 명령과 원문 source 좌표를 함께 제공한다.

공식 자료

• GNU ToolchainArm GNU Toolchain
• Linux feature statusArm Linux Kernel feature support
• ACLEArm C Language Extensions
• ABIAAPCS64·AAELF64 and Arm ABI specifications
• FVPArm Fixed Virtual Platforms
• First coresFirst Armv9 CPU cores
• ArchitectureDDI 0487: A-profile Architecture Reference Manual