커널 아키텍처 (Kernel Architecture)

리눅스 커널 아키텍처 심층 분석. x86_64, ARM64, RISC-V, MIPS 아키텍처별 부팅 과정(Boot Process), 주소 공간(Address Space), 특권 레벨, 커널 소스 트리 구조를 다룹니다.

x86_64, ARM64, RISC-V, MIPS 아키텍처별 커널 구조, 부팅 과정, 주소 공간 레이아웃을 상세히 다룹니다.

왜 커널 아키텍처를 알아야 할까요? 같은 C 코드라도 x86_64에서 문제없이 동작하던 코드가 ARM64에서 데이터 경쟁 버그로 이어지거나, RISC-V에서는 존재하지 않는 확장 명령어에 의존해 빌드 오류가 발생할 수 있습니다. 커널 드라이버·서브시스템 코드를 이식하거나, 부팅 실패를 디버깅하거나, 특권 레벨 경계를 넘는 보안 취약점(Vulnerability)을 분석할 때 아키텍처 지식이 없으면 근본 원인에 도달하기 어렵습니다. 이 문서는 네 아키텍처 각각의 특권 모델·메모리 주소 공간·부팅 경로·레지스터 체계를 커널 코드와 연결하여 설명합니다.

리눅스 커널 개요 (Linux Kernel Overview)

리눅스 커널은 1991년 Linus Torvalds가 처음 공개한 이래, 현재 세계에서 가장 널리 사용되는 운영체제 커널입니다. 서버, 데스크탑, 임베디드 기기, 스마트폰(Android), 슈퍼컴퓨터에 이르기까지 거의 모든 컴퓨팅 영역에서 동작합니다. 커널은 하드웨어와 사용자 공간(user space) 사이에서 추상화 계층 역할을 하며, 다음과 같은 핵심 기능을 담당합니다:

• 프로세스(Process) 관리 (Process Management) - 프로세스 생성, 스케줄링, 종료, 시그널(Signal) 처리
• 메모리 관리 (Memory Management) - 가상 메모리(Virtual Memory), 페이지 테이블(Page Table), 물리 메모리(Physical Memory) 할당
• 파일시스템 (Filesystem) - VFS(Virtual Filesystem)를 통한 다양한 파일시스템 지원
• 디바이스 드라이버 (Device Drivers) - 하드웨어 추상화 및 제어
• 네트워킹 (Networking) - TCP/IP 스택, 소켓(Socket), 패킷(Packet) 필터링
• 보안 (Security) - LSM, SELinux, capabilities, seccomp

모놀리식 vs 마이크로커널 (Monolithic vs Microkernel)

운영체제 커널 설계에는 크게 두 가지 접근 방식이 있습니다. 모놀리식 커널(Monolithic Kernel)은 모든 핵심 서비스(프로세스 관리, 메모리 관리, 파일시스템, 드라이버 등)가 하나의 커다란 커널 이미지 안에서 동일한 주소 공간에서 실행됩니다. 반면 마이크로커널(Microkernel)은 최소한의 기능만 커널에 포함하고 나머지는 사용자 공간 서버로 분리합니다.

리눅스는 모놀리식 커널입니다. 그러나 순수한 모놀리식이 아닌, 동적으로 적재 가능한 커널 모듈(Loadable Kernel Module, LKM)을 지원하여 모듈화의 유연성을 확보합니다. 이를 "모듈형 모놀리식(Modular Monolithic)" 커널이라고도 합니다. 커널 모듈에 대한 자세한 내용은 커널 모듈 문서를 참고하세요.

x86_64 아키텍처 (x86_64 Architecture)

x86_64(또는 AMD64, Intel 64)는 데스크탑과 서버 환경에서 가장 널리 사용되는 아키텍처입니다. x86의 32비트 아키텍처를 64비트로 확장한 것으로, 리눅스 커널에서 가장 오랫동안 지원해 온 아키텍처 중 하나입니다.

부팅 과정

x86_64 시스템의 부팅 과정은 펌웨어에서 시작하여 커널이 완전히 초기화될 때까지 여러 단계를 거칩니다. 현대 시스템에서는 UEFI(Unified Extensible Firmware Interface)가 표준이지만, 레거시 BIOS(Basic Input/Output System)도 여전히 지원됩니다.

커널의 x86_64 엔트리 포인트는 어셈블리(Assembly)로 작성되어 있습니다. 다음은 핵심 부팅 코드의 간략화된 예시입니다:

/* arch/x86/kernel/head_64.S - x86_64 커널 엔트리 포인트 (간략화) */

SYM_CODE_START_NOALIGN(startup_64)
    /* 세그먼트 레지스터 초기화 */
    xorl    %eax, %eax
    movl    %eax, %ds
    movl    %eax, %es
    movl    %eax, %ss
    movl    %eax, %fs
    movl    %eax, %gs

    /* 초기 페이지 테이블 설정 (Identity mapping) */
    leaq    early_top_pgt(%rip), %rax
    movq    %rax, %cr3

    /* 스택 포인터 설정 */
    leaq    init_thread_union+THREAD_SIZE(%rip), %rsp

    /* C 코드로 점프 */
    call    x86_64_start_kernel
SYM_CODE_END(startup_64)

주소 공간 레이아웃 (Address Space Layout)

x86_64에서는 48비트 가상 주소 공간(256TB)을 사용합니다. 이 공간은 사용자 영역(하위)과 커널 영역(상위)으로 명확하게 분리됩니다. 최신 커널에서는 5-level paging을 통해 57비트(128PB) 주소 공간도 지원합니다. 다음 다이어그램은 4-level paging 기준 주소 공간 레이아웃을 보여줍니다:

아키텍처별 주소 변환(Address Translation) 경로 비교

가상 주소(Virtual Address)를 물리 주소(Physical Address)로 변환하는 핵심 경로는 세 아키텍처 모두 유사하지만, 제어 레지스터(Register)와 페이지 테이블 포맷이 다릅니다. 아래 다이어그램은 세 아키텍처가 공유하는 변환 파이프라인과 아키텍처별 차이점을 한 화면에서 비교합니다.

세그먼테이션과 페이징 (Segmentation & Paging)

x86_64에서 세그먼테이션은 사실상 플랫 모델(flat model)로 사용됩니다. 모든 세그먼트의 베이스가 0이고 리미트가 최대값으로 설정되어, 세그먼테이션은 사실상 비활성화된 상태입니다. 그러나 GDT(Global Descriptor Table)는 여전히 존재하며, 커널/사용자 모드 전환과 TSS(Task State Segment)를 위해 필수적입니다.

페이징은 4단계 페이지 테이블을 사용합니다 (5단계 페이징은 CONFIG_X86_5LEVEL=y로 활성화):

• PGD (Page Global Directory) - 512 엔트리, CR3가 가리킴
• PUD (Page Upper Directory) - 512 엔트리
• PMD (Page Middle Directory) - 512 엔트리
• PTE (Page Table Entry) - 512 엔트리, 최종 물리 페이지(Page) 매핑(Mapping)

링 구조 (Protection Rings)

x86_64는 4개의 특권 레벨(Ring 0 ~ Ring 3)을 제공하지만, 리눅스에서는 실제로 Ring 0(커널 모드)와 Ring 3(사용자 모드) 두 레벨만 사용합니다. Ring 1과 Ring 2는 사용되지 않으며, 가상화(Virtualization) 확장(VT-x)에서는 Ring -1(VMX root mode)이라는 개념이 추가됩니다.

각 세그먼트 디스크립터에는 DPL(Descriptor Privilege Level) 필드가, 현재 실행 컨텍스트에는 CPL(Current Privilege Level) 값이 존재하며, CPU는 접근할 때마다 CPL ≤ DPL 조건을 검사합니다. 사용자 코드(CPL=3)가 커널 데이터(DPL=0)에 접근하면 #GP(General Protection) 예외가 발생하며, 이 메커니즘이 링 경계의 하드웨어적 강제력을 제공합니다. 자세한 보안 모델은 커널 보안 문서를 참고하세요.

MSR (Model-Specific Register)

MSR은 프로세서 모델별로 정의되는 특수 레지스터로, 성능 카운터, 전원 관리, 터보 부스트, virtualization 기능 등을 제어합니다. 리눅스 커널은 rdmsr/wrmsr 명령어로 MSR에 접근합니다.

/* arch/x86/include/asm/msr.h - MSR 접근 매크로 */

/* MSR 읽기 */
static inline u64 rdmsrl(unsigned int msr)
{
    u64 val;
    asm volatile("rdmsr" : "=A"(val) : "c"(msr));
    return val;
}

/* MSR 쓰기 */
static inline void wrmsrl(unsigned int msr, u64 val)
{
    asm volatile("wrmsr" : : "c"(msr), "A"(val));
}

/* 시스템 콜 진입 MSR 설정 예시 */
wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
wrmsrl(MSR_FMASK, 0);
wrmsrl(MSR_STAR, ((u64)__KERNEL_CS << 32) | (__USER_CS << 16));

x86_64 시스템 콜 Internals

x86_64 시스템 콜은 SYSCALL 명령어로 진입하며, MSR에 설정된 핸들러 주소로 점프합니다. 복귀는 SYSRET 명령어로 수행됩니다.

/* arch/x86/entry/entry_64.S - syscall 진입 흐름 (핵심 부분) */

/* 사용자 공간에서 SYSCALL */
    syscall                    /* RAX=syscall 번호, RDI, RSI, RDX, R10, R8, R9 = 인자 */
                                /* RIP → MSR_LSTAR에 저장된 주소 */

entry_SYSCALL_64:
    /* 레지스터 저장 (pt_regs 구조체) */
    push   %rax           /* RAX 저장 (syscall 번호) */
    cld
    push   %r15
    push   %r14
    push   %r13
    push   %r12
    push   %r11           /* RFLAGS 저장 */
    push   %r10
    push   %r9
    push   %r8
    push   %rcx           /* RIP 저장 (복귀 주소) */
    push   %r11          /* RFLAGS 재저장 */
    push   %rdx
    push   %rsi
    push   %rdi
    push   %rbp
    push   %rax           /* syscall 번호 */

    /* GS 기반 per-CPU 접근 시작 */
    SWAPGS                /* GS → 커널 GS로 교체 */

    /* 시스템 콜 테이블에서 핸들러 호출 */
    mov    %gs:cpu_tss.x86_tss.sp0, %rsp  /* 커널 스택으로 교체 */
        test   $0x7, %rcx        /* compat/native 판별 (반환 주소 하위 비트) */
    jz     1f
    swapgs
1:
    and    $-16, %rsp
    mov    %rsp, %gs:cpu_tss.x86_tss.sp1
    leaq   -RED_ZONE_SIZE(%rsp), %rsp
    push   %rsp
    push   %gs:cpu_tss.x86_tss.sp0

    /* syscall 테이블 호출 */
    mov    %rax, %rsp
    sub    $sizeof(struct pt_regs), %rsp
    mov    %rax, %rsp        /* pt_regs 빌드 */
    mov    %rax, %rsp, %rdi
    call   do_syscall_64
    /* 복귀 */
    ret

syscall_return:
    SWAPGS
    sysretq              /*Ring 3 복귀, RIP=RCX, RFLAGS=RDX */

x86_64 인터럽트 처리

x86_64의 인터럽트(Interrupt) 처리는 IDT(Interrupt Descriptor Table)과 LAPIC(Local APIC)가 담당합니다. 예외, IRQ, NMI 모두 IDT 게이트를 통해 처리됩니다.

256개 벡터 중 0~31번은 CPU 예외(#DF, #PF 등)에 예약되어 있고, 32번 이상은 외부 인터럽트에 할당됩니다. 커널은 FIRST_EXTERNAL_VECTOR(0x20)부터 IRQ 벡터를 배정하며, LAPIC 벡터는 FIRST_SYSTEM_VECTOR(0xF0) 이후 구간에서 사용합니다. 중요한 인터럽트는 TSS의 IST(Interrupt Stack Table)를 지정해 전용 스택에서 처리되도록 하여 일반 스택 손상 시에도 안정적으로 복구할 수 있습니다.

/* arch/x86/include/asm/desc_defs.h - IDT 게이트 구조 */

struct gate_struct {
    u16 offset_low;         /* offset [15:0] */
    u16 selector;           /* 코드 세그먼트 셀렉터 */
    u8  ist;                /* Interrupt Stack Table */
    u8  type_attr;         /* Type (0x6=Interrupt, 0x7=Trap) | DPL | P */
    u16 offset_mid;       /* offset [31:16] */
    u32 offset_high;       /* offset [63:32] */
    u32 reserved;       /* 보존 */
} __attribute__((packed));

/* IRQ 벡터 할당 */
#define FIRST_EXTERNAL_VECTOR    0x20  /* IRQ0 */
#define FIRST_SYSTEM_VECTOR  0xF0  /* LAPIC 등 시스템 벡터 */

VMX (Virtualization) Internals

VMX는 Intel의 하드웨어 가상화 확장입니다. VMX root mode(Ring -1)와 VMX non-root mode(게스트)를 지원합니다.

/* arch/x86/include/asm/vmx.h - VMX 주요 MSR */

#define MSR_IA32_VMX_BASIC             0x480
#define MSR_IA32_VMX_PINCTRL         0x481
#define MSR_IA32_VMX_PROCCTRL        0x482
#define MSR_IA32_VMX_EXITCTRL       0x483
#define MSR_IA32_VMX_ENTRYCTRL        0x484

/* VMCS 필드 */
#define VMCS_GUEST_RIP               0x00001602
#define VMCS_GUEST_RSP               0x00001603
#define VMCS_GUEST_CR3               0x00001604
#define VMCS_HOST_CR3               0x00001902
#define VMCS_HOST_RSP               0x00001903
#define VMCS_HOST_RIP               0x00001904

/* VMX 실행 상태 (VMCS field: VMCS_GUEST_ACTIVITY_STATE) */
#define VMX_GUEST_STATE_ACTIVE       0
#define VMX_GUEST_STATE_HLT          1
#define VMX_GUEST_STATE_SHUTDOWN      2
#define VMX_GUEST_STATE_WAIT_SIPI     3

/* arch/x86/include/asm/segment.h - GDT 세그먼트 정의 */

/*
 * x86_64 GDT 레이아웃 (간략화):
 *  Entry 0: NULL 디스크립터 (CPU 요구사항)
 *  Entry 1: Kernel 32-bit Code Segment (호환 모드용)
 *  Entry 2: Kernel 64-bit Code Segment
 *  Entry 3: Kernel Data Segment
 *  Entry 4: User 32-bit Code Segment (ia32 compat)
 *  Entry 5: User Data Segment
 *  Entry 6: User 64-bit Code Segment
 *  Entry 7+: TSS, TLS 등
 */
#define GDT_ENTRY_KERNEL32_CS       1
#define GDT_ENTRY_KERNEL_CS         2
#define GDT_ENTRY_KERNEL_DS         3
#define GDT_ENTRY_DEFAULT_USER32_CS 4
#define GDT_ENTRY_DEFAULT_USER_DS   5
#define GDT_ENTRY_DEFAULT_USER_CS   6

/* 세그먼트 셀렉터 값 (index << 3 | RPL) */
#define __KERNEL32_CS (GDT_ENTRY_KERNEL32_CS * 8)      /* 0x08, Ring 0 */
#define __KERNEL_CS   (GDT_ENTRY_KERNEL_CS * 8)        /* 0x10, Ring 0 */
#define __KERNEL_DS   (GDT_ENTRY_KERNEL_DS * 8)        /* 0x18, Ring 0 */
#define __USER32_CS   (GDT_ENTRY_DEFAULT_USER32_CS * 8 + 3) /* 0x23, Ring 3 */
#define __USER_DS     (GDT_ENTRY_DEFAULT_USER_DS * 8 + 3)   /* 0x2B, Ring 3 */
#define __USER_CS     (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3)   /* 0x33, Ring 3 */

ARM64 아키텍처 (ARM64 / AArch64 Architecture)

ARM64(AArch64)는 모바일 기기부터 서버, 슈퍼컴퓨터까지 빠르게 확산되고 있는 아키텍처입니다. Apple Silicon(M1/M2/M3/M4), AWS Graviton4, Ampere Altra/AmpereOne 등 고성능 ARM64 프로세서가 서버 시장에서도 중요한 위치를 차지하고 있습니다.

ARM64는 x86_64와 비교해 세 가지 설계 철학의 차이를 먼저 이해해야 합니다. 첫째, RISC 기반으로 명령어 수가 적고 길이가 고정(4바이트)되어 있어 파이프라인 설계가 단순합니다. 둘째, x86의 Ring 0~3 대신 Exception Level(EL0~EL3)이라는 4단계 모델을 사용하며, TrustZone(EL3)으로 보안 세계와 일반 세계를 하드웨어 수준에서 격리합니다. 셋째, 메모리 순서가 약한 모델(Weak Ordering)이어서 명시적 배리어 없이는 멀티코어 환경에서 쓰기 순서가 보장되지 않습니다. x86에서 포팅한 코드에 배리어가 빠져 있어도 x86 하드웨어의 강한 메모리 순서 덕분에 동작하던 코드가, ARM64에서는 산발적인 데이터 경쟁 버그로 나타나는 것이 가장 흔한 포팅 실수입니다.

Exception Level (EL0 ~ EL3)

ARM64는 x86의 Ring 구조 대신 Exception Level(EL)이라는 4단계 특권 모델을 사용합니다. 각 EL은 명확한 역할을 가지며, 하위 EL에서 상위 EL로의 전환은 exception 발생 시에만 가능합니다.

• EL0 (User/Application) - 사용자 애플리케이션이 실행되는 레벨. 가장 낮은 특권.
• EL1 (OS Kernel) - 운영체제 커널이 실행되는 레벨. 리눅스 커널은 여기서 동작합니다.
• EL2 (Hypervisor) - 하이퍼바이저(Hypervisor)가 실행되는 레벨. KVM이 이 레벨을 사용합니다.
• EL3 (Secure Monitor) - ARM TrustZone의 Secure Monitor. 보안 세계와 일반 세계 전환을 관리합니다.

ARM64 시스템 레지스터

ARM64는 x86의 MSR과 유사하게 MSR/MRS 명령어로 접근하는 시스템 레지스터를 사용합니다. 시스템 레지스터는SCTLR_ELx, TTBR0_EL1, TCR_EL1 등 EL별로 나뉩니다.

/* ARM64 시스템 레지스터 접근 예시 */

/* MMU 활성화 (SCTLR_EL1.M = 1) */
    mrs    x0, sctlr_el1
    orr    x0, x0, #1        /* M 비트 */
    msr    sctlr_el1, x0

/* 페이지 테이블 베이스 설정 (TTBR0_EL1) */
    msr    ttbr0_el1, x0

/* 인터럽트 허용 (DAIF 클리어) */
    msr    daif, #0

/* 현재 EL 확인 */
    mrs    x0, currentel
    lsr    x0, x0, #2        /* 0=EL0, 1=EL1, 2=EL2, 3=EL3 */

GIC (Generic Interrupt Controller)

ARM64 시스템의 인터럽트 컨트롤러는 GIC(Generic Interrupt Controller)입니다. GICv2, GICv3, GICv4 버전이 있으며, 버전별로 프로그래밍 인터페이스가 다릅니다.

/* drivers/irqchip/irq-gic-v3.c - GICv3 초기화 핵심 */

/* Redistributor베이스 주소 */
#define GICR_CTLR        0x0
#define GICR_TYPER        0x08
#define GICR_PIDR2       0xFE8

/* Interrupt ID Ranges */
#define GIC_SPI_OFFSET     32    /* SPI: 32~1019 */
#define GIC_PPI_OFFSET      16    /* PPI: 16~31 */
#define GIC_SGI_OFFSET      0      /* SGI: 0~15 */

/* GICD_IROUTERn - Interrupt Routing Register */
/* GICD_IROUTERn 경유로 각 SPI를 대상 redistributor에 라우팅 */

static int gic_set_affinity(struct irq_data *d, const cpumask *mask, bool force)
{
    /* GICv3: GICD_IROUTERn(16바이트 스트라이드)로 대상 CPU 라우팅 */
    void __iomem *router = gic_dist_base() + GICD_IROUTER_BASE +
                       (irq(d) * GICD_IROUTER_STRIDE);
    u32 target = cpu_logical_map(cpumask_first(mask));
    writel_relaxed(target, router);          /* Affinity 0-3 필드 */
    return IRQ_SET_MASK_OK;
}

ARM64 KVM 가상화

ARM64에서 KVM은 하이퍼바이저로 동작하며, EL2에서 실행됩니다. CONFIG_KVM, CONFIG_ARM64_VHE 등의 옵션이 있습니다.

• VHE (Virtualization Host Extensions): 커널이 EL2에서 직접 실행되어 가상화 오버헤드를 크게 줄임
• 비VHE: 분리된 커널/VMM 필요 (전통적 구성)

/* arch/arm64/kvm/arm.c - KVM 초기화 */

static int kvm_init(void)
{
    int ret;

    /* Hyp 시스템 레지스터 초기화 */
    kvm_linux_set_id_aa64pfr0(0);
    kvm_linux_set_id_aa64pfr1(0);
    kvm_linux_set_id_aa64zfr0(0);

    /* 2단계 페이지 테이블 활성화 */
    if (has_vhe()) {
        kvm_init_el2_stuff();
    }

    return 0;
}

/* VM 생성 시 2단계 페이지 테이블 설정 */
static int kvm_init_stage2(struct kvm *kvm)
{
    phys_addr_t pgd = __get_free_pages(GFP_KERNEL, VTCR_SIZE_BITS);

    /* VTCR_EL2: Stage-2 변환 제어 필드(SL0, IPS 등) 설정 */
    u64 vtcr = kvm_vtcr_el2_calc(mmu);
    write_sysreg(vtcr, vtcr_el2);

    /* VTTBR_EL2: Stage-2 페이지 테이블 베이스 주소 기록 */
    write_sysreg(pgd, vttbr_el2);
    return 0;
}

ARM64 보안 확장 (PAC, BTI, MTE, GCS)

ARM64는 다양한 하드웨어 기반 보안 확장을 제공합니다.

/* PAC (Pointer Authentication) 예시 */

/* PACIA 키 생성 (A 키 사용) */
    pacia  x0, x1, x2    /* x0 = x0 | PAC(x1, x2) */

/* PACIB (B 키 사용) */
    pacib  x0, x1, x2

/* AUTIA 복호화 검증, 실패 시 BRK */
    autia  x0, x1, x2

/* BTI (Branch Target Identification) */
    /* BTI 테스트 */
    bti    c             /* call-friendly 랜딩 패드 */
    bti    j             /* jump-friendly 랜딩 패드 */
    bti    cj            /* call/jump 모두 허용 */

/* MTE (Memory Tagging) */
    irg    x0, x1           /* x1을 x0에 복사하고 상위 바이트에 랜덤 태그 생성 */
    stg    x0, [x1]        /* Store tag with data */
    ldg    x2, [x1]        /* Load tag to x2 */
    cfinv  x0              /* Compare and invalidate if mismatch */

ARM64 부팅 과정

ARM64의 부팅 과정은 x86과 상당히 다릅니다. 대부분의 ARM64 시스템은 Device Tree(DT)를 사용하여 하드웨어 구성 정보를 커널에 전달합니다. 부팅 프로토콜은 커널 이미지의 시작점에 명시된 규약을 따릅니다.

MMIO와 Device Tree

ARM 시스템에서 하드웨어 레지스터에 접근하는 기본 방식은 MMIO(Memory-Mapped I/O)입니다. x86의 Port I/O(in/out 명령어)와 달리, ARM은 메모리 주소에 하드웨어 레지스터를 매핑하고 일반 메모리 접근 명령어(LDR/STR)로 제어합니다.

Device Tree(DT)는 하드웨어 구성을 기술하는 데이터 구조입니다. DTS(Device Tree Source) 파일로 작성하고, DTC(Device Tree Compiler)로 DTB(Device Tree Blob) 바이너리로 컴파일합니다. 커널은 부팅 시 DTB를 파싱하여 하드웨어 정보를 인식합니다.

/* 간단한 Device Tree 예시 (arch/arm64/boot/dts/example.dts) */

/dts-v1/;

/ {
    model = "Example ARM64 Board";
    compatible = "vendor,example-board";

    #address-cells = <2>;
    #size-cells = <2>;

    memory@80000000 {
        device_type = "memory";
        reg = <0x0 0x80000000 0x0 0x40000000>; /* 1GB @ 0x80000000 */
    };

    uart0: serial@9000000 {
        compatible = "arm,pl011", "arm,primecell";
        reg = <0x0 0x09000000 0x0 0x1000>; /* MMIO 영역 */
        interrupts = <0 33 4>;             /* GIC SPI INTID 33, level-triggered */
        clock-names = "uartclk", "apb_pclk";
    };

    gic: interrupt-controller@8000000 {
        compatible = "arm,gic-v3";
        #interrupt-cells = <3>;
        interrupt-controller;
        reg = <0x0 0x08000000 0x0 0x10000>,  /* GICD */
              <0x0 0x080A0000 0x0 0xF60000>; /* GICR */
    };
};

ARM64 메모리 순서 모델 (Memory Ordering Model)

ARM64는 x86_64와 달리 약한 메모리 순서 모델 (Weak Ordering)을 채택합니다. CPU는 메모리 읽기/쓰기 연산의 실행 순서를 하드웨어 레벨에서 보장하지 않으며, 컴파일러도 메모리 접근의 순서를 변경할 수 있습니다. 이 특성이 x86에서만 개발한 코드를 ARM64에 포팅할 때 산발적인 데이터 경쟁 버그(Data Race)로 나타나는 근본 원인입니다.

ARM64의 메모리 재순서화(Reordering)는 세 가지 차원에서 발생할 수 있습니다:

• 컴파일러 재순서화 — 컴파일러 최적화 과정에서 C 코드의 메모리 접근 순서가 변경됨
• CPU 하드웨어 재순서화 — ARM64 CPU가 동시에 여러 메모리 요청을 발행할 때, 완료 순서가 코드 순서와 다를 수 있음
• 시스템/커널 재순서화 — DMA, IOMMU, 캐시 코어리티(Coherency) 등 시스템 레벨에서 메모리 접근이 재배치(Relocation)될 수 있음

이러한 재순서화를 방지하기 위해 ARM64는 메모리 배리어(Memory Barrier) 명령어를 제공합니다. 배리어는 종류에 따라 범위가 다르며, 각 배리어는 다른 상황에서 사용됩니다:

/* ARM64 메모리 배리어 명령어 예시 */

/* DMB ISH — Inner Shareable Domain Data Memory Barrier */
      dmb      ish         /* 공유 메모리 접근 순서 보장 */

/* DMB SY — Full System Barrier (가장 강함) */
      dmb      sy          /* 모든 메모리 접근 순서 보장 */

/* DSB — Data Synchronization Barrier */
      dsb      sy          /* DMB는 접근 순서만, DSB는 이전 모든 접근 완료 보장 */

/* ISB — Instruction Synchronization Barrier */
      isb                  /* 파이프라인 플러시, 명령어 변경 후 사용 */

커널 코드에서 가장 많이 사용되는 배리어는 smp_mb()/smp_rmb()/smp_wmb()입니다. 각각 dmb ish/dmb ishld/dmb ishst로 확장되어 Inner Shareable 도메인 내 메모리 접근 순서를 보장하며, 완전한 시스템 동기화가 필요한 곳에는 dsb sy 계열을 사용합니다. arch/arm64/include/asm/barrier.h에서 정의됩니다:

/* arch/arm64/include/asm/barrier.h (핵심 발췌) */

/* 기본 배리어 원시 명령어 래퍼 */
#define isb()      asm volatile("isb" : : : "memory")
#define dmb(opt)   asm volatile("dmb " #opt : : : "memory")
#define dsb(opt)   asm volatile("dsb " #opt : : : "memory")

/* 전체 배리어 (컴파일러 + 하드웨어) */
#define __mb()     dsb(sy)
#define __rmb()    dsb(ld)
#define __wmb()    dsb(st)

/* SMP 배리어 — Inner Shareable 도메인 내 접근 순서만 보장 */
#define __smp_mb()   dmb(ish)
#define __smp_rmb()  dmb(ishld)
#define __smp_wmb()  dmb(ishst)

x86_64는 TSO(Totally Store Order) 모델이라 smp_mb()는 하드웨어 펜스 없이 컴파일러 배리어만으로 충분하지만, mb()는 여전히 mfence 명령어를 발행합니다. 반면 ARM64에서는 이 모든 매크로가 실제 배리어 명령어로 확장됩니다. 따라서 x86-only 관습으로 배리어를 생략한 코드는 ARM64에서 데이터 경쟁(Data Race)으로 연결될 수 있습니다. 반드시 아키텍처 독립 배리어 매크로를 사용해야 합니다:

/* include/linux/compiler.h — READ_ONCE / WRITE_ONCE */

/* 컴파일러 재순서화 방지: 단일 로드/스토어를 강제 (단순화된 표현) */
/* 실제 정의는 include/linux/compiler.h — asm_volatile 기반 컴파일러 배리어 + volatile 캐스트 */
#define READ_ONCE(x) \
    ({ typeof(x) _v_; asm_volatile("" : : "m"(RAW_MEMORY(x))); (_v_ = (x)); _v_; })

#define WRITE_ONCE(x, v) \
    ({ asm_volatile("" : "m"(RAW_MEMORY(x))); ((x) = (v)); });

#define WRITE_ONCE(x, v) \
    __atomic_store_n(&(x), (v), __ATOMIC_SEQ_CST)

/* 예: flags 변수의 safe access */
static void safe_flag_clear(volatile unsigned long *flags)
{
      WRITE_ONCE(*flags, 0);
      smp_wmb();   /* flags 변경이 다른 메모리 쓰기보다 먼저 완료됨 */
}

static bool safe_flag_test(volatile unsigned long *flags)
{
      bool result = READ_ONCE(*flags);
      smp_rmb();   /* flags 읽기가 이후 메모리 읽기보다 먼저 완료됨 */
      return result;
}

ARM64 메모리 순서 모델은 또한 LoadLoad, LoadStore, StoreLoad, StoreStore 재순서화의 네 가지 조합을 배리어 종류별로 제어할 수 있습니다. DMB ISH는 네 타입 모두를 방지하고, DMB ISHLD는 로드 관련(LoadLoad/LoadStore) 순서를, DMB ISHST는 스토어 관련 (StoreStore/StoreLoad) 순서를 보장합니다. 각 상황에 맞는 배리어를 선택하면 성능 최적화가 가능합니다.

MTE 커널 지원 (Memory Tagging Extension for Kernel)

ARMv8.5-A부터 도입된 MTE(Memory Tagging Extension)는 16바이트 그라눌(Granule) 단위로 4비트 태그를 메모리 메타데이터에 저장하여, 버퍼 오버플로우, use-after-free, heap corrosion 등의 메모리 안전성 오류를 하드웨어 레벨에서 감지하는 기능입니다. Linux 커널 5.16부터 사용자 공간 MTE를, 6.6부터 하드웨어 태그 기반 KASAN(KERNEL MTE)을 지원하기 시작했습니다.

Kernel MTE가 활성화되면, 커널 힙 할당자(SLAB/SLUB allocator)는 각 객체(Object)에 의사난수 태그를 할당하고, 객체 접근 시 하드웨어가 태그를 검증합니다. 태그 불일치 시 Tag Check Fault가 발생하며, 이를 통해 버퍼 오버플로, use-after-free, heap corruption 등의 메모리 안전성 위반을 사전에 감지할 수 있습니다. MTE는 KASAN(Kernel Address Sanitizer)과 상호 보완적인 진단 수단입니다: KASAN이 더 큰 오버헤드를 가지지만 더 넓은 범위(스택, 전역 변수 포함)를 커버하는 반면, MTE는 하드웨어 기반이므로 런타임 오버헤드가 훨씬 작지만 힙 객체만 커버합니다.

/* arch/arm64/mm/fault.c — MTE Tag Check Fault 처리 (실제 소스 발췌) */

/* EC 0x15(Tag Check Fault)의 ESR_ELx.ESS 필드([14:12]) 인코딩 */
#define ESR_ESC_OOOVRT    0b000  /* Out-of-range virtual address */
#define ESR_ESC_OOSRLD    0b001  /* Out-of-shareability load */
#define ESR_ESC_GRANULE   0b010  /* Granule size mismatch */
#define ESR_ESC_MISCON    0b011  /* Misconfigured */

/* 사용자 공간 동기 태그 체크 폴트 핸들러 */
static int do_tag_check_fault(unsigned long far, unsigned long esr,
                              struct pt_regs *regs)
{
    /* 태그 체크 폴트는 FAR_EL1 비트 63:60이 UNKNOWN일 수 있음 */
    if (!cpus_have_cap(ARM64_MTE_FAR))
        far = (__untagged_addr(far) & ~MTE_TAG_MASK) | (far & MTE_TAG_MASK);

    do_bad_area(far, esr, regs);
    return 0;
}

/* 폴트 디스패치 테이블 등록 (EC/FSC → 핸들러 매핑) */
static const struct fault_info fault_info[] = {
    ...
    { do_tag_check_fault, SIGSEGV, SEGV_MTESERR, "synchronous tag check fault" },
};

/* EL1 동기 태그 폴트: do_mem_abort() 경유 → TCF 비활성화 후 복구 */
if (is_el1_mte_sync_tag_check_fault(esr)) {
    do_tag_recovery(addr, esr, regs);
    return;
}

/* ARM64 MTE 관련 명령어 */

/* IRG — Issue Random Tag: x1을 x0에 복사하고 상위 바이트에 랜덤 태그 생성 */
      irg    x0, x1

/* GMI — Generate and Move Immediate: immediate 값을 태그로 설정 */
      gmi    x0, #5

/* MSTT — Move and Set Tag: x0의 태그를 [x1] 메모리 태그에 복사 */
      mstt   x0, [x1]

/* LDGT — Load Granule Tag: [x1]의 128바이트 블록 태그를 x0에 로드 */
      ldgt   x0, [x1]

/* STGT — Store Granule Tag: x2의 태그를 [x1]의 128바이트 블록에 저장 */
      stgt   x2, [x1]

/* MTE 태그 검사 활성화: SCTLR_EL1.TCF 필드(bit [1:0]) 설정 */
      mrs    x0, sctlr_el1
      orr    x0, x0, #0x3       /* TCF=ASYMM 또는 SYNC 등 모드 선택 */
      msr    sctlr_el1, x0
      isb                          /* 시스템 레지스터 갱신 동기화 */

/* CFINV — Compare and Invalidate: x0의 태그를 무효화(0으로 설정) */
      cfinv  x0

MTE를 커널 컴파일에 적용하려면 다음 두 가지 방법이 있습니다:

• Build-time MTE: CONFIG_KASAN_HW_TAGS=y를 설정하여 커널 이미지를 하드웨어 태그 기반 KASAN으로 빌드. 커널 실행 시 mte=on 파라미터로 활성화.
• Runtime MTE: 커널 부트 파라미터 mte=on|koff|ukon으로 태그 검사(Tag Checking)와 태그 생성(Tag Allocation)을 독립적으로 제어할 수 있습니다.

# MTE 커널 빌드 설정

# .config에 MTE 활성화
make menuconfig
# → Kernel hacking → [*] KASAN Hardware Tags Support

# 또는 커맨드 라인에서 설정
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
     CONFIG_ARM64_MTE=y CONFIG_KASAN_HW_TAGS=y

# MTE 활성화 부트 파라미터 추가 (GRUB 또는 Device Tree)
# /etc/default/grub — GRUB_CMDLINE_LINUX_DEFAULT 에 추가
mte=on      # 태그 검사+생성 모두 활성화 (기본)
mte=koff    # 커널 MTE 비활성화
mte=ukon    # 사용자 MTE만 활성화

# MTE 지원 여부 확인 (cpuinfo 기능 문자열)
grep -w mte /proc/cpuinfo

MTE 관련 기능은 릴리스마다 점진적으로 개선되고 있으며, KASAN HW 태그 연동, Hugepage 태그 관리, 태그 저장 오버헤드 절감 등이 최근 릴리스에서 지속적으로 반영되었습니다(구체 항목은 릴리스 노트 참조).

MTE 커널 사용 시 Tag Check Fault가 발생하면 커널은 해당 faults의 종류에 따라 다음 중 하나를 수행합니다:

• Abort (기본) — 커널 패닉 발생. 심각한 메모리 안전성 위반 시 사용.
• Signal — 사용자 공간 MTE fault 시 SIGSEGV 또는 SIGBUS 시그널을 프로세스에 전송.
• Ignore — debug 모드에서 태그 mismatch를 로그만 기록하고 정상으로 계속.

MTE의 태그는 16바이트(Granule) 단위로 할당되며, 4비트 태그이므로 2^4 = 16개의 서로 다른 태그값을 가질 수 있습니다. 커널 MTE는 SLUB 할당자(SLAB allocator)와 연동되어 각 객체에 대해 의사난수 기반의 고유 태그값을 할당합니다.

RISC-V 아키텍처 (RISC-V Architecture)

RISC-V는 UC Berkeley에서 설계한 오픈 소스 ISA(Instruction Set Architecture)로, 라이선스 비용 없이 누구나 자유롭게 구현할 수 있습니다. 리눅스 커널은 RISC-V를 공식적으로 지원하며, SiFive, StarFive, SpacemiT K1 등의 칩에서 이미 리눅스가 동작합니다.

특권 모드 (Privilege Modes)

RISC-V는 3단계 특권 모드를 정의합니다. 각 모드는 CSR(Control and Status Register) 접근 권한이 다릅니다.

• Machine Mode (M-mode) - 가장 높은 특권. 하드웨어에 직접 접근 가능. SBI 구현(OpenSBI)이 여기서 동작합니다.
• Supervisor Mode (S-mode) - 리눅스 커널이 실행되는 모드. 페이지 테이블과 인터럽트(Interrupt)를 관리합니다.
• User Mode (U-mode) - 사용자 애플리케이션 모드. 가장 낮은 특권.

RISC-V CSR (Control and Status Register)

RISC-V는 특권 모드별로 다른 CSR을 사용합니다. M-mode, S-mode, U-mode 각각 접근 가능한 CSR이 정의됩니다.

모드 간 전환은 ecall(하위 모드에서 상위 모드로 진입), mret/sret(상위 모드에서 하위로 복귀) 명령어로 이루어지며, 예외·인터럽트의 위임 대상 모드는 medeleg/mideleg CSR로 제어됩니다.

/* RISC-V CSR 접근 예시 */

/* sstatus 읽기 */
    csrr   t0, sstatus

/* sstatus의 SIE 비트(Set Interrupt Enable) */
    csrsi   sstatus, 0x2

/* sstatus의 SIE 비트 클리어 */
    csrci   sstatus, 0x2

/* medeleg 설정: U-mode 예외를 S-mode로 위임 */
    csrw    medeleg, t0

/* satp (주소 변환 테이블) 설정 - Sv48의 경우 */
    /* PPN[43:0] = 페이지 테이블 물리 프레임 번호 */
    csrw    satp, t0

RISC-V 페이지 테이블 (Sv39/Sv48/Sv57)

RISC-V Privileged Architecture 사양은 Sv39, Sv48, Sv57 세 가지 표준 가상 메모리 스킴을 정식 정의합니다. 리눅스는 Sv48 (4-level)을 주로 사용합니다.

• Sv39: 3-level, 512GB 주소 공간 (페이지 크기 1GB, 2MB, 4KB)
• Sv48: 4-level, 256TB 주소 공간, 가장 일반적
• Sv57: 5-level, 128PB 주소 공간 (v5.18부터 메인라인 지원)

/* arch/riscv/include/asm/pgtable.h - 페이지 테이블 형식 */

#define PTE_SHIFT     10       /* PTE Bits 수 */
#define PTE_PFN_SHIFT 10       /* PFN 시작 비트 */
#define PTE_VALID    _(1 << 0)
#define PTE_READ    _(1 << 1)            /* Read enable */
#define PTE_WRITE   _(1 << 2)      /* Write */
#define PTE_EXEC    _(1 << 3)      /* Execute */
#define PTE_USER     _(1 << 4)      /* User accessible */
#define PTE_GLOBAL   _(1 << 5)      /* Global */
#define PTE_ACCESS   _(1 << 6)      /* Accessed */
#define PTE_DIRTY    _(1 << 7)      /* Dirty (Svadu 확장) */

/* Sv48 4-level 페이지 테이블 */
/* VA를 9비트 인덱스 4개로 분할 → L3→L2→L1→L0 테이블 → 4KB 페이지 */

CLINT와 PLIC (인터럽트 컨트롤러)

RISC-V의 인터럽트는 두 가지 유형으로 나뉩니다:

• CLINT (Core Local Interrupt): 소프트웨어 인터럽트(SWINT), 타이머 인터럽트, IPI (코어당 1세트)
• PLIC (Platform-Level Interrupt Controller): 외부 디바이스 IRQ, 전역

/* drivers/irqchip/irq-sifive-plic.c - PLIC */

/* PLIC 메모리 맵 오프셋 (drivers/irqchip/irq-sifive-plic.c 기준) */
#define PLIC_PRIORITY_BASE       0x000000  /* source priority: source_id × 4 */
#define PLIC_PENDING_BASE        0x001000
#define PLIC_CONTEXT_ENABLE_BASE 0x002000  /* + context × 0x80 */
#define PLIC_CONTEXT_BASE        0x200000  /* + context × 0x1000 */
#define PLIC_CLAIM_OFFSET        0x0       /* 컨텍스트 윈도우 내 claim */
#define PLIC_THRESHOLD_OFFSET    0x4       /* 컨텍스트 윈도우 내 threshold */

/* IRQ 소스 enable 토글 예시 */
static void plic_toggle(struct irq_data *d, unsigned enable)
{
    u32 mask = 1UL << (irq(d) % 32);
    void __iomem *reg = plic_regs + PLIC_CONTEXT_ENABLE_BASE +
                       (context * 0x80) + (irq(d) / 32) * 4;
    if (enable)
        writel(readl(reg) | mask, reg);
    else
        writel(readl(reg) & ~mask, reg);
}

/* IRQ 클레임 (CLAIM) - 인터럽트 핸들링 */
static void plic_handle_irq(void)
{
    u32 irq;
    while ((irq = readl(plic_regs + PLIC_CLAIM_OFFSET))) {
        generic_handle_domain_irq(irq_domain, irq);
        writel(irq, plic_regs + PLIC_CLAIM_OFFSET);
    }
}

SBI 확장

SBI(Supervisor Binary Interface)는 커널이 M-mode 펌웨어(OpenSBI 등)에 서비스를 요청하는 표준 ABI입니다. 주요 표준 확장 목록:

SBI (Supervisor Binary Interface)

SBI는 S-mode(커널)와 M-mode(펌웨어) 사이의 표준 인터페이스입니다. 리눅스 커널은 SBI 호출을 통해 타이머(Timer) 설정, 프로세서 간 인터럽트(IPI) 전송, 콘솔 출력 등의 기계 수준 작업을 수행합니다. OpenSBI가 가장 널리 사용되는 SBI 구현체입니다.

/* arch/riscv/include/asm/sbi.h - SBI 호출 인터페이스 (간략화) */

/* SBI Extension IDs */
#define SBI_EXT_TIME           0x54494D45  /* "TIME" */
#define SBI_EXT_IPI            0x735049    /* "sPI"  */
#define SBI_EXT_RFENCE         0x52464E43  /* "RFNC" */
#define SBI_EXT_HSM            0x48534D    /* "HSM"  */

/* SBI 호출 수행 (ecall 명령어 사용) */
struct sbiret {
    long error;
    long value;
};

static inline struct sbiret sbi_ecall(int ext, int fid,
    unsigned long arg0, unsigned long arg1,
    unsigned long arg2, unsigned long arg3)
{
    struct sbiret ret;

    register unsigned long a0 asm("a0") = arg0;
    register unsigned long a1 asm("a1") = arg1;
    register unsigned long a6 asm("a6") = fid;
    register unsigned long a7 asm("a7") = ext;

    asm volatile("ecall"
        : "+r"(a0), "+r"(a1)
        : "r"(a6), "r"(a7)
        : "memory");

    ret.error = a0;
    ret.value = a1;
    return ret;
}

RISC-V 부팅 과정

RISC-V의 부팅 과정은 ARM64와 유사하게 여러 펌웨어 단계를 거칩니다. 현재 가장 일반적인 조합은 BootROM(FSBL) → OpenSBI → U-Boot → Linux입니다.

MIPS 아키텍처 (MIPS Architecture)

MIPS(Microprocessor without Interlocked Pipeline Stages)는 1981년 스탠포드 대학에서 시작된 초기 RISC(Reduced Instruction Set Computing) 설계로, x86_64 기계어(Machine Code)가 아닌 정수 파이프라인 중심의 단순한 명령어 세트를 표방했습니다. Sony PlayStation 2, Nintendo 64, SGI 워크스테이션, Cisco 라우터, OpenWRT 기반 공유기 임베디드 SoC(Ingenic, MediaTek, Realtek 등)에서 널리 사용되었으며, 리눅스 커널은 arch/mips에서 대부분의 MIPS 구현을 지원합니다.

오늘날 MIPS는 신규 사용자보다는 기존 임베디드 기기와 레거시 소프트웨어 유지보수 중심으로 커널 트리에 남아 있습니다. RISC-V가 라이선스 제약이 없으면서 MIPS와 유사한 RISC 설계 철학을 계승하면서, 신규 설계는 RISC-V로 이동하는 추세입니다. 커널 소스에서 MIPS는 별도의 arch/mips 트리로 유지되며 x86_64·ARM64·RISC-V와 달리 소프트웨어 관리 TLB와 세그먼트 기반 주소 공간이라는 독특한 구조를 가집니다.

개요 (Overview)

MIPS는 설계 초기부터 빅엔디안(Big-Endian)을 기본으로 채택했으며, 일부 구현은 리틀엔디안 (MIPSel)도 지원합니다. 커널은 엔디안(Endianness)에 따라 CPU_LITTLE_ENDIAN과 CPU_BIG_ENDIAN Kconfig 옵션으로 나뉘며, 배포판 크로스 툴체인 접두사도 mipsel-linux-gnu-처럼 달라집니다. 커널이 지원하는 MIPS 계열은 다음과 같습니다:

• MIPS I ~ MIPS V — 클래식 32/64비트 ISA (R2000/R4000/R10000 등)
• MIPS32 / MIPS64 Release 1~6 — 현대 MIPS 표준 (Release 6는 지연 슬롯 제거·컴팩트 분기 도입)
• microMIPS — 코드 밀도 최적화 명령어 세트
• nanoMIPS — 최신 임베디드용 16/32비트 혼합 명령어 세트
• MT(Multi-Threading), DSP ASE, MSA(MIPS SIMD), EVA, VZ — 아키텍처 확장

특권 모드 (Privilege Modes)

MIPS는 CP0(Coprocessor 0)의 Status 레지스터 KSU 필드로 세 가지 특권 모드를 표현합니다. 그러나 리눅스 커널은 슈퍼바이저 모드를 사용하지 않고, 커널 모드(Kernel Mode)와 유저 모드(User Mode) 두 가지만 사용합니다. 예외 발생 시 하드웨어가 EXL(Exception Level) 비트를 세워 KSU와 무관하게 자동으로 커널 모드로 전환합니다.

• 커널 모드 (KSU=00) — 모든 CP0 접근, 모든 메모리 접근, 전체 명령어 실행 가능. 리눅스 커널이 여기서 실행됩니다.
• 슈퍼바이저 모드 (KSU=01) — 커널 매핑 영역 접근 가능. 리눅스 MIPS는 이를 사용하지 않습니다.
• 유저 모드 (KSU=10) — kuseg(사용자 가상 주소)와 TLB 매핑 영역만 접근 가능. 사용자 공간이 여기서 실행됩니다.

CP0 Status 레지스터 ($12)

Status 레지스터는 특권 모드·인터럽트·예외 상태를 한꺼번에 관리합니다. 리눅스 인터럽트 비활성화 루틴(local_irq_disable/arch_local_irq_disable)은 이 레지스터의 IE 비트를 mfc0/mtc0로 직접 조작합니다. 핵심 비트는 다음과 같습니다:

부팅 초기 head.S의 setup_c0_status 매크로는 Status를 특정 비트 조합으로 깨끗이 초기화합니다:

/* arch/mips/kernel/head.S — setup_c0_status 매크로 (개념적 요약) */
    or      $t0, $t0, ST0_KERNEL_CUMASK  /* CU0 등 커널 필수 비트 세트 */
    or      $t0, $t0, 0x1f                 /* BEV 등 초기 부팅 비트 */
    xor     $t0, $t0, 0x1f                 /* 0x1f 마스크 클리어 (IE/EXL/ERL 제거) */
    mtc0    $t0, CP0_STATUS               /* Status 반영 */
    sll     $zero, 3 /* EHb — 파이프라인 해저드 제거 */

CP0 레지스터 (Coprocessor 0)

CP0는 x86의 CR/MSR, ARM64의 시스템 레지스터(System Register)에 해당하는 머신 제어 레지스터 집합입니다. 커널은 mfc0/mtc0 명령어로 접근하며, 예외·TLB·타이머·인터럽트 제어가 모두 CP0를 통해 이루어집니다. 주요 레지스터는 다음과 같습니다:

주소 공간 (Address Space)

32비트 MIPS의 주소 공간은 세그먼트 기반입니다. 최상위 비트가 세그먼트를 결정하며, kseg0/kseg1은 TLB를 거치지 않고 물리 메모리에 직접 매핑되는 것이 핵심 특징입니다. 이 때문에 커널은 초기 부팅 단계에서 페이지 테이블(TLB 엔트리) 설정 없이 코드를 실행할 수 있습니다.

TLB (Software-Managed TLB)

MIPS의 가장 독특한 점은 TLB(Translation Lookaside Buffer)를 하드웨어가 아니라 커널이 관리한다는 것입니다. x86_64/ARM64/RISC-V는 페이지 워크(Page Table Walk)를 하드웨어가 수행하지만, MIPS는 TLB 미스 시 CPU가 TLB Refill 예외를 발생시키고 커널이 직접 TLB 엔트리를 채워 넣습니다. 이를 위해 커널은 빌드 시점에 arch/mips/mm/tlbex.c가 생성한 최적화된 핸들러 코드를 사용합니다.

• 쌍 페이지 매핑 — 하나의 TLB 엔트리가 EntryLo0(짝수 페이지)와 EntryLo1(홀수 페이지) 두 페이지를 동시에 매핑합니다.
• ASID(Address Space Identifier) — EntryHi.ASID(8비트)로 프로세스별 주소 공간을 구분, 문맥 전환(Context Switch) 시 TLB를 비우지 않고 재사용합니다.
• PageMask — 엔트리별 페이지 크기(4KB~최대 수 MB)를 개별 지정합니다.
• Wired — 하위 N개 엔트리를 TLBWR(랜덤 교체) 대상에서 제외하여 커널 고정 매핑을 보호합니다.
• Context — 미스 시 PTE 주소를 PTEBase + BadVPN2로 즉시 계산해 핸들러 지연을 최소화합니다.

/* arch/mips/mm/tlbex.c가 빌드 시 생성하는 TLB Refill 핸들러 (개념적 코드) */
    mfc0    k1, C0_CONTEXT       /* Context → PTE 주소 */
    lw      k0, 0(k1)            /* 짝수 페이지 PTE → EntryLo0 */
    lw      k1, 4(k1)            /* 홀수 페이지 PTE → EntryLo1 */
    mtc0    k0, C0_ENTRYLO0      /* EntryLo0 설정 */
    mtc0    k1, C0_ENTRYLO1      /* EntryLo1 설정 */
    ehb                          /* 파이프라인 해저드 배리어 */
    tlbwr                        /* Random 인덱스에 TLB 기록 */
    eret                         /* 예외 복귀 (EPC로 이동) */

예외 벡터 (Exception Vectors)

MIPS는 예외 종류에 따라 고정된 예외 벡터(Exception Vector) 주소로 분기합니다. Status.BEV가 0이면 kseg0(캐시) 기반, 1이면 0xBFC00000(비캐시 ROM) 기반으로 이동합니다. 부팅 초기 BEV=1에서 커널이 초기화 후 BEV=0으로 전환합니다.

General Exception 벡터에 도달하면 커널은 Cause.ExcCode 필드로 핸들러를 선택합니다. arch/mips/kernel/genex.S의 except_vec3_generic이 이 디스패치를 수행합니다:

/* arch/mips/kernel/genex.S — except_vec3_generic (General 벡터 디스패치) */
    mfc0    k1, C0_CAUSE         /* Cause 레지스터 읽기 */
    andi    k1, k1, 0x7c         /* ExcCode 필드 (비트 6:2) 추출 */
    la      k0, exception_handlers
    addu    k0, k0, k1            /* ExcCode × 4 = 테이블 오프셋 */
    lw      k0, 0(k0)            /* 핸들러 주소 로드 */
    jr      k0                    /* 핸들러로 점프 */
    nop                             /* 지연 슬롯 */

부팅 과정 (Boot Process)

MIPS 부팅은 펌웨어(Bootloader)가 커널 엔트리로 직접 분기하는 단순한 구조입니다. 대표적인 펌웨어로 YAMON(Board 템플릿 보드), PMON, U-Boot, CFE가 있으며, 커널은 kernel_entry()에서 시작됩니다.

/* arch/mips/kernel/head.S — 커널 진입점 kernel_entry() (개념적 요약) */
FEXPORT(kernel_entry)
    setup_c0_status              /* Status 초기화 (BEV=1 유지, EXL/ERL 클리어) */
    sll     $zero, 3            /* EHb — 파이프라인 해저드 제거 */

#ifdef CONFIG_RELOCATABLE
    jal     relocate_kernel      /* 실제 적재 주소로 자기 재배치 */
    jr.hb   v0                    /* 재배치된 커널로 점프 (hazard barrier) */
#endif
    j       start_kernel          /* C 언어 초기화 진입 (arch-independent) */

• 펌웨어 인자: U-Boot/YAMON은 a0=인자 개수(argc), a1=인자 배열(argv), a2=환경(envp), a3=추가 정보를 전달하며, 커널은 이를 fw_arg0~fw_arg3으로 저장해 fw_init_cmdline 등에서 사용합니다.
• BMIPS DTB 규약: Broadcom(BMIPS)에서는 a0=0, a1=0xffffffff, a2=Device Tree 물리 주소로 DTB를 전달합니다. 장치는 물리 512MB 이내, 64비트 정렬이어야 합니다. (Documentation arch/mips/booting.rst)
• CONFIG_RELOCATABLE: 커널이 실제 적재 주소(Load Address)와 컴파일 주소가 다를 때 relocate_kernel이 자기 코드를 옮긴 뒤 jr.hb로 재점프합니다.
• SMP: 멀티코어 시스템에서 부팅 CPU만 kernel_entry를 수행하고, 나머지 코어는 펌웨어/IPI 메일박스로 보조 부팅 루틴(smp_bootstrap)에 진입합니다.

메모리 순서 모델 (Memory Ordering Model)

MIPS는 전통적으로 비순차적(Weakly Ordered) 메모리 모델을 채택했습니다. 명령어 실행은 순서대로 보이지만, 메모리 접근은 구현에 따라 재배열될 수 있습니다. 원자성은 LL/SC(Load Linked / Store Conditional) 쌍으로 보장하며, 순서 보장은 SYNC 명령어로 수행합니다.

/* arch/mips/include/asm/barrier.h에서 메모리 배리어 매크로 구성 */
/* smp_mb()는 SYNC stype 0, smp_rmb/wmb는 stype 0x10 계열 */
__sync:
    sync    0                     /* 완전 순서 배리어 */
    sync    0x10                  /* 경량 순서 배리어 (R2+) */

가상화 (Virtualization)

MIPS의 하드웨어 가상화는 VZ(Virtualization Module) 확장이 표준입니다. 커널은 CONFIG_KVM_MIPS_VZ로 KVM 게스트를 지원합니다. 과거에는 Trap & Emulate(KVM_TE) 방식도 있었지만, 2021년(v5.13 이후 병합 창)에 유지보수 축소로 커널에서 제거되었습니다. 따라서 현대 리눅스 MIPS KVM은 VZ 확장이 있는 하드웨어(옥테온 등)에서만 동작합니다.

유지보수 현황 (2025-2026)

특권 레벨 비교 (Privilege Level Comparison)

운영체제가 여러 프로그램을 동시에 실행할 때, 한 프로그램이 다른 프로그램의 메모리를 덮어쓰거나 하드웨어를 직접 제어하면 시스템 전체가 무너집니다. 이를 막기 위해 CPU는 실행 코드가 "얼마나 많은 권한을 갖느냐"를 하드웨어 수준에서 구분합니다 — 이것이 특권 레벨(Privilege Level)입니다.

특권 레벨이 낮은 코드(사용자 애플리케이션)는 직접 하드웨어에 접근하거나 다른 프로세스의 메모리를 읽으려 하면 CPU가 즉시 예외(Exception)를 발생시켜 커널에 제어권을 넘깁니다. 커널은 특권 레벨이 가장 높은 곳에서 실행되며, 이 경계가 OS의 보안과 안정성의 근본입니다. 세 아키텍처는 이 개념을 각기 다른 이름과 계층 수로 구현합니다:

위 다이어그램에서 주목할 점은 리눅스 커널이 각 아키텍처에서 다른 특권 레벨에서 동작하는 것입니다:

• x86_64: Ring 0에서 동작. Ring -1(VMX)은 하이퍼바이저 전용.
• ARM64: EL1에서 동작. EL2는 하이퍼바이저, EL3는 보안 모니터.
• RISC-V: S-mode에서 동작. M-mode는 SBI 펌웨어가 담당.

시스템 콜/예외 진입 경로 비교

사용자 공간에서 커널 공간으로 전환되는 공통 경로는 시스템 콜, 인터럽트, 예외입니다. 아키텍처별 진입 명령과 복귀 명령은 다르지만, 커널이 트랩 프레임을 저장하고 핸들러를 호출한 뒤 사용자 공간으로 복귀하는 큰 흐름은 동일합니다.

• 시스템 콜 진입 명령: x86_64는 SYSCALL, ARM64는 SVC, RISC-V는 ecall을 사용합니다.
• 트랩 벡터: x86_64(IDT), ARM64(VBAR_EL1), RISC-V(stvec)가 첫 진입 지점을 결정합니다.
• 복귀 명령: x86_64(SYSRET/IRETQ), ARM64(ERET), RISC-V(sret)로 복귀합니다.

start_kernel() - 커널 초기화 진입점 (Kernel Init Entry)

모든 아키텍처에서 아키텍처별 초기화가 완료되면 start_kernel() 함수가 호출됩니다. 이 함수는 init/main.c에 정의되어 있으며, 커널의 공통 초기화를 수행하는 핵심 함수입니다.

/* init/main.c - start_kernel() 함수 (핵심 흐름 간략화) */

asmlinkage __visible void __init start_kernel(void)
{
    /* 아키텍처 의존적 초기화 (이전 단계에서 일부 수행) */
    setup_arch(&command_line);     /* 아키텍처별 설정 */

    /* 부팅 초기 메모리 할당자 (memblock) */
    setup_per_cpu_areas();          /* Per-CPU 영역 설정 */

    /* 핵심 서브시스템 초기화 */
    trap_init();                     /* 예외/인터럽트 벡터 설정 */
    mm_core_init();                  /* 메모리 관리 초기화 */
    sched_init();                    /* 스케줄러 초기화 */
    init_IRQ();                      /* 인터럽트 컨트롤러 설정 */
    time_init();                     /* 타이머 초기화 */
    console_init();                  /* 콘솔 초기화 */

    /* VFS 및 기타 서브시스템 */
    vfs_caches_init();              /* VFS 캐시 초기화 */
    signals_init();                  /* 시그널 초기화 */
    proc_root_init();               /* procfs 초기화 */

    /* 나머지 초기화 - kernel_init 스레드 생성 */
    arch_call_rest_init();          /* rest_init() → kernel_init() */

    /*
     * rest_init()에서:
     *  1. kernel_init 커널 스레드 생성 (PID 1의 전신)
     *  2. kthreadd 커널 스레드 생성 (PID 2)
     *  3. 현재 스레드는 idle 스레드(PID 0)가 됨
     *
     * kernel_init()에서:
     *  1. initcall 실행 (드라이버 초기화 등)
     *  2. /sbin/init 또는 /init 실행 → PID 1 프로세스
     */
}

커널 소스 트리 구조 (Kernel Source Tree Structure)

리눅스 커널 소스 코드는 기능별로 잘 정리된 디렉토리 구조를 가지고 있습니다. 커널 개발을 시작할 때 이 구조를 이해하는 것이 매우 중요합니다.

arch/ 디렉토리 상세 (Architecture Directory Detail)

arch/ 디렉토리 아래의 각 아키텍처 디렉토리는 비슷한 하위 구조를 가집니다. 이는 커널의 아키텍처 추상화 설계 원칙을 반영합니다:

• arch/<arch>/kernel/ - 프로세스 전환, 시스템 콜, SMP, 시그널 처리 등 핵심 아키텍처 코드
• arch/<arch>/mm/ - 페이지 테이블 관리, TLB 관리, 캐시(Cache) 관리 등 메모리 관련 코드
• arch/<arch>/include/asm/ - 아키텍처별 헤더 파일 (인라인 어셈블리, 레지스터 정의 등)
• arch/<arch>/boot/ - 부트 코드, 부트 이미지 생성 스크립트
• arch/<arch>/configs/ - 기본 커널 설정 파일 (defconfig)
• arch/<arch>/Kconfig - 아키텍처별 Kconfig 옵션 정의

커널은 이러한 구조를 통해 아키텍처 독립적인 코드(kernel/, mm/ 등)와 아키텍처 의존적인 코드(arch/)를 깔끔하게 분리합니다. 새로운 아키텍처를 지원하려면 주로 arch/ 아래에 해당 아키텍처 디렉토리를 추가하면 됩니다.

빌드 설정 예시 (Build Configuration)

각 아키텍처의 기본 설정 파일(defconfig)로 빠르게 커널을 빌드할 수 있습니다:

# x86_64 기본 설정으로 커널 빌드
make x86_64_defconfig
make -j$(nproc)

# ARM64 크로스 컴파일
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make defconfig
make -j$(nproc) Image dtbs

# RISC-V 크로스 컴파일
export ARCH=riscv
export CROSS_COMPILE=riscv64-linux-gnu-
make defconfig
make -j$(nproc)

# QEMU로 빌드된 커널 테스트 (x86_64)
qemu-system-x86_64 \
    -kernel arch/x86/boot/bzImage \
    -initrd /path/to/initramfs.cpio.gz \
    -append "console=ttyS0" \
    -nographic

요약 (Summary)

이 문서에서는 리눅스 커널이 지원하는 주요 네 아키텍처의 핵심 개념을 살펴보았습니다. 각 아키텍처의 특성을 다음 표로 정리합니다:

아키텍처별 성능 최적화 (Architecture-Specific Performance Optimization)

각 아키텍처는 고유한 성능 특성과 최적화 포인트를 가지고 있습니다. 커널 개발자는 타겟 아키텍처의 특성을 이해하고 이에 맞는 최적화를 적용해야 합니다.

x86_64 최적화 포인트

x86_64는 강력한 OoOE(Out-of-Order Execution, 비순서 실행)와 넓은 SIMD(Single Instruction Multiple Data) 레지스터(AVX-512, AVX2, SSE)를 갖추고 있지만, 그 복잡성만큼 잘못된 사용이 성능을 오히려 깎는 경우도 많습니다. 대표적인 함정은 캐시 라인 경계를 무시한 데이터 배치(거짓 공유(False Sharing))와, likely()/unlikely() 없이 작성된 분기 코드입니다. 아래 기법들은 "기본값을 지키면 손해 없다"는 관점에서 핵심만 정리한 것입니다.

캐시 아키텍처와 False Sharing 방지

x86_64 CPU는 일반적으로 L1(32KB~64KB), L2(256KB~1MB), L3(Shared, 여러 MB~수십 MB)의 3단 캐시 계층 구조를 갖습니다. 캐시 라인(Cache Line) 기본 크기는 64바이트이며, 메모리 접근은 이 64바이트 단위(그레인, Granule)로 L1/L2/L3 캐시에 로드됩니다.

False Sharing은 두 개 이상의 CPU 코어가 서로 다른 변수를 접근하는데, 그 변수들이 같은 64바이트 캐시 라인 내에 배치될 때 발생하는 성능 저하입니다. 한 코어가 변수 A를 수정하면 MESIF/MOSI 일관성 프로토콜에 의해 다른 코어의 해당 캐시 라인이 무효화(Invalid)되어, 다른 코어가 변수 B에 접근할 때도 캐시 미스가 발생하게 됩니다.

/* ❌ 잘못된 예: False Sharing 발생 가능 */

/* hot과 cold가 같은 캐시 라인에 배치될 수 있음 */
struct bad_example {
      atomic_t  hot_counter;     /* 모든 코어에서 자주 접근 */
      spinlock_t hot_lock;       /* 모든 코어에서 자주 경쟁 */
      char        cold_name[64];/* 가끔만 접근하는 이름 */
      struct list_head cold_list;/* 드물게 접근하는 연결 리스트 */
};

/* ✅ 올바른 예: hot/cold 데이터 분리 + 캐시 라인 정렬 */

struct hot_data {
     atomic_t  counter;
     spinlock_t lock;
} __cacheline_aligned;  /* 64바이트 경계 정렬 */

struct cold_data {
     char        name[64];
     struct list_head list;
} __cacheline_aligned;

/* Per-CPU 변수 사용: 각 코어마다 전용 복사본 */
static struct hot_data percpu_hot
     __attribute__((percpu));

/* Per-CPU 변수 접근 (예: network packet counter) */
static void inc_packet_count(void)
{
     atomic_inc(&this_cpu_ptr(&percpu_hot)->counter);
}

커널 내부적으로 __cacheline_aligned는 아키텍처 특정 패딩을 추가하여 캐시 라인 크기에 맞춤합니다. x86_64에서는 64바이트, ARM64에서는 128바이트(일부 새 CPU)에 정렬됩니다.

/* include/linux/cache.h — 캐시 라인 정렬 매크로 */

/* L1 Cacheline-aligned */
#define __cacheline_aligned      __attribute__ ((aligned (L1_CACHE_BYTES)))

/* x86_64: arch/x86/include/asm/cache.h */
#define L1_CACHE_BYTES     64

/* Per-CPU 데이터의 정렬: cacheline_align() */
#define cacheline_aligned(x) __cacheline_aligned_in_smp x

/* 현대 커널: thread_info는 v4.13부터 task_struct에 통합됨 */
/* 현재 태스크 접근 매크로 (arch/x86/include/asm/current.h) */
#define current   (typeof(struct task_struct *)this_cpu_read_stable(current_task))

HW/SW Prefetch 기술

x86_64 CPU는 하드웨어 프리페치(Prefetch)를 기본적으로 제공하며, 간단한 순차 접근 패턴이나 stride-2와 같은 규칙적인 패턴을 자동으로 감지하여 데이터를 캐시에 미리 로드합니다. 그러나 커널 코드에서는 하드웨어가 감지하지 못하는 불규칙한 데이터 접근 패턴이 빈번하게 발생합니다. 이런 경우 명시적인 prefetch() 또는 _mm_prefetch() intrinsic 함수를 사용하여 소프트웨어 단에서 Prefetch 힌트를 줄 수 있습니다.

/* include/linux/prefetch.h — prefetch 매크로 개념 예시 */

/* Prefetch data into cache (읽기용) */
#define prefetch(addr)      __builtin_prefetch(addr)

/* Prefetch for write (쓰기 전용 힌트) */
#define prefetchw(addr)     __builtin_prefetch(addr, 1)

/* 예: 네트워크 rx ring buffer 처리 */
static int net_rx_poll(struct netdev_rx_queue *rxq, int budget)
{
     struct sk_buff *skb;
     int i;

     for (i = 0; i < budget; i++) {
/* 현재 버퍼 처리 */
         skb = rxq_dequeue(rxq);
         if (!skb)
             break;

/* 다음 2개 버퍼를 Prefetch (HW prefetch가 잡지 못하는 경우) */
         prefetch(skb + 1);
         prefetch(skb + 2);

         netif_receive_skb(skb);
     }
     return i;
}

분기 예측(Branch Prediction) 최적화

x86_64 CPU는 동적 분기 예측(Dynamic Branch Prediction)을 통해 분기의 실제 결과(진입 or 비진입)를 학습하고 다음 실행에 활용합니다. 분기 예측이 실패하면 파이프라인이 플러시되고 수십 사이클 규모의 지연(Latency)이 발생하며, 그 크기(Penalty)는 구현 세대에 따라 달라집니다. 커널 코드에서 분기 예측 효율을 높이는 방법은 다음과 같습니다:

• likely()/unlikely() 사용 — 컴파일러가 코드를 배치할 때 분기 예측 힌트를 반영합니다. likely() 내부 코드가 연속된 주소에 배치되어, 파이프라인이 효율적으로 Prefetch할 수 있습니다.
• Hot/Cold 코드 분리 — 자주 실행되는 경로를 연속 메모리에 배치하고, 드물게 실행되는 오류 경로를 별도 섹션으로 분리합니다.
• 루프 언롤링(Loop Unrolling) — 컴파일러가 작은 루프를 자동으로 Unroll하는 경우가 많지만, 커널 내부에서는 때때로 수동 Unrolling이 특정 성능 패턴에서 더 나은 결과를 만듭니다.

/* include/linux/compiler_types.h — likely/unlikely 내부 */

#if defined(__GNUC__) && __GNUC__ >= 4
#  define likely(x)        __builtin_expect (!(!(x)), 1)
#  define unlikely(x)      __builtin_expect (!(!(x)), 0)
#else
#  define unlikely(x) (x)
#endif

/* 사용 예: 네트워크 패킷 처리 */
static int process_packet(struct sk_buff *skb)
{
     /* 정상 경로: 패킷 유효함 (99.9% 케이스) */
     if (likely(skb->len > 0)) {
         process_ip_header(skb);
         process_tcp_header(skb);
         return 0;
     }

     /* 예외 경로: 빈 패킷 (0.1% 케이스) */
     pr_debug("Empty packet received\n");
     kfree_skb(skb);
     return -EINVAL;
}

NUMA Aware 최적화

NUMA(Non-Uniform Memory Access) 아키텍처에서 메모리 접근 지연 시간은 "어느 NUMA 노드에 속한 메모리를 접근하느냐"에 따라 다릅니다. 같은 노드 내 메모리 접근은 상대적으로 짧은 지연을 보이고, 다른 노드에서 접근하면 링크(PCIe/ QPI/ UPI)를 통과하며 더 긴 지연이 발생할 수 있습니다(정도는 하드웨어·워크로드에 따라 달라짐).

리눅스 커널은 NUMA 인식 기능을 여러 계층에서 제공합니다:

• Per-CPU NUMA 정책: 각 CPU 스레드가 속한 NUMA 노드를 인식하고, kmalloc_node(), alloc_pages_node()를 통해 로컬 노드에서 메모리를 할당 할 수 있습니다.
• NUMA_BALANCING: /proc/sys/kernel/numa_balancing sysctl로 활성화 시, 커널이 힌트 폴트(hint fault)를 유발해 프로세스가 자주 접근하는 메모리를 실행 중인 CPU에 가까운 NUMA 노드로 마이그레이션합니다.
• NUMA Aware Page Allocation: buddy allocator가 NUMA 노드별 free list를 관리하며, GFP_THISNODE 플래그를 사용하면 지정 노드 외 다른 노드로의 폴백(Fallback) 할당을 방지합니다.

/* NUMA-인식 메모리 할당 예제 */

/* 현재 CPU가 속한 NUMA 노드에서 kmalloc */
static struct my_device *alloc_device(int node)
{
     struct my_device *dev;

     /* 인자 node가 유효하면 해당 노드, 아니면 현재 노드를 사용 */
     if (node < 0)
         node = numa_node_id();

     dev = kmalloc_node(sizeof(*dev), GFP_KERNEL, node);
     if (!dev)
         return NULL;

     /* RX ring buffer용 페이지 32개를 같은 NUMA 노드에서 일괄 할당 */
     alloc_pages_bulk_node(node, GFP_KERNEL | __GFP_NOWARN,
         32, dev->rx_bufs);
     return dev;
}

/* NUMA-aware per-CPU variable */
static DEFINE_PER_CPU(struct cpu_stats, cpu_stats);

static void update_cpu_stats(int packets)
{
     struct cpu_stats *stats = this_cpu_ptr(&cpu_stats);
     stats->packets += packets;
     stats->bytes += skb->len;
}

SIMD 명령어 활용 (SSE/AVX/AVX-512)

x86_64의 SIMD 명령어(SSE, AVX, AVX-512)는 데이터 병렬처리에 매우 강력합니다. 커널 모드에서는 제한적으로 사용되며, kernel_fpu_begin/end()를 사용하여 FPU/MMX/SIMD 레지스터 컨텍스트를 보호해야 합니다.

커널에서 SIMD를 사용하는 대표적인 예:

• 암호화 하위 시스템: AES-NI, SHA extensions(GHASH, PCLMULQDQ) 활용
• CRC32/CRC32c 계산: PCLMULQDQ 기반 crc32_pclmul()/crc32c_pclmul() 등
• zstd/lz4: AVX2/ AVX-512 기반 압축/해제
• net filter(BPF/XDP): AVX2 기반 패킷 분류

/* 커널 모드 SIMD 사용 예제 (AES-NI 암호화) */

/* crypto/aesni-intel_glue.c 계열 — AES-NI 기반 ECB 암호화 구조 (개념 단순화) */
static int aesni_ecb_encrypt(struct aesni_ctx *ctx,
                                     u8 *dst, const u8 *src,
                                     unsigned int len)
{
     int ret = -EBUSY;

     kernel_fpu_begin();
     do {
         /* aesenc, aesenclast intrinsics (GCC/Clang) */
         _mm_store_si128(&out, _mm_aesenc_si128(in, *round_key));
         _mm_store_si128(&out, _mm_aesenclast_si128(in, *last_round_key));

         src += 16;
         dst += 16;
         len -= 16;
         round_key++;
     } while (len >= 16);

     kernel_fpu_end();
     return 0;
}

/* CRC32c PCLMULQDQ 최적화 */
uint32_t crc32c_pclmul(const u8 *data, unsigned int len, uint32_t crc)
{
     return _mm_crc32_u64(crc, *(const uint64_t*)data);
}

TLB 최적화

TLB(Translation Lookaside Buffer)는 가상 주소 → 물리 주소 변환 결과를 캐시하는 고속 메모리입니다. TLB miss가 발생하면 Page Table Walk(4-level이면 L1 → L2 → L3 → L4 → Page)가 필요한데, 캐시 히트 여부에 따라 수십~수백 사이클의 추가 지연이 발생할 수 있습니다.

주요 TLB 최적화 기법:

• Huge Pages: 4KB → 2MB 페이지로 전환하면 TLB entry 1개로 512개의 4KB page를 대체할 수 있습니다. CONFIG_HUGETLBFS 또는 CONFIG_TRANSPARENT_HUGEPAGE를 통해 활성화합니다.
• ASID (Address Space ID): x86_64는 CR3에 ASID를 내장하여 컨텍스트 스위치 시 TLB flush를 최소화합니다.
• TLB Shootdown 최소화: 페이지 테이블 변경 후 flush_tlb_one()를 사용하는 것이 flush_tlb_all()보다 효율적입니다.

# Transparent Huge Pages 설정 확인
cat /sys/kernel/mm/transparent_hugepage/enabled
# [always] madvise never

# HugePages 상태 확인
cat /proc/meminfo | grep -i huge
# HugePages_Total:        128
# HugePages_Free:         96

# TLB miss 측정
perf stat -e dTLB-load-misses,dTLB-store-misses -- ./benchmark

FRED과 GCS (Intel CET)

Intel CET(Control-flow Enforcement Technology)는 두 가지 서브 기술로 구성됩니다. GCS(Guarded Control Stack)는 Shadow Stack을 사용하여 Return Address를 보호하며, FRED(Flexible Return and Event Delivery)는 커널 호출/인터럽트 진입-종료를 가속합니다.

FRED은 Linux v6.12(2024 Q3)에 메인라인 머지되었으며, Granite Rapids(Xeon 6) 세대부터 하드웨어 지원을 시작했습니다. 기존 IDT 기반 예외/인터럽트 전달 경로를 전용 하드웨어 메커니즘으로 대체하여 이벤트 전달 오버헤드를 줄입니다(정도는 하드웨어·워크로드에 따라 달라짐).

# FRED 지원 확인
grep -i fred /proc/cpuinfo

# GCS 상태 확인
dmesg | grep -i gcs
# 예: CET/FRED 관련 부팅 메시지 확인 (실제 텍스트는 커널 버전에 따라 다름)

# FRED 활성화 부트 파라미터
fred=on  # forced enable
fred=off # explicit disable

하드웨어 성능 모니터링 (PMC / IntelPT)

x86_64 CPU는 PMU (Performance Monitoring Unit)를 통해 다양한 Hardware Counter를 제공하는데, 이를 통해 명령어 수, Cache Miss, Branch Miss, Cycle 수 등을 정량적으로 측정할 수 있습니다. perf은 이 PMC에 접근하는 최상위 도구이며, IntelPT는 Branch-level trace를 제공합니다.

# CPU cycle, instruction, cache/branch miss를 함께 측정
perf stat -e cycles,instructions,cache-references,cache-misses, \
     branch-instructions,branch-misses -- ./my_benchmark

# 결과를 flame graph로 가시화
perf record -F 99 -- ./my_benchmark
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg

# Intel PT trace (branch-level) record
perf record -e intel_pt// -- ./my_benchmark
perf inject -j --input perf.data --output perf.pt

# MSR 직접 읽기 (root 필요)
rdmsr -a 0x198  # IA32_PERFCTR0 (core cycles)
rdmsr -a 0x199  # IA32_PERFCTR1 (instructions)

MSR(Model-specific Register)에는 각 CPU 세대마다 다양한 성능 카운터가 위치합니다. perf stat은 PMU의 Counter multiplexing을 자동으로 처리하므로, 일반적으로 raw MSR 접근 없이 perf를 사용하는 것을 권장합니다.

ARM64 최적화 포인트

ARM64(RISC 계열)는 x86와 달리 약한 메모리 순서(Weak Memory Ordering) 모델을 사용합니다. 코드가 작성된 순서와 실제 메모리 접근 순서가 다를 수 있기 때문에, 공유 데이터를 다룰 때는 dmb/dsb 배리어나 smp_wmb()/smp_rmb() 같은 커널 추상화를 명시적으로 사용해야 합니다. 이 점이 x86 경험자가 ARM64 커널 코드를 처음 작성할 때 가장 자주 실수하는 부분입니다.

ARM64 메모리 순서 모델

ARMv8-A 메모리 순서 모델은 ACQUIRE-RELEASE 계열의 약한 순서(Weakly Ordered) 모델입니다. Load-Load, Load-Store, Store-Load, Store-Store 재배치 모두 허용되므로, DMB와 DSB 명령의 종류에 따라 재배치 허용 범위 제어합니다.

ARM64에서 분기 예측과 명령 Pipeline과 같은 하드웨어 특징은 다음과 같습니다:

• Out-of-Order vs In-order: Apple M-series는 와이드 이슈 OoO 코어인 반면, Ampere(Graviton)의 Neoverse N1/N2 코어는 인오더(In-order) 설계입니다
• Branch Predictor: ARM64에서도 동적 분기 예측(Dynamic Branch Prediction)을 지원합니다. AArch64 ISA에는 x86처럼 명시적인 분기 힌트 명령어가 없으므로, GCC의 __builtin_expect()가 코드 배치 최적화에 사용됩니다.
• Load-Store architecture: 모든 메모리 접근이 명시적인 Load/Store 명령어이고, Register-toRegister 연산만 메모리 접근이 아닙니다. 이 특징으로 인해 x86과 달리 Memory Barrier의 역할이 명확히 분리됩니다.

/* ARM64 Memory Ordering 예제 */

static void producer(struct shared *d)
{
     WRITE_ONCE(d->data, 42);
     smp_wmb();                   /* DMB ISHST: store → load 재배치 차단 */
     WRITE_ONCE(d->ready, 1);
}

static int consumer(struct shared *d)
{
     int val;

     if (!READ_ONCE(d->ready))
         return 0;
     smp_rmb();                   /* DMB ISHLD: load → load 순서 보장 */
     val = READ_ONCE(d->data);
     return val;
}

LSE (Large System Extensions)

ARMv8.1-A부터 도입된 LSE(Large System Extensions)는 원자적 읽기-수정-쓰기(RMW) 연산을 위한 단일 명령어 집합(Instruction Set)을 추가하는 확장입니다. LSE 이전에는 Atomic 연산이 LDXR/STXR 루프 + DMB ISH로 구현되었는데, 이는 멀티코어 환경에서 spin-like 재시도를 유발하여 동시성(Spin Count)이 높은 경우 성능 저하를 초래했습니다.

참고로 LDAR/STLR(Load-Acquire / Store-Release)는 LSE 이전의 ARMv8.0 기본 ISA에 이미 존재하며, 각각 acquire 로드와 release 스토어의 순서 보장을 제공합니다. LSE가 새로 추가한 것은 LDADD/SWP/CAS/LDXP/STXP 같은 원자 RMW 명령어로, LDXR/STXR 재시도 루프를 단일 명령으로 대체해 경쟁 환경의 스피너(Spin) 횟수를 줄여줍니다.

/* LSE Atomic Operations (ARM64 Assembly) */

/* LSE 이전: LDXR/STXR 루프 + DMB */
loop:
       ldxr    w0, [x1]
       add      w0, w0, #1
       stxr    w2, w0, [x1]
       cbnz    w2,    loop         /* store failed → retry */
       dmb     ish

/* LSE 이후: LDADD 단일 명령 (재시도 루프 없음) */
       ldadd   w0, wzr, [x1]         /* *x1 += 1 (원자적) */

/* Linux kernel: arch/arm64/include/asm/atomic.h */
/* atomic_add() → LSE 빌드에서는 LDADD 계열 명령으로 대체 (런타임 alternatives 패칭) */

SVE (Scalable Vector Extension)

SVE는 ARMv8.2-A부터 도입된 확장 명령어 집합으로, SIMD 작업에 사용되는 SIMD 레지스터의 길이를 고정 길이(AVX-512 = 512-bit)가 아니라 하드웨어에 따라 가변 길이로 정의합니다. ARM64 Server SoC(Graviton2, Fujitsu A64FX)에서 사용되며, 벡터 연산의 처리 단위(LEN)는 하드웨어 설계에 따라 결정됩니다.

SVE의 주요 특징:

• 가변 길이 벡터 — Graviton2(P128 = 128-bit) vs A64FX(P2048 = 2048-bit) 동일 코드가 다양한 하드웨어에서 동작하며, svlen 명령어로 벡터 길이 런타임 확인.
• Predicate — Loop Unrolling 없이 조건부 Mask를 이용한 데이터 병렬 처리.
• Kernel SVE 지원 — 커널 모드를 위해 SVE 레지스터 컨텍스트를 kernel_neon_begin/end(), kernel_sve_begin/end() 로 감싸야 합니다.

/* SVE 명령어 예시 (Scalable Vector Add) */

/* z0, z1, z2 = SVE vector registers */
       ld1     {z0.s}, p0/all, [x0]   /* load vector z0 from address x0. pred p0 */
       ld1     {z1.s}, p0/all, [x1]   /* load vector z1 from address x1 */
       add    z2.s, p0,    z0.s, z1.s  /* z2 = z0 + z1, mask p0 */
       st1     {z2.s}, p0/all, [x2]   /* store z2 to x2 */

/* whilelo: predicate 기반 루프 (loop unroll 없이) */
top:
       ld1     {z0.s}, p0/z, [x0]   /* predicated load (SVE는 포스트 증식 주소화 미지원) */
       whilelo p0.s, w2, w3            /* p0 = (w2 < w3)? 1:0 per lane */
       b.cond p0.any, top             /* any bit set? → continue */

/* SVE vector length 확인 */
       mrs     x0, SVL                /* SVE 벡터 길이(바이트)를 x0에 로드 */

/* Kernel SVE 사용 예: crypto/sha256-glue.c */

static void sha256_transform_sve(struct sha256_state *s,
                                     const u8 *data)
{
     kernel_sve_begin();
     /* SVE intrinsics (GCC/Clang) */
     sve_sha256_process(s, data);
     kernel_sve_end();
}

SME (Scalable Matrix Extension)

SME는 SVE를 기반으로 확장된 매트릭스 지향(matrix-oriented) SIMD 확장으로, ARMv9.2-A부터 지원됩니다. Tensor-like 연산에 특화된 ZA 레지스터 공간을 제공하며, ZA 타일 크기(ZAL × ZAW)는 구현의 SVE 벡터 길이(SVL)에 따라 결정됩니다.

SME의 핵심 특징:

• Streaming Mode — 캐시를 우회(Bypass)하고 메모리에 직접 읽고 쓰는 모드로, PSTATE.SM 비트로 진입/탈출합니다. 메모리 순서는 일반 ARMv8-A 약한 순서 모델을 따릅니다.
• ZA register — SVE의 z0~z31 벡터 레지스터와 별도로 할당되는 매트릭스 연산 특화 레지스터 공간입니다. 행렬 곱(FMLA 등 MMA 명령)을 단일 명령으로 수행합니다.
• Fractured Loads/Store — ZA의 부분(row/column)을 메모리에 직접 로드/스토.

/* SME 매트로릭스 연산 개념 예시 (ZA register) */

/* 스트리밍 모드: PSTATE.SM = 1로 진입, SMSTOP 명령으로 종료 */
       smstop                           /* streaming mode 종료 (PSTATE.SM = 0) */

/* ZA fractured load/store (프래디케이트 기반) */
       ldr     za0.d, p0, [x0]           /* ZA의 일부 요소를 p0 마스크로 로드 */
       str     za0.d, p0, [x2]           /* ZA의 일부 요소를 p0 마스크로 저장 */

/* MMA: Floating-point Matrix Multiply-Accumulate */
       fmla    za0.s, x1.s, za1.s        /* za0 += x1 × za1 (행렬 곱-누적) */

NEON (128-bit SIMD)

NEON이 ARM64에서 가장 널리 사용되는 SIMD 명령어입니다. x86의 AES-NI에 대응하는 ARMv8 Cryptographic Extensions(AES, AESEMC, AESIMC, SHA1/SHA2, PMULL 등)이 전용 암호화 명령어를 제공하며, 커널 crypto 프레임워크는 이 명령어들을 활용합니다. PMULL은 PCLMULQDQ의 ARM 대응으로, GHASH 등 Message Authentication Code(MAC) 연산을 가속합니다.

/* NEON + ARM Crypto Extension 예시 */

/* PMULL: Polynomial Multiply (GHASH 핵심 연산) */
       pmull   q0, d0, d8                /* 하위 64비트 쌍 → 128비트 결과(q0) */
       pmull2  q1, d1, d9               /* 상위 64비트 쌍 → 128비트 결과(q1) */

/* AES 라운드 연산 (ARM Crypto Extensions) */
       aes    q0, q1                   /* SubBytes + ShiftRows (암호화 라운드) */
       aesimc q0, q1                  /* InvMixColumns (복호화 라운드) */
       aesmc  q0, q1                  /* MixColumns (암호화 라운드) */

/* VMULL: Integer Multiply-Lengthen (포화 연산 아님) */
       vmull   q0, d0, d1                /* 32 × 32 → 64 (부호 있는 곱 확장) */

/* Kernel NEON usage example: crypto/ghash-neon-arm64.c */

/* GHASH using NEON + ARM Crypto Extensions */
static void ghash_neon_update(struct ghash_ctx *ctx,
                                 const u8 *src, unsigned int len)
{
     uint64_t x[2], h[2];

     kernel_neon_begin();
     /* Load H key into NEON registers */
     vld1q_u64(h, (const uint64_t *)ctx->hash);

     while (len >= 16) {
         /* Load input block */
         vld1q_u64(x, (const uint64_t *)src);

         /* EORB with current state */
         x[0] = veorq_u64(x[0], ctx->x[0]);
         x[1] = veorq_u64(x[1], ctx->x[1]);

         /* Polynomial multiply (PMULL) — core of GHASH */
         /* ... NEON intrinsics for PMULL, EOR, shift ... */

         src += 16;
         len -= 16;
     }
     kernel_neon_end();
}

MTE (Memory Tagging Extension)

MTE가 활성화된 ARM64 시스템에서는 Tag Check Fault의 오버헤드가 발생합니다. 보안 검사와 성능 간의 Trade-off에서, Tag Allocation + Tag Checking을 모두 켰을 때 전반적으로 일부 성능 저하가 관찰되지만(정도는 하드웨어·워크로드에 따라 달라짐), 이는 사용 패턴(Heap 객체 수, Allocation 빈도, Cache Hit Rate)에 따라 달라집니다.

MTE가 성능에 미치는 영향:

• Tag Allocation: 16바이트 데이터마다 1바이트 태그를 저장하므로, 4KB 페이지당 256바이트가 Tag Storage로 사용됩니다(유효 용량 ≈ 3840바이트).
• Tag Compare: 각 Load/Store마다 태그 비교가 추가되어 소폭의 지연이 발생합니다(구현·캐시 상태에 따라 다름).
• Tag Check Fault: 불일치 시 Exception 발생 → Context Switch → 성능 대폭 저하.

MTE 설정이 성능에 미치는 영향을 최소화하려면:

• Tag Allocation만 활성(Tag Checking 비활성): 디버깅/프로파일링(Profiling) 모드에서 활용. Tag를 할당하지만 Violation을 Exception이 아닌 Ignore로 처리합니다.
• Huge Page + MTE: 2MB Huge Page를 사용하면 Tag Storage Overhead가 4KB Page 대비 1/512로 감소됩니다.
• SME Streaming Mode: Stream Mode는 Tag Storage를 참조하지 않으므로, MTE 오버헤드를 완전히 피할 수 있습니다.

# MTE Tag Storage 확인
cat /proc/cpuinfo | grep -i mte
# Features: ... fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
#           jpcre32 lrnd lse2 ssbs mte

# MTE 지원 여부 (cpuinfo 기능 문자열)
grep -w mte /proc/cpuinfo
# user-space MTE 제어 비트 확인
prctl PR_GET_TAGGED_ADDR_CTRL  # TCF bit 상태 반환

ARM64 NUMA 최적화

ARM64 서버(Graviton, Ampere, Apple Silicon)는 NUMA Aware 메모리 할당과 CPU Affinity 정책이 x86_64와 유사하게 동작합니다. 다만 ARM64는 ACPI 대신 Device Tree로 NUMA 토폴로지를 정의하므로, DTB(Device Tree Blob)에서 numa-node, memory, cpus 노드의 numa-node-id 속성으로 NUMA 노드-메모리-CPU 매핑을 정의합니다.

/* ARM64 Device Tree: NUMA 토폴로지 정의 예시 */

/ {
     #address-cells = <2>;
     #size-cells  = <2>;

     /* NUMA 노드 0: 물리 메모리 1GB @ 0x8_0000_0000 */
     memory@80000000 {
         device_type = "memory";
         reg = <0x0 0x80000000 0x0 0x40000000>;
         numa-node-id = <0>;
     };

     /* NUMA 노드 1: 물리 메모리 1GB @ 0xC_0000_0000 */
     memory@c0000000 {
         device_type = "memory";
         reg = <0x0 0xc0000000 0x0 0x40000000>;
         numa-node-id = <1>;
     };

     cpus {
         cpu0 {
             device_type = "cpu";
             reg = <0>;
             numa-node-id = <0>;
         };

         cpu4 {
             device_type = "cpu";
             reg = <4>;
             numa-node-id = <1>;
         };
     };
};

ARM64 캐시 및 TLB 최적화

ARM64는 캐시 라인 크기가 64바이트(Neoverse 기반 Graviton 등) 또는 128바이트(Apple M-series)로 x86_64와 다를 수 있습니다. TLB Entry 수는 아키텍처마다 다르며, TLB 최적화 측면에서 Huge Page, ASID, DSB ISH 명령의 효율적 활용이 중요합니다.

• Huge Pages: ARM64도 2MB/1GB Huge Page를 지원합니다. CONFIG_TRANSPARENT_HUGEPAGE와 CONFIG_HUGETLBFS를 활성화합니다.
• ASID 관리: ARM64에서 ASID는 TTBR0/TTBR1_EL1의 ASID 필드로 제어됩니다. ASID가 다르면 전체 TLB flush 없이 TTBR만 교체하여 기존 TLB 엔트리를 보존할 수 있습니다.
• DSB ISH 활용: 캐시 유지(Cache Maintenance) 작업 후 DSB ISH를 반드시 사용하여, 플러시가 완료되기 전에 새로운 접근이 발생하지 않도록 합니다.

/* ARM64 TLB flush 패턴 (arch/arm64/mm/tlbflush.c) */

/* Single address TLB flush (context-aware) */
void flush_tlb_page(struct vm_area_struct *vma, unsigned long address)
{
      /* ASID가 동일하면 단일 entry만 flush */
      __asm__ __volatile__(
           "dsb ish">           /* Ensure page table update visible */
           "tlbi vale1is, %0"  /* VA-based TLBI, EL1, Inner Shareable */    /* TLB Invalidate Virtual Address, EL1 */
           "dsb ish">           /* Ensure TLBI complete */
           "isb">               /* Pipeline flush */
           : : "r"(address) : "memory"
      );
}

/* ASID가 다르면(다른 process) — global TLB flush */
void flush_tlb_all(void)
{
      __asm__ __volatile__(
           "dsb ish">
           "tlbi vmalle1is"  /* All-addresses TLBI, EL1, Inner Shareable */    /* Global TLB invalidate, all ASIDs */
           "dsb ish">
           "isb">
           : : : "memory"
      );
}

ARM64 성능 모니터링 (PMU / CoreSight)

ARM64의 PMU(Performance Monitoring Unit)는 architected register로 PMCR_EL0, PMCNTENSET_EL0, PMCCNTR_EL0(사이클 카운터) 등으로 접근합니다. 또한 ARM CoreSight는 실행 시점의 Hardware trace를 제공하는데, Intel PT의 ARM64 대응 도구라고 볼 수 있습니다.

# 시스템의 PMU 목록 확인 (cpu, etm4x 등)
ls /sys/bus/event_source/devices/

# perf with ARM PMU
perf stat -e cycles,instructions,cache-misses -- ./benchmark

# CoreSight ETM trace (CONFIG_CORESIGHT_ETM* 필요)
perf record -e cs_etm// -- ./benchmark
perf script

# CPU 토폴로지 확인 (예시 sysfs)
cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

/* ARM64 PMU Register 접근 (kernel code) */

/* PMCR_EL0: Performance Monitor Control Register */
static void pmu_enable_counters(void)
{
      u64 val;

      /* C bit: 이벤트 카운터 리셋, E bit: PMU 인에이블 */
      asm volatile("msr pmcr_el0, %0" : : "r"((u64)0x00000005) : "memory");

      /* Enable all counters */
      asm volatile("msr pmcntenset_el0, %0" : : "r"((u64)0xFFFFFFFF) : "memory");

      /* Enable PMU */
      asm volatile("mrs %0, pmcr_el0" : "=r"(val));
     val |= (1 << 0);  /* E bit: Enable */
      asm volatile("msr pmcr_el0, %0" : : "r"(val) : "memory");
}

실전 디버깅(Debugging) 팁 (Debugging Tips)

아키텍처별 커널 디버깅은 각 플랫폼의 특성을 이해하고 적절한 도구를 사용해야 효과적입니다.

공통 디버깅 기법

디버깅 도구에는 계층이 있습니다. 가장 가벼운 커널 로그(pr_*/WARN_ON)로 현장을 포착하고, 재현이 어려운 타이밍 문제는 ftrace/tracing으로 이벤트 순서를 기록하며, 패닉 발생 시에는 kdump/kexec로 메모리 덤프를 확보해 post-mortem 분석하는 것이 표준 절차입니다. 하드웨어 디버거(JTAG 등)는 부팅 초기 단계나 시뮬레이터 환경에서 마지막 수단으로 사용합니다.

아키텍처에 상관없이 가장 먼저 활용해야 할 도구는 커널 로그(pr_debug/pr_err)와 WARN_ON() 계열 매크로입니다. 이 두 가지는 별도 장비 없이도 즉시 사용할 수 있고, 문제 발생 위치와 콜스택을 빠르게 좁혀 주기 때문에 항상 첫 번째 수단으로 삼아야 합니다. 아키텍처 특화 도구(JTAG, CoreSight 등)는 그다음 단계입니다.

/* 커널 디버그 출력 */
pr_debug("Variable x = %d\\n", x);         /* 동적 디버그(dyndbg)로 활성화 시 출력 */
pr_info("Info message\\n");                /* 정보성 메시지 */
pr_warn("Warning: %s\\n", msg);           /* 경고 */
pr_err("Error: %d\\n", errno);            /* 에러 */

/* WARN 및 BUG 매크로 */
WARN_ON(condition);                       /* 조건 만족 시 경고 + 백트레이스 */
WARN_ONCE(condition, "message");          /* 최초 1회만 경고 */
BUG_ON(critical_error);                   /* 치명적 에러 시 패닉 (사용 자제) */

/* 동적 디버그 */
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
pr_debug("Entry: func=%s\\n", __func__);

x86_64 특화 디버깅

x86_64는 Intel PT(Processor Trace)와 MSR 직접 접근이라는 강력한 하드웨어 도구를 제공합니다. Intel PT는 분기 명령 실행 이력을 하드웨어가 기록하므로, 이미 크래시가 발생한 후에도 어떤 경로로 실행되었는지 재구성할 수 있습니다. 일반적인 printk 디버깅으로는 타이밍 문제를 재현하기 어려운 경쟁 조건(Race Condition) 디버깅에 특히 유용합니다.

ARM64 특화 디버깅

ARM64 플랫폼은 대부분 임베디드·서버 보드이기 때문에 UART 시리얼 콘솔이 핵심 디버깅 수단입니다. 부팅 초기에 출력이 없다면 earlycon 파라미터로 직렬 포트(Serial Port)를 직접 지정해야 합니다. 칩 내부 트레이스가 필요한 경우에는 CoreSight ETM(Embedded Trace Macrocell)을 활용하며, 이는 Intel PT의 ARM 대응 기능입니다. Device Tree 구성 오류는 /proc/device-tree/와 dtc로 덤프해서 비교하는 것이 가장 빠릅니다.

RISC-V 특화 디버깅

실제 RISC-V 하드웨어 없이 시작하기 가장 좋은 방법은 Spike ISA 시뮬레이터 또는 QEMU RISC-V입니다. 두 환경 모두 커널 부팅 로그를 터미널로 받아볼 수 있으며, 실리콘이 없는 상태에서 SBI·CSR 동작을 검증하는 데 유용합니다. 실제 보드를 사용할 경우, RISC-V JTAG 디버그 스펙은 x86/ARM보다 최근에 정의되었으므로 보드마다 지원 품질이 다릅니다. 보드 문서에서 지원 디버그 Transport(JTAG/cJTAG)를 먼저 확인하세요.

MIPS 특화 디버깅

MIPS는 하드웨어 없이 시작하기에 가장 쉬운 대상 중 하나입니다. QEMU가 Malta 보드(qemu-system-mips/qemu-system-mipsel)와 MIPS virt 머신(-M virt)을 지원하며, TLB 소프트웨어 관리 특성상 TLB 관련 예외가 부팅 초기에 자주 발생하므로 이를 관찰하는 것이 디버깅의 핵심입니다.

# MIPS32 (little-endian, Malta) QEMU 실행 예
qemu-system-mipsel -M malta \
    -kernel vmlinux \
    -append "console=ttyS0" \
    -nographic

자주 묻는 질문 (FAQ)

Q1. 어떤 아키텍처를 선택해야 하나요?

A: 사용 목적에 따라 다릅니다:

• x86_64: 데스크탑, 서버, 클라우드 환경. 가장 성숙한 생태계와 도구 지원
• ARM64: 모바일, 임베디드, 저전력 서버 (AWS Graviton, Apple Silicon). 전력 효율 우수
• RISC-V: 연구, 교육, 새로운 HW 프로젝트. 오픈 ISA로 라이선스 비용 없음
• MIPS: 레거시 라우터·임베디드 기기 유지보수 또는 소프트웨어 관리 TLB 등 RISC 설계 학습 목적. 신규 HW는 RISC-V 권장

Q2. 크로스 컴파일(Cross Compilation)은 어떻게 하나요?

A: ARCH와 CROSS_COMPILE 변수를 설정합니다:

# ARM64 크로스 컴파일 (x86_64 호스트)
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

# RISC-V 크로스 컴파일
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j$(nproc)

자세한 내용은 빌드 시스템 문서를 참고하세요.

Q3. 32비트 커널도 여전히 사용되나요?

A: 예, 특정 임베디드 환경에서는 여전히 사용됩니다. ARM32 (AArch32), x86 (i386), MIPS32 등은 레거시 시스템이나 자원 제약 환경에서 사용되지만, 새로운 프로젝트는 대부분 64비트 아키텍처를 선택합니다. 주요 배포판들은 x86 32비트 지원을 점차 종료하고 있습니다.

Q4. ARM64의 big.LITTLE은 무엇인가요?

A: 고성능 코어(big)와 저전력 코어(LITTLE)를 조합한 이기종 멀티프로세싱(HMP) 아키텍처입니다. 리눅스 커널은 Energy Aware Scheduling (EAS)를 통해 워크로드에 따라 적절한 코어에 태스크(Task)를 할당합니다. 최신 ARM 시스템은 DynamIQ 기술을 사용하여 더 유연한 코어 조합을 지원합니다. 자세한 내용은 프로세스 스케줄러 문서를 참고하세요.

Q5. 페이지 테이블 레벨은 어떻게 결정되나요?

A: 가상 주소 공간 크기에 따라 결정됩니다:

• x86_64: 4-level (48-bit VA), 5-level (57-bit VA, CONFIG_X86_5LEVEL)
• ARM64: 3-level(SV39)/4-level(SV48)/5-level(SV57, 56-bit VA) — VA 폭과 페이지 크기에 따라 결정
• RISC-V: Sv39 (3-level), Sv48 (4-level), Sv57 (5-level)

레벨이 많을수록 주소 공간은 넓어지지만 페이지 테이블 워킹 오버헤드가 증가합니다. 자세한 내용은 메모리 관리 문서를 참고하세요.

Q6. 아키텍처별 시스템 콜 차이는?

A: 시스템 콜 번호와 진입 메커니즘이 다릅니다:

• x86_64: syscall 명령어, 번호는 arch/x86/entry/syscalls/syscall_64.tbl
• ARM64: svc #0 명령어, 번호는 include/uapi/asm-generic/unistd.h
• RISC-V: ecall 명령어, 번호는 주로 asm-generic/unistd.h를 사용해 ARM64와 많은 항목을 공유

모든 아키텍처는 공통 시스템 콜 인터페이스를 제공하지만, 일부 아키텍처별 시스템 콜이 존재할 수 있습니다. 자세한 내용은 시스템 콜 (System Call) 문서를 참고하세요.

Q7. 가상화 오버헤드는 얼마나 되나요?

A: 하드웨어 가상화 지원 여부에 따라 크게 다릅니다:

• Hardware-assisted (VT-x, AMD-V, ARM VHE, RISC-V H-ext): 다소의 오버헤드 (정도는 워크로드 의존)
• Paravirtualization (Xen PV): 하드웨어 지원 없을 때 사용, 오버헤드 더 높음
• I/O 가상화: 네트워크, 디스크 I/O에서 오버헤드 큼 → virtio, SR-IOV로 완화

현대 시스템에서는 하드웨어 가상화 지원이 표준이므로 오버헤드가 크지 않습니다. 자세한 내용은 가상화 (KVM) 문서를 참고하세요.

Q8. PREEMPT_RT와 PREEMPT의 차이는 무엇인가요?

A: 두 옵션은 선점(preemption) 범위가 다릅니다:

• CONFIG_PREEMPT — 커널 코드 대부분을 선점할 수 있지만, 스핀락(spinlock) 내부와 같은 임계 구간은 선점 불가능합니다. 일반 데스크탑/서버 환경에 적합합니다.
• CONFIG_PREEMPT_RT (v6.12 메인라인 병합) — 스핀락을 RT-mutex로 변환하고, 인터럽트 핸들러를 스레드화하여 거의 모든 커널 경로를 선점할 수 있습니다. 일반 커널 대비 훨씬 낮은 지연 분산을 제공해 산업 제어, 로봇 공학, 프로 오디오 등에 사용됩니다(실측 지연은 워크로드·하드웨어에 따라 다름).

v6.12 이전에는 별도의 외부 패치(Patch)(rt-patches)를 적용해야 했으나, 이제 메인라인 커널만으로 실시간(Real-time) 커널을 빌드할 수 있습니다. 자세한 내용은 RT-Mutex 문서를 참고하세요.

Q9. FRED가 기존 IDT를 완전히 대체하나요?

A: FRED(Flexible Return and Event Delivery)는 Intel이 도입한 새로운 이벤트 전달 메커니즘으로, v6.12에서 커널 지원이 추가되었습니다.

• 대체 범위 — FRED는 예외(Exception)와 인터럽트 전달 경로를 IDT(Interrupt Descriptor Table) 기반에서 전용 하드웨어 메커니즘으로 대체합니다. 스택 전환, 레지스터 저장, 이벤트 레벨 분류를 하드웨어가 자동으로 처리합니다. SYSCALL/SYSRET 시스템 콜 경로는 그대로 유지됩니다.
• 호환성 — FRED를 지원하지 않는 프로세서에서는 기존 IDT 방식이 그대로 사용됩니다. 커널은 부팅 시 CPU 기능을 감지하여 자동으로 적절한 경로를 선택합니다.
• 이점 — 커널 진입/복귀 오버헤드 감소, 중첩 이벤트 처리 효율화, 레거시 진입 방식의 특수한 동작(quirk) 제거 등의 장점이 있습니다.

CPU 제조사 아키텍처 매뉴얼 (Architecture Software Developer's Manuals)

리눅스 커널 개발에서 각 CPU 제조사의 공식 아키텍처 매뉴얼은 가장 권위 있고 정확한 참조 문서입니다. 커널 코드의 아키텍처 의존 부분(arch/ 디렉토리)을 이해하거나 수정할 때 반드시 해당 매뉴얼을 참조해야 합니다.

Intel® 64 and IA-32 Architectures Software Developer's Manual (Intel SDM)

AMD64 Architecture Programmer's Manual (AMD APM)

ARM Architecture Reference Manual (ARM ARM)

RISC-V Specifications

RISC-V는 단일 문서가 아니라 용도별 볼륨으로 나뉘어 있는 스펙 체계입니다. Unprivileged ISA는 사용자 레벨 명령어를, Privileged ISA는 특권 모드·CSR·메모리 관리·인터럽트를 정의하며, SBI/PLIC/AIA 같은 플랫폼 인터페이스 스펙은 펌웨어(OpenSBI)와 인터럽트 컨트롤러 연동을 규정합니다. 아래 표는 각 문서가 커널 개발에서 어디에 쓰이는지를 정리한 것입니다.

MIPS Architecture Reference Manuals

MIPS 사양은 아키텍처 버전(Release)별로 문서 유형이 나뉩니다. CP0 레지스터·예외·TLB 동작은 Privileged Resource Architecture (MD00090)에 수록되어 있으며, 명령어 집합은 MIPS32/MIPS64 Architecture Reference Manual에서 다룹니다. 정식 문서 배포는 Wave Computing(구 Imagination)의 MIPS 지원 페이지에서 과거 PDF(MD00086/MD00087 등)로 제공되었으며, 현재는 검증된 사본이 커널 커뮤니티·교육 자료로 유통됩니다.

매뉴얼 효과적 활용법

아키텍처 매뉴얼은 전부를 읽을 필요가 없습니다. 어떤 현상을 설명하는지 먼저 파악하고, 아래 표처럼 상황별로 필요한 챕터만 찾아보는 방식이 가장 효율적입니다. 레지스터 필드나 비트 위치를 확인할 때는 매뉴얼의 레지스터 요약표(Register Summary)를 먼저 보고, 상세 동작은 해당 챕터 본문으로 이동하세요.

AMD vs Intel 마이크로아키텍처 비교 (Microarchitecture Comparison)

x86_64 프로세서를 제조하는 두 벤더 — AMD와 Intel — 는 동일한 ISA(명령어 셋 아키텍처)를 구현하지만, 내부 마이크로아키텍처 설계 철학이 근본적으로 다릅니다. 이 차이는 커널의 스케줄러, NUMA 정책, 캐시 관리, 전력 제어 코드에 직접적인 영향을 미칩니다.

칩렛(Chiplet) vs 모놀리식/타일(Tile) 설계

인터커넥트 토폴로지 비교

파이프라인(Pipeline) 및 실행 엔진 비교

마이크로아키텍처 세대별 파이프라인 폭과 내부 자원의 차이는 IPC(클록당 명령어 수)와 분기 예측 정확도에 직접 영향을 미치며, 커널의 성능 최적화 결정에도 관련됩니다. 아래 표의 디코드 폭·ROB 크기 등은 제조사 공식 수치와 커뮤니티 리버스 엔지니어링 값을 함께 정리한 것입니다.

x86 CPU 실행 모드 (Operating Modes)

x86 프로세서는 리셋 후 리얼 모드(Real Mode)에서 시작하여 여러 모드를 거쳐 롱 모드(Long Mode)에 도달합니다. 리눅스 커널 부팅 과정은 이 모드 전환을 순차적으로 수행하며, 각 모드의 특성을 이해하는 것은 부트로더 코드와 커널 초기화 코드를 분석하는 데 필수적입니다.

모드 전환 흐름

Real Mode (리얼 모드)

Real Mode는 1978년 Intel 8086 설계 당시 유일한 실행 모드였습니다. 당시 메모리는 1MB가 최대였고, 메모리 보호 개념 자체가 없었기 때문에 모든 코드가 하드웨어에 직접 접근할 수 있었습니다. 현대 x86_64 시스템에서 Real Mode는 부팅 직후 펌웨어(BIOS/UEFI) 환경에서만 사용됩니다. CPU가 전원을 켜는 순간에는 하위 호환성을 위해 항상 Real Mode로 시작하고, 이후 Protected Mode → Long Mode 순으로 전환합니다. 즉, 커널 개발자가 Real Mode 코드를 직접 작성할 일은 거의 없지만, 부팅 초기 실패를 디버깅할 때 이 모드의 제약(16비트, 1MB 주소)을 이해하고 있어야 합니다.

; Real Mode 초기 부팅 코드 개념 예시 (실제 코드: arch/x86/boot/compressed/head_32.S 등)
; 부트로더가 커널 이미지를 로우 메모리에 로드한 뒤 진입점부터 실행됨

; A20 게이트 활성화 (20번째 주소 라인)
; A20이 비활성이면 1MB 이상 주소에 접근 불가
    in      al, 0x92        ; Fast A20 (System Port)
    or      al, 2
    out     0x92, al

; Protected Mode로 전환 준비
    lgdt    [gdt_ptr]        ; GDT 로드
    mov     eax, cr0
    or      eax, 1           ; PE (Protection Enable) 비트 설정
    mov     cr0, eax         ; → Protected Mode 진입!
    jmp     0x08:pm_entry   ; far jump로 CS 갱신 (GDT 셀렉터 0x08)

Protected Mode (보호 모드)

Protected Mode는 Intel 80286에서 도입되고 80386에서 완성된 32비트 실행 모드입니다. Real Mode의 한계(1MB 주소, 보호 없음)를 극복하여 4GB 주소 공간, 하드웨어 메모리 보호, 특권 레벨(Ring)을 제공합니다. 리눅스 32비트 커널(i386)은 이 모드에서 동작하며, 64비트 부팅에서도 Long Mode 진입 전 필수 경유 단계입니다.

Protected Mode 진입 상세

Real Mode에서 Protected Mode로 전환하려면 다음 단계를 정확한 순서로 수행해야 합니다. 하나라도 빠지면 트리플 폴트(Triple Fault)로 시스템이 리셋됩니다.

; Protected Mode 진입 전체 흐름 (arch/x86/boot/pmjump.S 기반)

; ① 인터럽트 비활성화 — 모드 전환 중 인터럽트 금지
    cli

; ② A20 게이트 활성화 — 1MB 이상 메모리 접근 가능하게
    in      al, 0x92        ; Fast A20 (System Port)
    or      al, 2
    out     0x92, al

; ③ GDT 로드 — 세그먼트 디스크립터 테이블 설정
    lgdt    [gdt_ptr]        ; GDTR에 GDT base + limit 적재

; ④ CR0.PE = 1 — Protection Enable 비트 설정
    mov     eax, cr0
    or      eax, 1           ; PE 비트 (bit 0)
    mov     cr0, eax         ; → 이 순간 Protected Mode 진입!

; ⑤ far jump — CS를 GDT 코드 세그먼트 셀렉터로 갱신
;    이것이 없으면 명령어 프리페치 큐에 Real Mode 코드가 남아 있음
    jmp     0x08:pm_entry   ; GDT[1] = 코드 세그먼트 (셀렉터 0x08)

; ⑥ 데이터 세그먼트 레지스터 재적재
pm_entry:
    .code32
    mov     ax, 0x10        ; GDT[2] = 데이터 세그먼트 (셀렉터 0x10)
    mov     ds, ax
    mov     es, ax
    mov     fs, ax
    mov     gs, ax
    mov     ss, ax
    mov     esp, stack_top   ; 32비트 스택 설정

세그먼테이션 (Segmentation)

Protected Mode의 핵심 메커니즘은 세그먼테이션입니다. 모든 메모리 접근은 세그먼트 셀렉터를 통해 GDT/LDT의 디스크립터를 참조하여 선형 주소(Linear Address)로 변환됩니다.

GDT 엔트리 구조

/* GDT 엔트리 구조 (Intel SDM Vol.3 Section 3.4.5) */
struct gdt_entry {
    u16 limit_low;        /* 세그먼트 크기 [15:0]         (바이트 0-1) */
    u16 base_low;         /* 베이스 주소 [15:0]           (바이트 2-3) */
    u8  base_mid;          /* 베이스 주소 [23:16]          (바이트 4)   */
    u8  access;            /* P | DPL(2) | S | Type(4)     (바이트 5)   */
    u8  granularity;       /* G | D/B | L | AVL | Limit[19:16] (바이트 6) */
    u8  base_high;         /* 베이스 주소 [31:24]          (바이트 7)   */
} __attribute__((packed));

/* Access 바이트 비트 분해:
 * bit 7    : P   (Present) — 1이면 세그먼트 유효, 0이면 #NP 예외
 * bit 6-5  : DPL (Descriptor Privilege Level) — 00=Ring 0 ~ 11=Ring 3
 * bit 4    : S   (System) — 1=코드/데이터, 0=시스템(TSS, Call Gate 등)
 * bit 3-0  : Type — S=1일 때:
 *   코드: bit3=1, bit2=Conforming, bit1=Readable, bit0=Accessed
 *   데이터: bit3=0, bit2=Expand-down, bit1=Writable, bit0=Accessed
 */

/* Granularity 바이트 비트 분해:
 * bit 7    : G   (Granularity) — 0=바이트, 1=4KB 단위 (Limit × 4KB)
 * bit 6    : D/B (Default size) — 코드: 0=16bit, 1=32bit / 스택: 0=SP, 1=ESP
 * bit 5    : L   (Long mode) — 1=64bit 코드 (Long Mode 전용, D=0 필수)
 * bit 4    : AVL (Available) — OS가 자유롭게 사용
 * bit 3-0  : Limit [19:16] — Limit 상위 4비트
 */

Linux GDT 레이아웃

/* arch/x86/include/asm/segment.h — Linux GDT 레이아웃 */

/* 셀렉터 값 = (인덱스 << 3) | TI | RPL */
#define GDT_ENTRY_KERNEL32_CS   1   /* 0x08: Ring 0 32-bit 코드 */
#define GDT_ENTRY_KERNEL_CS     2   /* 0x10: Ring 0 64-bit 코드 */
#define GDT_ENTRY_KERNEL_DS     3   /* 0x18: Ring 0 데이터 */
#define GDT_ENTRY_DEFAULT_USER32_CS 4 /* 0x23: Ring 3 32-bit 코드 (RPL=3) */
#define GDT_ENTRY_DEFAULT_USER_DS   5 /* 0x2B: Ring 3 데이터 */
#define GDT_ENTRY_DEFAULT_USER_CS   6 /* 0x33: Ring 3 64-bit 코드 */
#define GDT_ENTRY_TSS           8   /* 0x40: TSS 디스크립터 슬롯 (인덱스 9는 미사용) */
#define GDT_ENTRY_LDT          10  /* 0x50: LDT 디스크립터 슬롯 (인덱스 11은 미사용) */
#define GDT_ENTRY_TLS_MIN      12  /* 0x60: TLS 엔트리 시작 */
#define GDT_ENTRY_PER_CPU      15  /* 0x78: per-CPU 데이터 */

/* Linux의 Flat 세그먼트 설정:
 * 코드/데이터 세그먼트 모두 Base=0, Limit=0xFFFFF, G=1
 * → 선형 주소 0x00000000 ~ 0xFFFFFFFF (4GB) 전체 커버
 * → 세그먼테이션을 사실상 무력화하고 페이징에 보호를 위임 */

Protected Mode 페이징 (2-Level)

페이징이 활성화되면(CR0.PG=1) 선형 주소는 페이지 디렉토리(PD)와 페이지 테이블(PT) 2단계를 거쳐 물리 주소로 변환됩니다.

Ring 전환 메커니즘

Protected Mode의 Ring 전환(유저 → 커널, 커널 → 유저)은 인터럽트/예외, SYSENTER/SYSEXIT, Call Gate를 통해 수행됩니다. Ring 전환 시 CPU는 자동으로 TSS에서 새 Ring의 스택(SS:ESP)을 로드합니다.

/* Ring 전환 시 CPU 자동 동작:
 *
 * Ring 3 → Ring 0 (인터럽트/예외):
 *   1. TSS에서 Ring 0의 SS0:ESP0 로드
 *   2. 이전 SS:ESP를 새 스택에 push
 *   3. EFLAGS push
 *   4. CS:EIP push (복귀 주소)
 *   5. 에러 코드 push (해당 시)
 *   6. IDT에서 새 CS:EIP 로드 → 핸들러 진입
 *
 * Ring 0 → Ring 3 (IRET):
 *   1. 스택에서 EIP, CS, EFLAGS pop
 *   2. CS의 RPL이 현재 CPL보다 높으면 (유저 복귀)
 *   3. 스택에서 ESP, SS 추가 pop
 *   4. Ring 3 코드 실행 재개
 */

/* SYSENTER/SYSEXIT (Pentium II+, 32비트):
 * SYSENTER: Ring 3 → Ring 0 (MSR에서 CS/EIP/ESP 로드)
 *   IA32_SYSENTER_CS  (0x174) → 커널 CS
 *   IA32_SYSENTER_ESP (0x175) → 커널 ESP
 *   IA32_SYSENTER_EIP (0x176) → 커널 진입점
 * SYSEXIT:  Ring 0 → Ring 3 (ECX=유저 ESP, EDX=유저 EIP)
 */
wrmsrl(MSR_IA32_SYSENTER_CS, __KERNEL_CS);
wrmsrl(MSR_IA32_SYSENTER_ESP, tss->x86_tss.sp0);
wrmsrl(MSR_IA32_SYSENTER_EIP,
    (unsigned long)entry_SYSENTER_32);

PAE (Physical Address Extension)

PAE 모드에서는 물리 주소가 36비트로 확장되어 기존 32비트 PDE/PTE로는 전체 프레임 주소를 담을 수 없게 됩니다. 그래서 커널은 Page Directory(PD) 위에 PDPT(Page Directory Pointer Table)라는 한 단계를 더 두며, PDPT의 각 엔트리는 64비트 폭으로 52비트 물리 프레임 주소와 제어 비트를 함께 가집니다. 이때 CR3에는 PD의 주소 대신 PDPT의 물리 주소가 적재됩니다. PDE/PTE 자체가 64비트가 되면서 bit 63을 NX(No-Execute) 비트로 활용할 수 있게 되는데, 이것이 DEP(Data Execution Prevention)/W^X 정책의 하드웨어 기반입니다.

리눅스에서 PAE가 사용되는 곳은 크게 두 곳입니다. 첫째, 32비트(x86) 커널은 CONFIG_X86_PAE=y 빌드에서 4GB 초과 RAM 시스템을 지원하기 위해 PAE를 사용합니다. 둘째, 64비트(x86_64) 부팅 경로에서는 EFER.LME 기록이 CR4.PAE=1을 요구하므로, Real Mode에서 Long Mode로 넘어가는 중간 단계로 PAE를 일시적으로 활성화한 뒤 64비트 PTE 기반 4-level 페이징으로 전환합니다.

Long Mode (IA-32e Mode / 64-bit Mode)

Long Mode는 x86-64 확장에 의해 정의된 64비트 실행 모드로, ISA의 마케팅 명칭으로는 AMD64·Intel EM64T가 있으며 Intel SDM 문서에서는 IA-32e mode라고 표기합니다. 64비트 범용 레지스터, 최대 256TB(48비트) 또는 128PB(57비트) 가상 주소 공간, 4-/5-level 페이징, SYSCALL/SYSRET 고속 시스템 콜, NX(No-Execute) 비트 등을 제공합니다. 현대 리눅스 커널(x86_64)은 이 모드에서 동작합니다.

Long Mode 진입 상세

Protected Mode에서 Long Mode로의 전환은 정확한 순서가 필수입니다. 순서가 틀리면 #GP(General Protection Fault) 또는 Triple Fault가 발생합니다.

; arch/x86/boot/compressed/head_64.S — Long Mode 전환 (간략화)
    .code32
startup_32:
; ① 페이징이 켜져 있으면 끔 (UEFI에서 올 때)
    movl    %cr0, %eax
    andl    $~X86_CR0_PG, %eax
    movl    %eax, %cr0

; ② PAE 활성화
    movl    %cr4, %eax
    orl     $X86_CR4_PAE, %eax
    movl    %eax, %cr4

; ③ Identity-mapped PML4 페이지 테이블 구성
;    가상주소 = 물리주소 (전환 직후 코드가 같은 주소에서 실행되도록)
    leal    pgtable(%ebx), %edi
    xorl    %eax, %eax
    movl    $(BOOT_INIT_PGT_SIZE/4), %ecx
    rep     stosl                  ; 0으로 초기화

    ; PML4[0] → PDPT
    leal    pgtable + 0x1007(%ebx), %eax
    movl    %eax, pgtable + 0(%ebx)

    ; PDPT[0] → PD (PD 안의 PDE들이 PS=1로 2MB 대형 페이지 매핑)
    leal    pgtable + 0x2007(%ebx), %eax
    movl    %eax, pgtable + 0x1000(%ebx)

; ④ CR3에 PML4 물리 주소 적재
    leal    pgtable(%ebx), %eax
    movl    %eax, %cr3

; ⑤ EFER.LME = 1 (Long Mode Enable)
    movl    $MSR_EFER, %ecx
    rdmsr
    btsl    $_EFER_LME, %eax       ; bit 8
    wrmsr

; ⑥ CR0.PG = 1 → Long Mode 활성화!
;    이 순간 EFER.LMA=1이 자동으로 설정됨
    movl    %cr0, %eax
    orl     $X86_CR0_PG, %eax
    movl    %eax, %cr0

; ⑦ far JMP → 64-bit 코드 세그먼트 (CS.L=1)
;    이 JMP는 CPU의 명령어 디코더를 64-bit 모드로 전환
    ljmpl   $__KERNEL_CS, $startup_64

; === 여기서부터 64-bit 코드 ===
    .code64
startup_64:
    ; 64-bit 레지스터 사용 가능
    xorq    %rax, %rax     ; 64-bit zero
    movq    %rax, %ds      ; Long Mode에서 DS/ES/SS base=0 강제
    movq    %rax, %es
    movq    %rax, %ss
    movq    %rax, %fs
    movq    %rax, %gs

4-Level 페이징 (PML4)

Long Mode에서 페이징은 필수이며, 최소 4단계 페이지 테이블을 사용합니다. 각 테이블은 512개 엔트리(각 8바이트)로 구성되어 4KB를 차지합니다.

Protected Mode vs Long Mode 페이징 비교

레지스터 확장

Long Mode에서는 기존 8개 범용 레지스터가 64비트로 확장되고, R8~R15 8개 레지스터가 추가됩니다. REX 프리픽스가 이 확장 레지스터 접근을 가능하게 합니다.

Long Mode에서의 세그먼테이션 변화

Long Mode는 세그먼테이션을 대부분 비활성화합니다. Protected Mode에서 핵심이었던 세그먼트 Base/Limit이 무시됩니다.

/* Long Mode에서 FS/GS Base 설정 (MSR 사용) */
/* 커널 per-CPU 데이터 접근: GS Base */
wrmsrq(MSR_GS_BASE, per_cpu_offset(cpu));
/* 이후 %gs:offset 으로 per-CPU 변수 접근 */
/* 예: movq %gs:current_task, %rax → 현재 task_struct */

/* 유저 TLS(Thread-Local Storage): FS Base */
wrmsrq(MSR_FS_BASE, thread->fsbase);
/* glibc의 __thread 변수는 FS Base 기준으로 접근 */

/* SWAPGS: 시스템 콜 진입 시 GS 교체 */
/* SYSCALL → GS = 유저 값 → SWAPGS → GS = 커널 per-CPU */
/* SYSRET 전 → SWAPGS → GS = 유저 값 복원 */

Long Mode 서브모드

Protected Mode vs Long Mode 종합 비교

CPU 모드 전환 주의사항

제어 레지스터(CR) 요약

Descriptor Table 레지스터 구조

GDTR/IDTR 레지스터는 GDT와 IDT의 위치를 CPU에 알려주는 특수 레지스터입니다. LGDT/LIDT 명령어로 메모리의 의사 디스크립터(Pseudo-Descriptor)를 읽어 적재하며, Protected Mode에서는 48비트(6바이트), Long Mode에서는 80비트(10바이트) 구조를 사용합니다.

리눅스 커널은 arch/x86/include/asm/desc.h에서 GDT/IDT 적재를 위한 인라인 함수(Inline Function)를 제공합니다:

/* arch/x86/include/asm/desc.h */

/* LGDT/LIDT 명령어가 받는 6/10바이트 메모리 구조 */
struct desc_ptr {
    u16 size;       /* 테이블 바이트 크기 - 1 (Limit) */
    u64 address;    /* 테이블 선형 주소 (Base) */
} __attribute__((packed));

static __always_inline void native_load_gdt(const struct desc_ptr *dtr)
{
    asm volatile("lgdt %0" : : "m"(*dtr));
}

static __always_inline void native_load_idt(const struct desc_ptr *dtr)
{
    asm volatile("lidt %0" : : "m"(*dtr));
}

/* 사용 예시: 부팅 시 GDT 설정 */
/* arch/x86/kernel/head64.c */
struct desc_ptr gdt_descr = {
    .size    = GDT_SIZE - 1,
    .address = (unsigned long)get_cpu_gdt_rw(0),
};
load_gdt(&gdt_descr);

세그먼트 디스크립터 비트 필드 상세

GDT/LDT의 각 엔트리는 8바이트(64비트) 세그먼트 디스크립터입니다. 비트 배치가 연속적이지 않아 소프트웨어에서 직접 조립할 때 주의가 필요합니다. 인텔 SDM Vol.3 Section 3.4.5의 "Segment Descriptor"를 기준으로 설명합니다. 아래 다이어그램의 필드 폭은 가독성 확보를 위한 개략치이며 실제 비트 비례가 아닙니다.

/* GDT_ENTRY() 매크로 — arch/x86/include/asm/desc_defs.h */
/* base: 32비트 세그먼트 베이스, limit: 20비트 크기, flags: 접근·세분성 바이트 */
#define GDT_ENTRY(flags, base, limit)                                  \
    ((((base)  & _AC(0xff000000,ULL)) << (56-24)) | \
     (((flags) & _AC(0x0000f0ff,ULL)) << 40)      | \
     (((limit) & _AC(0x000f0000,ULL)) << (48-16)) | \
     (((base)  & _AC(0x00ffffff,ULL)) << 16)       | \
     (((limit) & _AC(0x0000ffff,ULL))))

/* 사용 예: Ring 0 64-bit 코드 세그먼트 (CS=0x10, Long Mode) */
/* flags=0xa09b: G=1, L=1, P=1, DPL=0, S=1, Type=0xb (코드/실행/읽기) */
GDT_ENTRY(0xa09b, 0, 0xfffff)

시스템 세그먼트 디스크립터 (S=0)

GDT 디스크립터의 S(Descriptor Type) 비트가 0이면 시스템 디스크립터입니다. 코드/데이터 세그먼트(S=1)와 달리 TSS, LDT, 각종 Gate를 기술합니다. Long Mode에서 TSS와 LDT 디스크립터는 128비트(16바이트)로 확장되어 GDT에서 연속된 두 슬롯을 차지합니다. 다이어그램의 필드 폭은 실제 비트 비례가 아닌 개략치입니다.

리눅스 커널은 arch/x86/include/asm/desc_defs.h에서 시스템 디스크립터를 위한 구조체(Struct)를 정의합니다:

/* arch/x86/include/asm/desc_defs.h */

/* Long Mode TSS/LDT 디스크립터: GDT에서 연속된 2슬롯(16바이트) 차지 */
struct ldttss_desc {
    u16 limit0;         /* Limit[15:0] */
    u16 base0;          /* Base[15:0] */
    unsigned base1:8,   /* Base[23:16] */
             type:5,    /* Type (S=0 포함된 5비트) */
             dpl:2,     /* 디스크립터 권한 레벨 */
             p:1;       /* Present 비트 */
    unsigned limit1:4,  /* Limit[19:16] */
             zero0:3,   /* Reserved = 0 */
             g:1,       /* Granularity (1=4KB 단위) */
             base2:8;   /* Base[31:24] */
    u32 base3;          /* Base[63:32] — 두 번째 QWord */
    u32 zero1;          /* Reserved = 0 */
} __attribute__((packed));

/* TSS 디스크립터 설정 — arch/x86/kernel/cpu/common.c의 cpu_init() */
/* TSS 디스크립터는 cpu_entry_area 내부가 아니라 GDT 슬롯에 기록됩니다 */
set_tss_desc(cpu, &get_cpu_entry_area(cpu)->tss);

IDT 게이트 디스크립터 구조 상세

64비트 Long Mode의 IDT 엔트리는 16바이트(128비트)로, Protected Mode의 8바이트에서 확장되었습니다. 핸들러 오프셋이 64비트로 늘어났으며, IST(Interrupt Stack Table) 필드가 추가되어 중첩 예외 상황에서도 안전한 전용 스택을 사용할 수 있습니다. 다이어그램의 필드 폭은 실제 비트 비례가 아닌 개략치입니다.

/* struct gate_struct — arch/x86/include/asm/desc_defs.h */
struct gate_struct {
    u16    offset_low;    /* 핸들러 주소 [15:0] */
    u16    segment;       /* 코드 세그먼트 셀렉터 (예: __KERNEL_CS = 0x10) */
    struct idt_bits bits; /* IST[2:0] | 0[4:0] | Type[3:0] | 0 | DPL[1:0] | P */
    u16    offset_middle; /* 핸들러 주소 [31:16] */
    u32    offset_high;   /* 핸들러 주소 [63:32] */
    u32    reserved;      /* 반드시 0 */
} __attribute__((packed));

/* 인터럽트 게이트 설정 예 (arch/x86/kernel/idt.c) */
set_intr_gate(X86_TRAP_DE, asm_exc_divide_error); /* #DE: DPL=0, IF 클리어 */
SYSG(X86_TRAP_BP, asm_exc_int3),  /* early_idts[] 항목: #BP DPL=3 게이트는 SYSG 매크로 테이블로 설치 */

CPL/DPL/RPL 특권 레벨 메커니즘

x86은 4개의 특권 레벨(Ring 0~3)을 지원하며, 세그먼트 접근 시 CPU가 자동으로 세 가지 레벨을 비교합니다. 리눅스는 Ring 0(커널)과 Ring 3(사용자)만 사용하며, Ring 1/2는 활용하지 않습니다.

; Ring 3 → Ring 0 전환 시 CPU가 자동으로 수행하는 동작
; (예외/인터럽트 발생 시, CALL 게이트 사용 시)
;
; 1. CPL 변경 감지: 새 DPL < 현재 CPL → 스택 전환 수행
; 2. TSS.RSP0에서 Ring 0 커널 스택 포인터 로드
; 3. 현재 컨텍스트를 새 스택에 자동 푸시 (5개 항목):
;    [+40]: SS   (원래 Ring 3 스택 세그먼트)
;    [+32]: RSP  (원래 Ring 3 스택 포인터)
;    [+24]: RFLAGS
;    [+16]: CS   (원래 Ring 3 코드 세그먼트)
;    [ +8]: RIP  (원래 복귀 주소)
;    [  0]: Error Code (예외인 경우에만 푸시)
;
; 복귀: IRET → 저장된 SS/RSP/RFLAGS/CS/RIP 복원
;       CPL이 높아지면 자동으로 Ring 3 스택으로 복귀

SYSCALL/SYSRET 메커니즘 상세

현대 리눅스 커널은 시스템 콜에 INT 0x80/IRET 대신 SYSCALL/SYSRET 명령어를 사용합니다. 이 명령어들은 세그먼트 디스크립터 검사를 생략하고 MSR에서 직접 CS/SS 셀렉터와 진입점 주소를 읽어 Ring 3 ↔ Ring 0 전환을 수행합니다.

리눅스 커널의 syscall_init()에서 부팅 시 MSR을 설정합니다:

/* arch/x86/kernel/cpu/common.c — 단순화 발췌 */
void syscall_init(void)
{
    /* FRED 활성화 시 SYSCALL/SYSRET MSR 경로는 사용하지 않음 (#UD 발생) */
    if (!cpu_feature_enabled(X86_FEATURE_FRED))
        idt_syscall_init();
}

static inline void idt_syscall_init(void)
{
    /* STAR: [63:48]=SYSRET용 CS 기준(__USER32_CS), [47:32]=SYSCALL용 CS(__KERNEL_CS) */
    wrmsrl(MSR_STAR, ((u64)__USER32_CS) << 48 |
                     ((u64)__KERNEL_CS) << 32);

    /* LSTAR: 64비트 SYSCALL 진입점 */
    wrmsrl(MSR_LSTAR, (u64)entry_SYSCALL_64);

    /* CSTAR: 32비트 Compatibility Mode 진입점 (Intel CPU에서 직접 쓰기는 #UD이므로 wrmsrl_cstar() 경유) */
    wrmsrl_cstar((u64)(ia32_enabled() ? entry_SYSCALL_compat : entry_SYSCALL32_ignore));

    /* SFMASK: SYSCALL 진입 시 RFLAGS에서 클리어할 비트 (14개 플래그 전체) */
    wrmsrl(MSR_SYSCALL_MASK,
           X86_EFLAGS_CF|X86_EFLAGS_PF|X86_EFLAGS_AF|
           X86_EFLAGS_ZF|X86_EFLAGS_SF|X86_EFLAGS_TF|
           X86_EFLAGS_IF|X86_EFLAGS_DF|X86_EFLAGS_OF|
           X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_RF|
           X86_EFLAGS_AC|X86_EFLAGS_ID);
}

TSS (Task State Segment) 구조

Long Mode의 TSS는 하드웨어 멀티태스킹 지원 대신 스택 포인터 저장소로 사용됩니다. CPU는 예외/인터럽트 발생 시 TSS에서 스택 포인터를 가져옵니다. 리눅스는 CPU마다 하나의 TSS를 유지하며, 태스크 전환(context switch)마다 RSP0를 갱신합니다.

/* struct x86_hw_tss — arch/x86/include/asm/processor.h (단순화) */
struct x86_hw_tss {
    u32  reserved1;
    u64  sp0;          /* RSP0: Ring 0 진입 시 커널 스택 최상단 */
    u64  sp1;          /* RSP1: Ring 1 (리눅스 미사용, 항상 0) */
    u64  sp2;          /* RSP2: Ring 2 (리눅스 미사용 — SYSCALL 진입 시 사용자 RSP 임시 저장용 스크래치) */
    u64  reserved2;
    u64  ist[7];       /* IST1~7: NMI, #DF, #MC 등 전용 스택 포인터 */
    u32  reserved3;
    u32  reserved4;
    u16  reserved5;
    u16  io_bitmap_base; /* IOPB 오프셋 (0x68 = IOPB 없음) */
} __attribute__((packed));

/* RSP0 갱신 — arch/x86/kernel/process_64.c */
/* __switch_to() 호출 시마다 새 태스크의 커널 스택 최상단을 RSP0에 기록 */
/* this_cpu_write(cpu_tss_rw.x86_tss.sp0, task_top_of_stack(next_p)); */

Long Mode 특화 기능 상세

Long Mode는 단순히 64비트 레지스터와 넓은 주소 공간만 제공하는 것이 아닙니다. 캐노니컬(Canonical) 주소 규칙, REX 프리픽스, FS/GS Base MSR, RIP-relative 주소 지정 등 시스템 소프트웨어가 반드시 이해해야 할 고유 메커니즘을 포함합니다.

; arch/x86/entry/entry_64.S — 시스템 콜 진입 (Ring 3 → Ring 0, 단순화 발췌)
; SYSCALL 실행 후: GS.base = 사용자 GS 값 (그대로 유지됨)
; per-CPU 데이터 접근을 위해 SWAPGS로 커널 GS.base를 복원해야 함
SYM_CODE_START(entry_SYSCALL_64)
    swapgs                    ; GS.base ↔ KernelGS.base 교체 (진입 시 첫 번째 명령어)
    movq    %rsp, PER_CPU_VAR(cpu_tss_rw + TSS_sp2)  ; 사용자 RSP를 scratch 공간에 임시 저장
    ; ... 커널 스택 설정, pt_regs 저장 ...

; Ring 0 → Ring 3 복귀 (단순화 발췌 — 실제 코드는 POP_REGS·트램폴린 스택 전환·
; STACKLEAK_ERASE_NOCLOBBER·SWITCH_TO_USER_CR3_STACK 등을 먼저 수행)
SYM_CODE_START(syscall_return_via_sysret)
    ; ... 위 단계들 완료 후 ...
    swapgs                    ; sysretq 직전의 마지막 단계에서 사용자 GS.base 복원
    sysretq                   ; Ring 3 복귀 (RCX→RIP, R11→RFLAGS)

; RIP-relative 주소 지정 — PIE/KASLR 호환
; Long Mode에서 [rip + disp32] 형식으로 현재 명령어 기준 ±2GB 내 접근
; 어셈블러가 자동으로 다음 명령어 주소와의 차이를 계산
    lea     rax, [rip + my_symbol]    ; RIP-relative LEA: 심볼 주소를 위치 독립적으로 로드
    mov     rbx, [rip + global_var]   ; 전역 변수 접근: 재배치 없이 동작
; 컴파일러: -fPIC 또는 -fPIE 플래그 → 자동으로 RIP-relative 코드 생성
; 커널 KASLR: 임의 주소에 로드되어도 내부 참조는 상대 오프셋으로 유효

v6.12~v6.14 최신 변경사항 (Recent Kernel Changes)

커널 v6.12~v6.14(2024년 말~2025년 초)에서 아키텍처 관련 주요 변경사항을 정리합니다. 이 기간에는 PREEMPT_RT 완전 병합, sched_ext, 각 아키텍처의 하드웨어 보안 기능 확장 등 대규모 변경이 이루어졌습니다.

크로스 아키텍처 변경

PREEMPT_RT 완전 메인라인 병합, sched_ext BPF 스케줄러 도입 등 스케줄링 서브시스템의 오랜 숙제가 해결된 시기입니다. NUMA 메모리 코드 범용화처럼 특정 아키텍처에 묶여 있던 코드를 공통 계층으로 올리는 작업도 병행되었습니다.

x86_64 변경

Intel FRED(Flexible Return and Event Delivery)과 AMD Bus Lock Detect가 핵심 변경입니다. 인터럽트·예외 전달 경로를 현대화하고, 잠금(Lock) 경합(Contention)으로 인한 성능 저하를 하드웨어 수준에서 감지·제어하는 방향으로 발전하고 있습니다.