ARM64 주소 폭과 비정렬 접근을 구분해서 읽습니다

64비트 레지스터가 64비트 주소 공간을 보장하지는 않습니다

x1에 숫자가 들어 있다고 그 숫자를 모두 유효한 메모리 주소로 사용할 수 있는 것은 아닙니다. CPU가 구현한 주소 변환 기능, 커널 설정, 현재 변환 제어 레지스터, 실제 페이지 테이블이 함께 맞아야 합니다. 주소 폭으로 표현할 수 있는 범위와 보드에 설치된 RAM 용량도 구분해야 합니다.

“ARMv8-A의 PA는 최대 48비트”라는 말은 이후의 확장까지 포함한 설명으로는 부족합니다. ARMv8.2의 LPA는 64KB granule에서 52비트 PA·IPA를, LVA는 52비트 VA를 지원하는 기능입니다. 이후 LPA2를 사용하는 4KB·16KB 구성도 있습니다. 기능 이름이 비슷해도 VA와 PA 설정을 같은 것으로 취급하지 않습니다. 아래 내용은 가능한 모든 최신 확장을 나열하는 대신 Linux v6.18.37의 설정과 부팅 경로를 기준으로 설명합니다. ARM64 주소 폭·페이지 크기 설정

빌드 시 선택과 부팅 중 판정을 나누어 봅니다

CONFIG 이름은 빌드에 포함할 코드와 상수를 정합니다. IS_ENABLED(CONFIG_ARM64_LPA2)도 이 빌드의 설정을 판정하는 표현입니다. 반면 early_map_kernel의 cpu_has_lpa2()와 cpu_has_lva()는 부팅 CPU의 기능 판정입니다. 지원되지 않는 경우 va_bits를 VA_BITS_MIN으로 낮추는 분기가 실제 실행 중에 일어납니다. early_map_kernel VA_BITS_MIN·vabits_actual

cpu_has_lpa2는 ID_AA64MMFR0_EL1에서 현재 페이지 크기에 해당하는 TGran 필드를 읽어 판정합니다. cpu_has_lva는 ID_AA64MMFR2_EL1의 VARange 필드를 확인합니다. 두 helper 모두 커널의 feature override를 적용한 값을 사용하므로 아래의 “사용 가능”은 이 부팅 경로에서의 판정 결과를 뜻합니다. MMFR은 CPU가 제공하는 메모리 모델 기능을 나타내는 식별 레지스터이며 현재 task의 페이지 테이블 주소를 담는 TTBR과 역할이 다릅니다. cpu_has_lva·cpu_has_lpa2

Kconfig의 조합도 확인해야 합니다. 4KB·16KB에서 VA_BITS_52를 선택하면 PA_BITS_48의 조건을 만족하지 못하고 PA_BITS_52를 사용합니다. 64KB에서는 이 두 설정의 선택 조건이 다릅니다. 따라서 “VA를 52로 골랐으니 PA도 언제나 같은 이유로 52다”라고 모든 페이지 크기에 적용하지 않습니다. ARM64_PA_BITS_48·ARM64_PA_BITS_52·ARM64_LPA2

52비트로 빌드했는데 왜 47비트로 동작합니까?

CONFIG_ARM64_VA_BITS_52=y인 커널의 부팅 경로를 비교하겠습니다. 표는 VA 폭을 선택하는 동작이며, 그 밖의 CPU·부팅 요구 사항도 만족한다고 가정합니다. 주소 폭을 줄이는 처리가 모든 다른 호환성 문제까지 해결한다는 뜻은 아닙니다.

이 결과는 v6.18.37의 memory.h와 early_map_kernel을 함께 읽어 얻었습니다. 같은 태그의 개요 문서나 Kconfig 도움말에 있는 “48비트로 되돌아간다”는 간략한 표현만으로 16KB 구성까지 판단하면 47비트 조건을 놓칩니다. T1SZ의 비트 위치와 64−VA_BITS 계산은 pgtable-hwdef.h에서도 확인할 수 있습니다. 페이지 크기별 최소 VA 폭 기능 확인·T1SZ 변경·LPA2 초기 매핑 TCR_T1SZ·OFFSET·MASK

사용자 공간도 별도로 봅니다. 52비트 VA를 지원한다고 기존 프로그램의 모든 mmap 결과가 자동으로 높은 주소에 배치되는 것은 아닙니다. 일반 구성은 호환성을 위해 낮은 주소를 우선하고, 넓은 주소 범위를 요청하는 hint를 처리합니다. CONFIG_ARM64_FORCE_52BIT는 이 호환 동작을 바꾸는 시험용 옵션이므로 일반 운영 설정으로 권하는 항목이 아닙니다. 52비트 사용자 주소·FORCE_52BIT 도움말

주소의 최상위 비트 하나만 보고 사용자·커널을 나누지 않습니다

주소 그림에서 사용자 공간은 0으로, 커널 공간은 f로 시작하는 예를 자주 봅니다. 하지만 tagged pointer까지 포함해 “bit 63이 1이면 무조건 커널 주소”라고 설명하면 틀립니다. Linux의 AArch64 사용자 데이터 접근에는 상위 바이트를 주소 변환에서 무시하는 TBI0, Top Byte Ignore 설정이 사용됩니다.

이 예는 MTE tag 검사나 그 밖의 접근 제한이 걸리지 않는 Normal memory를 가정합니다. TBI가 동작해도 x1 안의 비트가 자동으로 0x0000000000012000으로 다시 쓰이는 것은 아닙니다. 주소 변환에 상위 바이트를 사용하지 않는 동작과 레지스터 값을 바꾸는 동작을 구분해야 합니다. Tagged virtual addresses

CPU가 tagged pointer로 읽을 수 있는 것과 그 포인터를 모든 시스템 호출에 그대로 넘길 수 있는 것은 별개의 규칙입니다. 커널이 사용자 데이터를 읽는 write 같은 호출에는 기본적으로 꺼져 있는 tagged address ABI의 활성화 조건이 있습니다. prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)로 요청하며 실패 여부도 확인합니다. 활성화한 뒤에도 mmap, brk, mremap의 new_address 등은 예외 규칙이 있으므로 모든 포인터의 tag가 허용된다고 일반화하지 않습니다. Tagged Address ABI의 조건과 예외

비정렬 LDR이 항상 예외를 일으키는 것은 아닙니다

4바이트 접근의 시작 주소가 4의 배수가 아니면 자연 정렬을 만족하지 않습니다. 0x10000에서 4바이트를 읽는 경우는 정렬되어 있고, 0x10001에서 읽는 경우는 비정렬입니다. 정렬되지 않았다는 사실과 CPU가 그 접근을 허용하는지는 구분해야 합니다. 자연 정렬과 이식성

A는 alignment check 제어 비트입니다. 이 표는 일반적인 LDR·STR 설명 범위이며 exclusive·acquire/release·atomic·SIMD 명령의 세부 조건까지 같은 표로 판정하지 않습니다. LDP·STP의 데이터 정렬은 두 레지스터의 총 크기가 아니라 각 요소 크기를 기준으로 보며, SP를 주소로 사용하는 경우의 별도 정렬 규칙도 구분해야 합니다. Armv8-A memory model guide · 12절 정렬

비정렬 접근이 허용되는 CPU에서도 C의 u8 포인터를 임의로 u32 포인터로 바꿔 역참조하는 습관은 이식성 문제를 만듭니다. 컴파일러의 타입·정렬 가정과 CPU 명령의 실행 가능 여부는 같은 조건이 아닙니다. 장치 register에는 장치가 정한 접근 폭과 readl/writel 계열의 I/O 접근 규칙도 필요합니다. 타입 변환·비정렬 helper 장치 I/O 접근 규칙

LDR 한 줄로 x0와 x1이 어떻게 바뀝니까?

다음은 little-endian 데이터 접근의 계산 예입니다. x1=0x0000000000010001이고, 그 주소부터 네 바이트가 11 22 33 44라고 정하겠습니다. Normal memory, 적용되는 A=0이며 매핑·권한·tag 문제와 동시 쓰기가 없다고 가정합니다. x0의 시작 값 0xdeadbeef12345678은 변화가 보이도록 선택한 임의의 숫자입니다.

ldr w0, [x1]

대괄호는 x1의 값이 가리키는 메모리를 읽는다는 표시입니다. 위 예의 결과는 접근이 성공했을 때의 상태이며, fault 경로의 레지스터 상태를 이 성공 결과로 표시하면 안 됩니다. A64 ISA guide 1.2 · W/X 관계와 load 주소 형식

커널에서 바이트 버퍼를 해석할 때는 의도를 코드에 적습니다

수신한 형식이 “첫 바이트는 종류, 뒤의 네 바이트는 little-endian 정수”라고 정해진 예입니다. buf는 커널이 읽을 수 있는 일반 메모리이며, len은 실제 유효 바이트 수, out은 유효한 출력 포인터라고 가정합니다. 장치가 아직 쓰고 있는 DMA 버퍼나 사용자 포인터를 그대로 받은 상태는 이 전제에 포함되지 않습니다.

#include <linux/errno.h>
#include <linux/unaligned.h>

static int read_payload_value(const u8 *buf, size_t len, u32 *out)
{
    if (len < 5)
        return -EINVAL;

    *out = get_unaligned_le32(buf + 1);
    return 0;
}

get_unaligned_le32의 le는 little-endian, 32는 읽을 값의 비트 수입니다. 이 helper는 정렬 조건을 알리고 endian을 변환하지만, 길이 검사·사용자 주소 검증·DMA 완료 확인·잠금은 수행하지 않습니다. 내부 구현은 컴파일러가 비정렬 배치를 알 수 있게 하며, 실제 기계 명령이 언제나 네 번의 1바이트 load로 나온다고 단정하지 않습니다. get_unaligned_le32 구현 helper 사용과 비용

동시에 다른 CPU나 장치가 같은 필드를 바꾼다면 별도의 소유권·동기화 규칙이 필요합니다. helper를 사용했다는 이유로 읽기가 원자적이거나 최신 값이라는 보장은 생기지 않습니다. 기존 DMA 소유권 글과 저장 순서 글에서 이 부분을 이어서 설명합니다.

fault가 나면 주소 폭·매핑·권한·정렬을 나누어 봅니다

Linux v6.18.37의 fault table은 데이터 alignment fault를 SIGBUS/BUS_ADRALN에 연결합니다. 네이티브 AArch64 사용자 접근에서 이 경로를 타면 do_bad_area가 그 신호를 전달하는 경로로 갑니다. 커널 모드 fault는 같은 사용자 신호 처리로 설명하지 않습니다. CONFIG_COMPAT_ALIGNMENT_FIXUPS가 켜져 있더라도 do_compat_alignment_fixup은 compat_user_mode 조건의 AArch32 사용자 접근에 대한 별도 경로이며, 모든 AArch64 비정렬 명령을 자동 복구하는 옵션이 아닙니다. do_alignment_fault·do_bad_area·fault_info

기존 페이지 fault 글은 VMA를 찾고 fault를 처리하는 경로를, 페이지 테이블 글은 주소와 속성 비트의 배치를 설명합니다. 여기서는 그 앞에서 구분해야 하는 주소 폭·tag·정렬 조건과 명령의 입력·출력 값을 보충했습니다. 예제는 계산으로 확인한 설명이며 실제 장치에서 실행한 결과는 아닙니다.

이어서 읽기

• 게스트의 Stage-1·Stage-2 fault
• DMA 버퍼의 소유권과 수명
• CPU와 장치가 관찰하는 저장 순서
• blog/kernel/armv9-mmu-kernel.html
• blog/kernel/arch-page-table-format-6-18-lts.html
• blog/kernel/page-fault-6-18-lts.html