커널 모듈에서 특정 CPU 확장을 구현하는 것과 관련된 정보를 찾고 있습니다. 나는 뭔가 관련이 있다는 것을 발견했다 : 실제로는 가까운 소스 코드 인 http://www.mirrors.docunext.com/lxr/http/source/arch/mips/kernel/unaligned.c이다.커널 모듈에서 CPU 확장 구현
기본적으로 특정 CPU 확장으로 빌드 된 이진 전용 공유 개체가 있습니다.이 공유 개체는 명령 집합이 대부분있는 약간 오래된 CPU에서 실행해야하지만 멋진 새 작업은 필요하지 않습니다. 그래, 나는 그것이 다소 느릴 것이라는 것을 안다. 그러나 그것은 SIGILLs로 부서지는 것보다 낫다.
음, 커널 소스를 읽은 후에, 이미 약간의 지원이있는 것처럼 보입니다. 얼마나 실제로 사용되는지는 알 수 없지만 다양한 에뮬레이트 된 명령어를 저장하는 링크 된 목록이 있습니다. 실제로이 작업을 수행 할 수 있다면 아마도 커널 헤더 제공 트리로 바꿀 것입니다.
커널 모듈을 올바르게 이해하고 있다면 플러그 식 에뮬레이션을 지원하는 데 문제가없는 것처럼 보입니다.
커널 모듈을 사용하여이 문제를 해결할 수 있다고 생각하지 않습니다. 나는 당신이 누락 된 지시 사항을 허용하는 VM에서 이것을 실행할 필요가 있다고 생각한다. (나는 XEN을 사용하려고 시도한다.) 사용하지 않는 객체를 재 컴파일한다.
@ joe는 FP 단위가없는 구형 프로세서에서 사용 된 구식 FP 에뮬레이션 트릭과 같은 것을 의미한다고 생각합니다. 아무도 지금이 연구를하고 있는지 모르겠습니다. –
외부 FP 장치는 실제로 더 큰 그림의 두 번째 부분입니다. 그러나 내가 그것에 올 때 나는 그것을 망칠 것이다. 다음은 x86 예제입니다 (타겟 CPU는 ARM 임). CPU가 SSE2를 지원하지 않으면 ADDPD 명령어를 만나면 커널이 내부 SIGILL을 던져 버릴 것입니다. (커널 모듈 등)에 의해 캐치되어 ADDPD를 구현 한 특정 기능을 호출하게됩니다. 반드시 커널 모듈 일 필요는 없습니다. 커널 프레임 워크를 작성해야 할 수도 있습니다. 이는 괜찮습니다. – joe
나는 이것을 userland에서 할 수 있다고 생각합니다. SIGILL에 대한 처리기를 sigaction()으로 설치하고 SA_SIGINFO을 지정하십시오. 의 si_code 필드는 SIGILL의 여러 원인을 구별합니다. 예를 들어, 신호가 kill()에서 왔을 때 명령어를 에뮬레이트하려는 것은 의미가 없습니다. 핸들러에 대한 세 번째 인수는 오류 발생시 CPU 컨텍스트를 포함하는 구조를 가리 킵니다 (문서 참조). 당신은 이것을 수정하고 시그널 핸들러에서 리턴 할 수 있으며, 변경 사항이 적용됩니다. 그래도 문제가 해결되지 않으면 setcontext()을 시도하십시오.
분명히 커널에서 수행하는 것보다 덜 효율적이지만 더 깨끗하고 안전합니다.
이렇게 할 수 있지만 약간 힘듭니다. 잘못된 opcode는 가로 챌 필요가 있으므로 기존의 잘못된 명령어 핸들러를 수정하거나 핸들러를 래핑해야합니다.이 핸들러는 더럽고 복잡합니다.
커널 개조를 피하고 순수한 커널로 사용하려면 wrapped-exception 접근 방식이이를 수행하는 유일한 방법 일 수 있습니다. 커널을 수정할 수 있다면 패치 처리기가 더 좋습니다.
링크가 끊어졌습니다 ... – luke
Shazbot! 고마워. – joe
귀하의 질문이 조금 지나치게 길 수도 있다고 생각합니다. 당신은 이미 기본적인 아이디어를 가지고 있습니다 - 결국 SIGILL을 초래하는 함정을 가로 채서 대신에 사용자 프로세스 상태를 검사하고 실행하려고했던 명령을 에뮬레이트하십시오. (모듈에서 할 수는 없을 것이라고 생각합니다. 모듈에 shims를 추가하지 않으면 컴파일해야 할 것입니다). 그래서 진짜 질문은 무엇입니까? – caf