인터럽트 처리 순서

아래 문의 주신 질문에 답변드립니다: Big picture에서 보이는 GIC는 주변 장치에서 발생한 인터럽트를 수신하여 처리하는 하드웨어 유닛(IP)입니다. 콜 스택에 나타난 gic 관련 핸들러 함수는 Arm 프로세서가 GIC의 CPU 인터페이스로부터 인터럽트를 성공적으로 수신하여 처리하고 있다는 확인(Acknowledgement) 작업을 수행합니다. 익셉션 핸들러 다음에 GIC가 처리되는 것은 아닙니다. 추가로 궁금하신 점이 있으면 문의주세요. 감사합니다.

preemption 체크 관련 질문

확인 방법이 다른 이유는 인터럽트가 유발된 후 유저 공간으로 복귀하는 프로세스와 커널 공간에서 실행되는 프로세스의 Preemption을 다른 방식으로, 유연하게 처리하기 위해서입니다. 리눅스 커널에서는 기본적으로 CFS 스케줄러에 의해 프로세스의 실행 시간이 관리되는데, 프로세스에게 일정 시간 실행될 수 있는 timeslice를 제공합니다. timeslice를 프로세스가 다 소진했을 때는 preemption될 대상이 되며, 아래와 같이 설정됩니다. 유저 프로세스인 경우 flags를 TIF NEED_RESCHED 로 설정 커널 공간에서 실행되는 프로세스인 경우 preempt_count를 0으로 설정 감사합니다.

Exception Level 설정 관련 질문

질문 주신 내용에 대해 답신드립니다: 1. 어셈블리 명령어를 실행해서 익셉션 레벨을 변경할 수는 있습니다. 예를 들어 EL2에서 EL1, 혹은 EL1 에서 EL0으로 낮은 익셉션 레벨로 변경할 수 있습니다. 2. 어셈블리 명령어를 실행해서(예시: SVC) 더 높은 익셉션 레벨로 진입할 수는 없습니다. 3. 부팅한 다음에 확인되는 익셉션 레벨은 EL3이며, 칩셋 레벨에서 하드웨어적으로 설정됩니다. 혹시 '시스템 소프트웨어 개발을 위한 Arm 아키텍처의 구조와 원리 - 1부 저자 직강 (2024년 버전)'을 수강하셨다면, 아래 섹션에서 관련 내용을 확인하실 수 있습니다: -> 섹션 12. [보충] 6.익셉션 레벨: 부팅과정에서 설정되는 익셉션 레벨 https://inf.run/7jyaB 감사합니다.

Current EL 관련 질문

Current Exception level을 직역해서 해석하면 현재 익셉션 레벨입니다. 익셉션 벡터 테이블을 해석할 때는 Current Exception level는 익셉션을 핸들링하는 익셉션 벡터 (혹은 익셉션 핸들러)가 존재하는 익셉션 레벨로 해석하시면 됩니다. 예를 드신 내용으로 설명드리면요: User App이 실행 중 Exception이 발생했다면, User App이 실행되는 EL0에서 EL1으로 익셉션이 스위칭됩니다. 즉, EL1에 존재하는 VBAR_EL1에서 해당 익셉션(User App이 실행 중 Exception이 발생)을 처리하는데요, 다음과 같이 해석하시면 됩니다. Current Exception level = EL1 Lower Exception Level = EL0 따라서 'Lower Exception Level'에 표기된 오프셋을 기준으로 익셉션 벡터 주소로 분기됩니다. 추가로 궁금하신 점이 있으면 질문해주세요. 감사합니다.

T32에 관련해서

질문 주신 내용에 대해 답신 드립니다: 1. 강의에서 제공하는 T32 프로그램을 따로 만들어서 진행 부탁드립니다. 실습을 진행하실 때는: 되도록 기존에 (회사에서) 사용하시던 T32 폴더는 T32_back으로 변경하고, 인프런 강의에서 제공하는 TRACE32프로그램을 C:\T32 폴더에 위치시켜서 실습을 진행하시길 권장드립니다. 프로그램 간에 충돌이 일어날 수 있어 이렇게 권장 드립니다. 2. (인프런에 올린 TRACE32 프로그램은) 맥북에서 실행되지는 않습니다. 이점 양해 부탁드립니다. 감사합니다.