Linux 6.18 계열 · x86 INIT/SIPI는 전통적인 AP 시작 경로 예

CPU를 시작시키는 요청과 IPI는 무엇이 다릅니까?

ARM·RISC-V·x86에서 CPU 시작 주소를 전달하는 방법과, 실행 중인 CPU에 일을 알리는 방법을 비교합니다.

“CPU를 깨운다”는 말부터 나눕니다

상태필요한 동작확인할 결과
커널에 아직 참여하지 않은 보조 CPU펌웨어·아키텍처별 시작 경로, stack·MMU·per-CPU 초기화해당 CPU의 Linux 초기화와 online 완료
온라인이지만 idle인 CPU타이머·장치 interrupt·IPI 등으로 대기에서 빠져나옵니다.idle 복귀와 필요한 작업 처리
특정 프로세스가 wait queue에서 잠듦조건 변경 후 task를 실행 가능 상태로 만듭니다.scheduler가 선택했을 때 task 실행 재개
시스템 suspend로 깊게 정지함wake source와 플랫폼 복구 경로보존되지 않은 CPU·장치 상태 복원

wait queue의 wake_up()은 CPU의 reset 핀을 직접 조작하는 함수가 아닙니다. runnable task가 생긴 뒤 scheduler가 필요에 따라 다른 CPU에 알릴 수 있지만, task 상태 변경과 하드웨어 CPU 시작은 구분해야 합니다.

시작 주소를 누가 받는지 비교합니다

아키텍처의 대표 경로식별자시작 주소 전달대상 CPU가 준비할 것
ARM64 PSCI CPU_ONMPIDR affinity로 나타낸 대상SMC/HVC 요청의 entry point 인자펌웨어의 CPU 상태 처리 뒤 secondary_entry의 커널 초기화
RISC-V SBI HSMhart IDhart_start의 start_addrsecondary_start_sbi에서 task·stack·MMU·trap 설정
x86 INIT/SIPIAPIC IDSIPI vector가 낮은 물리 메모리의 시작 페이지를 나타냅니다.trampoline을 거쳐 모드·stack·커널 진입 상태 준비

이 표는 대표적인 비교입니다. 모든 ARM 장치가 PSCI를 사용하거나 모든 x86 환경이 같은 INIT/SIPI 경로를 사용한다는 뜻은 아닙니다. 플랫폼·가상화·펌웨어 규약에 따른 다른 시작 방법이 있습니다. 실제 보드의 CPU operation을 먼저 확인해야 합니다. ARM64 부팅 조건 RISC-V HSM

x86 SIPI의 vector는 일반 interrupt vector와 다릅니다

전통적인 x86 AP 시작 과정에서 INIT는 대상 AP를 초기 상태로 만들고, SIPI는 시작할 페이지를 알려 줍니다. SIPI의 8비트 vector는 시작 물리 주소의 상위 부분으로 사용되어 vector × 4096 위치를 가리킵니다. 예를 들어 vector가 0x08이면 시작 위치는 0x8000입니다. 일반 interrupt의 IDT 항목 8을 선택한다는 뜻이 아닙니다.

전통적인 INIT/SIPI 기반 시작의 개념
  1. BSP가 trampoline을 준비합니다

    낮은 물리 주소에 AP가 실행할 초기 코드와 필요한 자료를 준비합니다.

    INIT와 SIPI 요청을 보냅니다.

  2. AP가 trampoline에서 시작합니다

    초기 실행 모드에서 필요한 주소·descriptor·페이지 테이블 등을 갖춥니다.

    해당 커널 진입 경로로 이동합니다.

  3. AP의 Linux 초기화

    CPU별 상태, interrupt 관련 상태와 scheduler 참여를 준비합니다.

    시작을 요청한 쪽과 준비 완료를 맞춥니다.

  4. 온라인 CPU

    이후의 reschedule·TLB shootdown 등에서는 목적에 맞는 IPI를 처리합니다.

화살표는 시작 과정의 진행입니다. SIPI 하나에 모든 Linux CPU 초기화가 포함된다는 뜻은 아닙니다. 실제 횟수·대기·동기화는 CPU와 커널 구현을 따릅니다.

Intel SDM의 multiprocessor initialization Linux x86 AP 시작 구현

실패 지점을 로그로 나눕니다

관찰 지점질문
요청 전논리 CPU 번호를 실제 MPIDR·hart ID·APIC ID로 올바르게 바꿨습니까?
요청 처리펌웨어 또는 interrupt controller가 요청을 받았습니까? 오류·timeout은 어디에서 발생했습니까?
첫 명령대상 CPU가 지정한 물리 주소에 도착합니까? 해당 메모리에 코드가 있고 실행 가능한 상태입니까?
초기 stack·MMU새 CPU가 읽는 포인터와 페이지 테이블이 준비됐습니까? cache와 순서는 맞습니까?
Linux 참여CPU별 초기화 뒤 online 완료 신호까지 도착합니까?

주소가 실행 중에 정해지면 임의의 숫자를 “정답”으로 적기보다, 어디에서 계산되고 어느 CPU가 소비하는 값인지 기록합니다. 같은 함수의 CPU A 로그와 CPU B 로그도 CPU 번호와 시점을 붙여 구분해야 합니다.