2022/07/02 8주차 스터디 내용

1.6.2 Barrier

ISB (Instruction Synchronization Barrier)

DMB (Data Memory Barrier)

DSB (Data Synchronization Barrier)

Q. DSB의 동작 차이를 정확히 이해하지 못함?

1.6.4 메모리 속성

cacheable과 shareable 메모리 속성

non-shareable

inner-shareable

outer-shareable

full system

1.7 멀티코어 프로세서

1.7.1 멀티프로세싱 시스템

SMP : Symmetric

AMP : Asymmetric

HMP : Heterogeneous

동기화 이슈

A64의 load/store exclusive(ldxr/stxr) 계열 인스트럭션 : shared memory의 non-block 동기화를 지원하는 동기화 primitive (normal/device memory 에 모두 사용 가능)

배타적 모니터

core 마다 local monitor, system에 하나 이상의 global monitor

1.7.2 캐시 일관성

Cluster 내의 core간 cache coherency 지원

system level에서 cluster간 coherency 지원은 AMBA ACE bus protocol을 구현한 CCI (Cache Coherent Interconnect)를 통해서 지원

snoop

1.7.3 클러스터 내의 멀티코어 캐시 일관성

MOESI 프로토콜

Modified : 수정

Owned : 소유

Exclusive : 독점

Shared : 공유

Invalid : 무효

1.7.4 버스 프로토콜과 캐시 일관성 인터커넥트

AMBA 4 ACE (AXI Coherency Extension)

1.8 전력 관리

1.8.1 유휴 상태 관리

context 저장 후 복구

Q. 스탠바이 모드나 리텐션 모드에서는 context 저장이 필요 없지 않을지요?

1.8.2 소비전류 관련 인스트럭션

Q. 비동기 abort는 어떤 경우에 해당하는지?

1.8.3 PSCI

PSCI (Power State Coordination Interface)는 core의 전원을 켜고 끌 때 사용하는 전력 관리 interface다. ACPI (Advanced Configuration and Power Interface)나 FDT (Flatten Device Tree) 같은 hardware 검색 기술과 함께 사용할 수 있도록 설계되었다.

Q. ARM에서도 ACPI의 PowerState, Processor State를 사용하나요?

ACPI 설명 : https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface

Programmer’s Guide for ARMv8-A

Chapter 1 Introduction

ARMv8 introduces the ability to perform execution with 64-bit wide registers, but provides mechanisms for backwards compatibility to enable existing ARMv7 software to be executed

AArch64 is the name used to describe the 64-bit execution state of the ARMv8 architecture. AArch32 describes the 32-bit execution state of the ARMv8 architecture, which is almost identical to ARMv7.

Chapter 2  ARMv8-A Architecture and Processors

ARMv9

https://namu.wiki/w/ARM%20Cortex-A%20%EC%8B%9C%EB%A6%AC%EC%A6%88#s-4

big : A710, A715

LITTLE : A510

ARMv9 내용은 찾아봐도 자세한 내용은 못찾고 부가적인 기능이 주를 이루는 것 같습니다.

찾을 수 있는 자료는 아래와 같습니다.

• Arm®️ Architecture Reference Manual Supplement Armv9, for Armv9-A architecture profile (ARM DDI

0608).

• Arm®️ Architecture Reference Manual Supplement, The Realm Management Extension (RME), for Armv9-A

(ARM DDI 0615).

• Arm®️ Architecture Reference Manual Supplement, The Scalable Matrix Extension (SME), for Armv9-A

(ARM DDI 0616).

ARM Architecture Reference Manual에 Chapter A3 Armv9 Architecture Extensions

ISA는 아래와 같습니다.

An Armv9.0 compliant implementation must also be Armv8.5 compliant.

An Armv9.1 compliant implementation must also be Armv8.6 and Armv9.0 compliant.

An Armv9.2 compliant implementation must also be Armv8.7 and Armv9.1 compliant.

An Armv9.3 compliant implementation must also be Armv8.8 and Armv9.2 compliant.

Linux LP64, Window LLP64

여기서 윈도우와 리눅스는 또 따로 논다. 윈도우는 int와 long이 모두 4바이트로 남고 long long 타입으로 64비트를 지원하는 LLP64 모델을 따른다. 이 말은 즉 32비트와 동일하다는 소리다. 윈도우에서는 long long 타입이 32비트 환경에서도 이미 지원이 되었고 많은 곳에서 long 타입이 그대로 사용되고 있으므로, 포인터를 제외한 int, long 타입이 32비트와 64비트에서 같은 크기를 가지는 이점이 있다. 반면, 리눅스/유닉스는 LP64 모델로 int만 32비트고 long은 64비트가 된다. 하나 골치 아픈 것은 size_t 이다. STL이나 많은 함수에서 크기를 나타낼 때 쓰는 형이다. size_t는 32비트 환경에서는 4바이트, 64비트 환경에서는 8바이트를 가진다. 윈도우와 리눅스 공히 그렇다.

리눅스 커널이 32비트에서 64비트로 발전해오면서 메모리 메니지 먼트 쪽은 64비트로 자료구조가 (제가아는한 ) 바뀌었는데

dma쪽 보면 자료구조중 일부 데이터 타입이 32비트로 표현된것이 여전히 코어에 남아 있습니다 그렇기 때문에 메모리 오프셋을 long에서 int로 넘길때 문제가 발생하는 코드들이 있고 이것들을 현재 드라이버들에서 int overflow가 발생하지 않게 구현이 되고 있는것들이 있어요

그래서 여전히 이런 타입에 대한 부분에 대한 명확한 숙지가 필요한거 같네요.

Chapter 3 Fundamentals of ARMv8

1.3.5 AArch64 익셉션 벡터 테이블

익셉션이 발생하면, 프로세서는 익셉션에 대응하는 약속된 위치의 핸들러 코드를 수행한다. 핸들 러가 저장된 메모리 영역을 익셉션 벡터라고 부른다. ARM 아키텍처에서 익셉션 벡터는 테이블 형태로 되어 있으며, 익셉션 벡터 테이블이라 부른다. EL0를 제외한 각 익셉션 레벨은 각각 벡터테이블을 갖고 있다.

EL2（하이퍼바이저）나 EL3（보안 모니터）를 구현한 시스템에서 동기 익셉션들은 현재 또는 상위 익셉 션 레벨에서 처리된다. 비동기 익셉션은 하이퍼바이저나 보안 커널이 다룰 수 있도록 상위 익셉션

레벨로 라우팅될 수 있다. SCR_EL3 레지스터는 EL3로 라우팅될 익셉션을 지정하고, 마찬가지로 SCR_EL2는 EL2로 라우팅될 익셉션을 지정한다. IRQ, FIQ 및 SError의 라우팅을 개별적으로 제 어할 수 있다.

Q. EL3에서 Exception이 발생하면 그럼 처리를 어디서 해주나요

매뉴얼을 좀더 읽어봤는데, 아까 FIQ, IRQ, SVC, ... 등등의 '모드'가 PL1에서 동작된다고 한 부분은, ARMv7에서는 일부 레지스터가 프로세서 모드에 따라서 같은 레지스터 번호에 대해서 모드에 따라서 물리적으로 다른 저장 공간을 사용할 수 있다고 되어있네요. (banked registers) 그래서 매뉴얼에서 FIQ, IRQ, ... 등등의 모드가 PL1에서 실행된다는 내용은 FIQ exception, IRQ exception이 특정 privilege level에서 처리된다는 의미가 아닙니다.

그래서 다른 분들께서 말씀하신 대로 ARMv7에서 예를 들어 FIQ, IRQ exception이 EL2에서도 처리가 될 수는 있지만 EL2에는 Hyp mode만 존재하기 때문에 FIQ, IRQ 등의 모드로는 처리할 수 없는 것 같습니다.

ARMv8에서는 ARMv7과 다르게 레지스터가 banked되지 않고 항상 모든 익셉션 레벨에서 같은 레지스터 번호가 같은 물리적인 저장 공간을 사용하고요.

아까 제가 질문한 내용은 이렇게 이해했습니다 :)

프로세서 모드가 무엇인지 제대로 이해하지 못해서 헷갈린 것 같아요

Q. 그런데 저는 이부분이 잘 이해가 안되더라구요

❑ Current Exception level with SP_EL1, SP_EL2, SP_EL3

"SP_ELx"는 각 익셉션 레벨 별로 지정한 스택 포인터 주소를 뜻합니다.

❑ Lower Exception level(AArch64)

AArch64 EL0가 동작 중에 발생한 exception

❑ Lower Exception level(AArch32)

AArch32 EL0가 동작 중에 발생한 exception

Q. A64 instruction set에서 명령어 하나의 크기는 그대로 32비트가 아닌가요?

The new A64 instruction set is similar to the existing A32 instruction set. Instructions are 32 bits wide and have similar syntax.

https://developer.arm.com/documentation/den0024/a/An-Introduction-to-the-ARMv8-Instruction-Sets/The-ARMv8-instruction-sets

https://developer.arm.com/documentation/ddi0596/2021-12/Index-by-Encoding

https://developer.arm.com/documentation/ddi0596/2021-12/Index-by-Encoding/Branches--Exception-Generating-and-System-instructions?lang=en#condbranch

Q. thumb으로 모드 변경할때는 bl or blx 인스트럭션 쓰는데

썸모드자체가 2~4byte의 비고정형 인스트럭션 사이즈를 가지고있는데 bl or blx로 인스트럭션 브랜치를 하면 4byte단위로 인스트럭션 디코딩을 하는것 같네요