2023.10.14 (23주차) - 약 10명 참여

head.S : init_kernel_el 완료, __cpu_setup의 reset_amuserenr_el0 x1 까지 진행.

init_el1에서 SPSR에 대한 설명  -> Arm 아키텍처의 구조와 원리 pg 49

공유) BOOT_CPU_MODE_EL1 값 = 0xe11

Q: 보통 return 할 때와 달리 elr_el1에 lr 값을 넣어준 후 eret을 사용하는 이유는 무엇인가요?

A1: 레벨에 맞는 ELR 및 SPSR 사용
  (레벨에 맞는 SPSR 값을 논리적 개념인 pstate로 업데이트)

A2: https://github.com/gregkh/linux/commit/d87a8e65b5101123a24cddeb7a8a2c7b45f7b60c

A3:

Q: init_pstate_el1의 값은 PSTATE.DAIF mask and el1_h 값을 set 하는데, 그러면 굳이 INIT_PSTATE_EL1 값을 설정해서 넣어야하는가? 다른 명령어를 사용해서 넣을 수 있지 않나?

A: Init_pstate_el1 -> DAIF 및 익셉션레벨 이외의 비트 값은 0으로 하는 의도도 있다.

__hyp_stub_vectors 

책 pg287

Q: ventry에서 align 7을 하는 이유

A: 익셉션 벡터 테이블에서 익셉션 종류에 따라서 offset이 0x80만큼 차이가 나기 때문이다. 0x80 = 0b1000_0000; 즉 하위 7비트를 align 하는 것 

Q: EL1에서 DAIF mask하는 이유

A: 인터럽트 벡터 테이블이 세팅되어 있지 않아서 인터럽트가 발생하면 시스템이 오작동할 것이다. (벡터 베이스 레지스터에 값을 넣지 않았다는 의미) 따라서 mask 해준다. 

Q: __hyp_stub_vectors 여기서 벡터 테이블을 한 개만 사용하지 않아서 stub을 붙여줬는데, 같이 보고 넘어갔으면 좋겠다.

A1: http://jake.dothome.co.kr/arm64-vector/ (el2 벡터 부분)

A2: http://jake.dothome.co.kr/hyp_mode_check/ (하단부 To EL2, and beyond! pdf 파일)

A3: https://www.youtube.com/watch?v=j0bp4fnO98w&ab_channel=KVMForum (위 pdf에 해당하는 영상)

A4: https://selfish-developer.com/entry/KVM-ARM (KVM 만들 때의 의사결정 과정)

cf) 모바일에서는 안드로이드 또는 ios 한 개의 OS만 올라가는데, 가상화를 위해서가 아니라 별도의 추가 기능을 위해서 하이퍼바이저를 사용하기도 한다. 

https://docs.samsungknox.com/admin/fundamentals/whitepaper/core-platform-security/real-time-kernel-protection/

Q: VHE redirecting register access

A1:

A2: VHE를 사용할 때는 EL1 레지스터에 접근을 한다면 EL2로 redirection 해준다. 이 때, 레지스터의 이름은 EL12로 사용한다.

Q: EL1에서 인터럽트를 비활성화한 것 처럼 EL2에서도 해줘야하지 않을까요? stub vector만 구성되어 있기 때문입니다.

A: init_el2_state의 __init_el2_nvhe_prepare_eret 매크로에 있습니다. 

(/arch/arm64/include/asm/el2_setup.h)

Q: x0에 HCR_HOST_NVHE_FLAGS를 저장한 후에 이 값을 hcr_el2에 쓴다. 좀 아래에 내려가보면, hcr_el2 값을 읽어서 HCR_E2H 비트를 검사하는데, 그렇다면 무조건 NVHE이지 않을까요?

A1: 주석을 보면 Fruity CPU는 HCR_EL2.E2H 값이 1로 고정되어있어서, nVHE mode로 부팅하는 것이 불가능하다고 합니다. 따라서 이 경우를 위해 처리해주는 것 같습니다.

A2: A1의 경우에 더해지는 플래그인 BOOT_CPU_FLAG_E2H의 주석을 보면 boot mode와 함께 리턴되지만, __boot_cpu_mode에 값이 보존되지는 않고 idreg override 코드에서 boot state를 수행하는 데 사용된다고 합니다.

Q: __hyp_stub_vectors를 보면 elx_sync만 처리하게끔 되어있다. 이유는 무엇인가요?

A:

nVHE에서는 위와 같은 플로우로 처리되기 때문이다. __hyp_stub_vectors는 위 그림에서 KVM lowvisor에 해당하고, 여기에 들어갈 때는 모두 HVC를 통해서 들어간다. elx_sync 코드를 보면, 여러 인자들을 받아 분기를 다르게 하는데, 이것이 EL1의 vector로 이동하는 코드가 아닐까 싶다.

Q: SYS_ID_AA64MMFR2_EL1의 값 중 0xff << ID_AA64MMFR2_EL1_VARange_SHIFT를 tst하는 의미에 대해서 이야기해보면 좋을 것 같습니다.

A1: 0b0000 VMSAv8-64 supports 48-bit VAs.

0b0001 VMSAv8-64 supports 52-bit VAs when using the 64KB translation granule. 

The size for other translation granules is not defined by this field.

A2: VA_BITS가 52일 때, 그것을 지원하는지 안하는지 확인해서 x0에 VA_BITS 또는 VA_BITS_MIN을 쓴다.

Q: FP / ASIMD을 Enable 하는 것에 대해 이야기해보면 좋을 것 같습니다.

A: __cpu_setup은 MMU를 켜기 전에 CPU를 설정해주는 것이다. (하드웨어 설정) 

FP (Floating Point), ASIMD (Arm Single Instruction Multiple Data) .. 

FP / ASIMD 관련 명령어를 실행했을 때, 커널로 trap되지 않고 하드웨어적으로 처리되게한다.

http://jake.dothome.co.kr/kboard/?uid=114&mod=document

Q: mdscr_el1에 1 << 12값을 쓰는 것의 의미는 무엇인가요?

A: 주석을 보면 알 수 있다. mdscr_el1을 리셋하고, EL0에서 DCC(Debug Communication Channel)에 접근하면 트랩을 발생시킨다. 즉, EL0에서 디버그를 할 수 없도록 한다.