반응형

A. 환경 정보

  • Host: Windows 10 (version: 21H2, build: 19044.1766)
  • Guest: Ubuntu 20.04 (WSL version2)
  • GPU: NVIDIA GeForce GTX 1050

B. 환경 구축하기

1. WSL 버전 확인

  • cmd.exe에서 아래 명령어 입력하기
  • wsl --list -v
  • 실행결과
  • C:\ >wsl --list -v NAME STATE VERSION * Ubuntu-20.04 Running 2
  • WSL 버전이 1일 경우, 해당 사이트를 참고하여 Update 를 해주세요.

2. WSL 에 적합한 Windows vGPU Driver 설치하기

  • 참고
    • 가상 GPU 를 사용하려면 특정의 드라이버가 필요합니다.
    • 따라서 시스템 드라이버가 최신인 경우라도 반드시 설치하여야 합니다.
  • 그래픽 카드의 제조사를 확인한 후 설치 필요
  • 각 환경에 맞는 드라이버 다운로드 및 설치 완료

3. WSL2 환경인 Ubuntu에 NVIDIA CUDA 설치하기

  • 참고
    • Ubuntu 저장소에서 직접 CUDA 툴킷 패키지를 설치하기 위해 Linux NVIDIA Graphics Driver를 설치할 경우, WSL에서는 작동되지 않습니다.
  • CUDA toolkit 설치 (require version >= 10)
    sudo apt-key del 7fa2af80  
    wget [https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86\_64/cuda-wsl-ubuntu.pin](https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-wsl-ubuntu.pin) sudo apt-key adv --fetch-keys [https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86\_64/3bf863cc.pub](https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/3bf863cc.pub)  
    sudo add-apt-repository “deb [https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86\_64/](https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/) /”  
    sudo apt update sudo apt -y install cuda

4. Sample Code 컴파일

  • 샘플 코드는 NVIDIA에서 제공하고 있으며, 해당 링크에서 다운받을 수 있다.
  • 테스트 폴더 생성
    • mkdir vgpu
  • 샘플 코드 clone
    • git clone https://github.com/nvidia/cuda-samples
  • 컴파일 할 Sample Code 디렉터리로 이동
    • blackcon@DESKTOP-QQQ9POJ:~/vgpu$ cd cuda-samples/Samples/1_Utilities/deviceQuery
  • 샘플 디렉터리 파일 목록
    blackcon@DESKTOP-QQQ9POJ:~/vgpu/cuda-samples/Samples/1_Utilities/deviceQuery$ ls   
    Makefile README.md deviceQuery_vs2017.sln deviceQuery_vs2019.sln deviceQuery_vs2022.sln NsightEclipse.xml deviceQuery.cpp deviceQuery_vs2017.vcxproj deviceQuery_vs2019.vcxproj deviceQuery_vs2022.vcxproj
  • make를 사용하여 컴파일 실행
blackcon@DESKTOP-QQQ9POJ:~/vgpu/cuda-samples/Samples/1_Utilities/deviceQuery$ make 
/usr/local/cuda/bin/nvcc -ccbin g++ -I../../../Common -m64 --threads 0 --std=c++11 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_61,code=sm_61 -gencode arch=compute_70,code=sm_70 -gencode arch=compute_75,code=sm_75 -gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86 -gencode arch=compute_86,code=compute_86 -o deviceQuery.o -c deviceQuery.cpp 
nvcc warning : The 'compute_35', 'compute_37', 'sm_35', and 'sm_37' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). 
/usr/local/cuda/bin/nvcc -ccbin g++ -m64 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_60,code=sm_60 -gencode arch=compute_61,code=sm_61 -gencode arch=compute_70,code=sm_70 -gencode arch=compute_75,code=sm_75 -gencode arch=compute_80,code=sm_80 -gencode arch=compute_86,code=sm_86 -gencode arch=compute_86,code=compute_86 -o deviceQuery deviceQuery.o nvcc warning : The 'compute_35', 'compute_37', 'sm_35', and 'sm_37' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). 
mkdir -p ../../../bin/x86_64/linux/release cp deviceQuery ../../../bin/x86_64/linux/release

5. Sample Code 실행 결과

마치며

  • 해당 포스팅을 통하여 Windows의 WSL2 환경에서 GPU를 이용한 개발을 할 수 있도록 셋팅을 하였습니다.
  • 이 기술은 머신러닝에 사용될 수 있을 것이며, Windows 11 이후 버전에서는 WSL2를 GUI로 출력시킬 수 있다고 하니 해당 기능에 활용 될 수 있을 듯 합니다.
  • 저는 이 설치를 통하여 WSL2에서 gpu에 접근할 경우, 어떤 flow로 작업되며 최종적으로는 HOST에 어떠한 영향이 일어나는지 분석을 해보고자 합니다.
  • 가능하다면 향 후 포스팅에서 소개드릴 수 있도록 해볼게요.

Reference

반응형

참고 : 아래 글은 Micro Soft의 블로그에 작성된 포스트를 한글로 작성한 글입니다.

WSL(Windows Subsystem Linux)로 출시된 DirectX

  • Microsoft는 GPU 하드웨어 가속화가 Linux 2용 Windows Subsystem(WSL 2)으로 온다고 발표했다. (build 2020)
  • WSL 이란?WSL은 사용자가 Windows PC에서 Linux 애플리케이션을 실행할 수 있는 환경이다.
  • 이러한 리눅스 애플리케이션과 도구는 이제 GPU 가속화의 혜택을 받을 수 있다.

GPU 가상화

소개

  • "WDDM GPU 반가성화" 또는 "GPU-PV" 란, WDDM (Windows Display Driver Model) 에 통합되며 모든 WDDMv2.5 이상 드라이버는 GPU 가상화를 기본적으로 지원하는 기술을 말한다.
  • GPU-PV는 이제 Windows의 기본 부분이며 Windows Defender Application Guard, Windows Sandbox 또는 Hololens 2 에뮬레이터와 같은 시나리오에서 사용된다.
  • 오늘날 이 기술은 VM 또는 컨테이너 내부 (Windows guest)에서 실행되는 Windows로 제한된다.

지원범위

  • WSL 2에 GPU 가속화를 지원하기 위해 WDDMv2.9는 GPU-PV의 범위를 Linux 게스트로 확대한다.
  • 이는 GPU-PV 프로토콜을 활용하여 사용자 모드 Linux에 GPU를 노출시키는 새로운 Linux 커널 드라이버를 통해 달성된다.
  • GPU의 예상 추상화는 WDDM GPU 추상화 모델을 근접하게 따르며, 그 추상화에 대비하여 제작된 API와 드라이버는 Linux 환경에서 사용하기 위해 쉽게 포팅될 수 있다.

Linux 용 dxgkrnl 소개

소개

  • Dxgkrnl은 /dev/dxg 장치를 사용자 모드 Linux에 노출시키는 Linux용 새로운 커널 드라이버이다.
  • /dev/dxg는 Windows에서 기본 WDDM D3DKMT 커널 서비스 레이어를 밀접하게 모방하는 IOCTL 세트를 노출한다.
  • Linux 커널 내부의 Dxgkrnl은 VM 버스를 통해 윈도우즈 호스트의 빅 브라더에 연결하고 이 VM 버스 연결을 사용하여 물리적 GPU와 통신한다.

dxgkrnl 구조

dxgkrnl 구조


출처: https://devblogs.microsoft.com/directx/directx-heart-linux/

GPU 접근 권한

  • 호스트에 여러 개의 GPU가 있는 경우 모든 GPU가 투영되어 Linux 환경에 사용할 수 있다(가정: 이 모든 GPU가 WDDMv2.9 드라이버를 실행하고 있어야함)
  • 리눅스 환경 내에서 실행되는 애플리케이션은 윈도우즈에서 기본 애플리케이션과 동일한 GPU에 액세스할 수 있다.
  • Linux와 Windows 사이에 리소스 파티셔닝이나 Linux 애플리케이션에 부과되는 제한은 없다.
  • 공유는 누가 무엇을 필요로 하는가에 따라 완전히 동적이다.
  • 기본적으로 GPU를 공유하는 두 Windows 애플리케이션과 동일한 GPU를 공유하는 Linux 및 Windows 애플리케이션 간에는 차이가 없습니다.
  • Linux 애플리케이션이 GPU에 단독으로 있다면, 모든 리소스를 사용할 수 있다!

/dev/dxg 셋팅

  • Windows 호스트에 올바른 GPU 드라이버가 설치되어 있다고 가정하면 /dev/dxg는 추가 패키지를 설치할 필요 없이 설치된 모든 WSL 배포판에서 자동으로 노출되고 사용할 수 있다.
  • GPU에 액세스하려면 배포판이 WSL 버전 2 모드(wsl –set-version 2)에서 실행되어야 합니다.

오픈소스


👇 정리되지 않은 내용들 👇


DxCore & D3D12 on Linux

리눅스 내부의 GPU에 대해 WDDM 호환 추상화를 투영함으로써 WSL에서 실행될 때 우리는 다시 컴파일하여 리눅스 에서 초기의 그래픽 API를 가져올 수 있었다.

이것은 실제와 완전한 D3D12 API, 모조품, 프리텐더 또는 재구성이 아닌 실제 D3D12 API 입니다.libd3d12.so은 Windows에서 d3d12.properties와 동일한 소스 코드에서 컴파일되지만 Linux 대상에서는 컴파일된다.동일한 수준의 기능과 성능(가상화 오버헤드 최소화)을 제공한다.유일한 예외는 존재()이다.현재 WSL은 콘솔 전용 경험이기 때문에 WSL과의 프레젠테이션 통합은 없다.D3D12 API는 오프스크린 렌더링 및 컴퓨팅에 사용할 수 있지만 픽셀을 화면에 직접 복사하는 스왑체인(Yet 😊) 지원은 없다.

DxCore(libdxCore).따라서)는 API의 기존 측면이 현대 버전으로 대체된 dxgi의 단순화된 버전이다.DxCore는 Windows와 Linux 모두에서 사용할 수 있다.DxCore는 Windows 기반 WDDM 드라이버가 GPU와 대화하기 위해 사용하는 D3DKMT API의 플랫 버전을 호스팅하는 데도 사용된다. 이 API는 다양한 WDDM 서비스가 커널로 이동하는 방법의 차이를 추상화한다(Windows의 서비스 테이블과 Linux의 서비스 테이블).

libd3d12.so과 libdxcore.so은 Windows의 일부로 제공되는 폐쇄 소스, 사전 예약 사용자 모드 이진 파일이다.이러한 이진 파일은 glibc 기반 디스트로와 호환되며 /usr/lib/wsl/lib 아래에 자동으로 탑재되어 로더가 볼 수 있게 한다.즉, 이러한 API는 별도의 패키지를 설치하거나 디스트로의 구성을 변경할 필요 없이 즉시 사용할 수 있다.지원은 현재 Ubuntu, Debian, Fedora, Centos, SUSE 등과 같은 glibc 기반 디스트로로 제한되어 있다.

D3D12는 GPU 제조업체 파트너가 제공하는 GPU 특정 사용자 모드 드라이버(UMD)가 없으면 작동이 불가능할 것이다.UMD는 쉐이더를 하드웨어 특정 바이트 코드로 컴파일하고 API 렌더링 요청을 GPU가 실행할 명령 버퍼의 실제 GPU 명령으로 변환하는 등의 업무를 담당한다. 파트너와 긴밀하게 협력하면서 D3D12 UMD를 Linux 대상으로 재구성하여 WSL 환경에서 이러한 드라이버를 실행할 수 있도록 한다.이 지원은 WSL의 GPU 지원이 최종 사용자에게 원활하도록 다가오는 WDDMv2.9 드라이버에 통합되고 있다.WDDMv2.9 드라이버에는 Linux용으로 컴파일된 DX12 UMD 버전이 탑재된다.호스트 드라이버 패키지는 /usr/lib/wsl/drivers에서 WSL 내부에 탑재되며 d3d12 API에서 직접 액세스할 수 있다.WDDMv2.9 드라이버가 있는 경우 GPU는 마법처럼 WSL로 표시되고 완전히 사용할 수 있게 된다.

DirectML 및 AI 교육

D3D12와 DxCore 외에도 WSL에서 실행될 때 Linux에서 작동하도록 기계학습 API, DirectML을 포팅했다.우리는 다이렉트를 가져왔다.ML의 회의 수행 기계 학습 기능을 Linux로 확장하고 교육 워크플로우 지원으로 기능 확장!DirectML은 D3D12 API의 맨 위에 위치하며 머신러닝 워크로드에 대한 컴퓨팅 작업 및 최적화 모음입니다.

DirectML 팀은 회의 및 교육에서 가속화된 이러한 하드웨어를 인기 있는 ML 도구, 라이브러리 및 프레임워크와 통합하는 목표를 가지고 있다.DirectML로 교육 워크플로우를 지원함에 있어, 초기에는 학생과 초보자의 ML 워크플로우에 초점을 맞추고 있다.우리는 대학생과 산업 내 엔지니어들이 광범위한 Windows 하드웨어를 활용하여 학습하고 새로운 ML 기술을 습득할 수 있도록 하고 싶다.DirectML 활용은 WSL 2 내에서 실행되는 Linux 기반 ML 도구에서 DirectX 12 지원 GPU를 두드림으로써 학생과 초보자가 기존 시스템에서 하드웨어 가속을 활용할 수 있는 간단한 경로를 제공한다.

다이렉트 확장에 투자한 만큼ML의 기능, 실리콘 파트너와의 놀라운 공동 엔지니어링은 이러한 ML 중심 투자로부터 Windows 에코시스템에서 다양한 GPU가 혜택을 받도록 하는 데 필수적이다.이번 여름부터 DirectML과의 교육이 시사회장에 들어간다고 발표하게 되어 설레는 이유다!

고객이 DirectML로 교육을 더욱 쉽게 시작할 수 있도록 DirectML 백엔드를 통합한 텐서플로우 미리보기 패키지를 출시하고 있다.학생들과 초보자들은 텐서플로우 튜토리얼로 시작할 수 있고 그들의 미래를 위한 기반을 구축할 수 있을 것이다.게다가, 우리는 텐서플로우 커뮤니티와 함께 RFC 과정을 거치고 있어!미리보기가 공개되면, 우리는 계속해서 투자를 할 것이며 DirectML에 새로운 기능을 추가하는 것은 물론 텐서플로우의 엔드투엔드 교육 능력을 지속적으로 향상시켜 여러분의 교육 워크플로우를 더욱 향상시킬 것이다.

실습 교육을 위해 DirectML 하드웨어 가속화를 살짝 사용하려는 경우 //build 스킬링 세션(Windows AI: hardware-accelerated ML on Windows devices)에서 확인하십시오.

OpenGL, OpenCL & Vulkan

Linux에서 사용자들은 그래픽에 크로노스 API를 사용한다.그렇다면 OpenGL, OpenCL 또는 Vulkan의 GPU 가속화에 대한 지원은 어떠한가?
우리는 최근 DX12 위에 OpenCL과 OpenGL의 하드웨어 가속화를 가져올 계층 매핑 작업을 발표했다.우리는 Mesa 라이브러리를 통해 하드웨어 가속 OpenGL과 OpenCL을 WSL에 제공하기 위해 이 레이어를 사용할 것이다.우리의 작업이 끝난 후에, WSL distro는 이 가속을 밝히기 위해 메사를 업데이트해야 할 것이다.이 Mesa 업데이트를 픽업하는 디스트로의 경우 WDDMv2.9 드라이버 이상이 Windows 호스트에 설치될 때마다 가속이 자동으로 활성화된다.

벌칸은?우리는 여전히 WSL에서 벌칸을 가장 잘 지원하는 방법을 모색하고 있으며 앞으로 더 많은 세부사항을 공유할 것이다.게다가 모든 계획을 한꺼번에 밝힐 수는 없다.

NVIDIA CUDA

오늘날 가장 인기 있는 컴퓨팅 API는 어떤가?

우리는 NVIDIA CUDA 가속도 WSL에 온다는 것을 알리게 되어 기쁘다! CUDA는 크로스 플랫폼 API로 Windows에서 WDDM GPU 추상화 또는 Linux에서 NVIDIA GPU 추상화를 통해 GPU와 통신할 수 있다.

NVIDIA와 협력하여 /dev/dxg에 의해 노출되는 WDDM 추상화를 직접 대상으로 하는 리눅스용 CUDA 버전을 구축했다.이것은 완전히 기능적인 버전의 libcuda이다.따라서 CUDN, CubBLAS, Tensor와 같은 CUDA-X 라이브러리의 가속화가 가능해진다.RT

WSL에서의 CUDA 지원은 NVIDIA의 WDDMv2.9 드라이버에 포함될 것이다.D3D12 지원과 마찬가지로, CUDA API에 대한 지원은 NVIDIA GPU가 있으면 glibc 기반 WSL distro에서 자동으로 설치되고 사용할 수 있다. libcuda.so 라이브러리는 libd3d12.so과 나란히 호스트에 배치되어 이전에 설명한 것과 동일한 메커니즘을 사용하여 로더 검색 경로에 탑재 및 추가된다.

우리는 CUDA 지원 외에도 WSL 내에서 NVIDIA 도커 툴에 대한 지원을 받고 있다.클라우드에서 실행되는 동일한 컨테이너형 GPU 워크로드는 WSL 내에서 그대로 실행될 수 있다.NVIDIA 도커 툴은 사전 설치되지 않고, 대신 지금처럼 사용자 설치 가능한 패키지로 남아있지만, 패키지는 이제 호환이 되어 하드웨어 가속화와 함께 WSL로 실행될 것이다.

WSL에서의 NVIDIA CUDA 지원에 대한 자세한 내용과 최신 정보는 해당 링크에 방문하십시오.

GUI 응용 프로그램

//build에서 우리는 리눅스 GUI 응용프로그램에 대한 지원이 WSL로 오고 있다고 발표했다.오늘날 WSL은 콘솔 전용이지만, 곧 좋아하는 Linux IDE 또는 기타 GUI 응용 프로그램을 Windows 데스크톱의 다른 Windows 응용 프로그램과 함께 사용할 수 있다.

Linux 애플리케이션과 이를 호스팅하는 Windows 데스크톱 간에 픽셀이 어떻게 흘러가고 다양한 창이 어떻게 통합되고 매끄러운 환경으로 통합될 것인가?그것은 또 다른 시간 😊의 이야기가 될 것이다.

Coming to WDDMv2.9

여기까지 읽어봤다면, 여러분은 아마도 이 모든 것들에 대해 흥분했을 것이고, 이제 언제 실제로 그것을 가지고 놀 수 있을지 궁금해 할 것이다!

DxCore, D3D12, DirectML 및 NVIDIA CUDA에 대한 지원은 패스트 링이 RS_PRELISE로부터 수신 빌드로 다시 전환되면 곧 Windows Insider Fast 빌드에 제공될 예정이다.TensorFlow의 미리보기는 PyPI.org에서 기존 TensorFlow 패키지와 함께 설치 가능한 PyPI 패키지와 거의 동시에 사용할 수 있게 된다.그 때 당신은 그 멋진//구축 데모들을 모두 복제할 수 있을 것이다.미리 보기를 원하시면 aka.ms/gpuinwsl에 채널을 맞추고 향후 ML에 대한 투자를 개선하고 싶다면 잠시 시간을 내어 설문조사를 완료하십시오.

OpenGL/OpenCL 매핑 계층 및 GUI 애플리케이션 지원은 추후 Insider 빌드 플라이닝을 통해 제공될 예정이다.이러한 기술을 준비함에 따라 Windows Insider 빌드 릴리스 노트 및 블로그 업데이트를 통해 귀하에게 계속 알려드릴 겁니다.

네가 이걸 흥미롭게 찾았기를 바래!이 방법을 사용해 보고 피드백을 공유하십시오!

반응형

들어가기에 앞서..

해당 포스트는 MSRC(Microsoft Security Response Center) 블로그에 작성된 First Step Hyper-V Research 내용을 토대로 작성하였습니다.


Debugging Environment

1) Intro

이 글에서 작성할 환경 설정은 nested(중첩) VM을 생성하고 이 내부에서 Hyper-V guest의 하이퍼바이저와 루트 파티션의 커널을 디버깅하기 위함입니다. Hyper-V하이퍼바이저 중에서도 Type-1 방식이기 때문에 Host 에서는 커널과 하이퍼바이저를 디버깅할 수 없습니다. 이를 위해 게스트를 만들고 그 안에 Hyper-V를 활성화(nested vm)하고 모든 것을 구성하여 디버깅을 할 것입니다. 다행히도 Hyper-V는 이 방식에서 활용할 중첩 가상화를 지원합니다. 디버깅 환경은 아래 이미지와 같습니다.

Arch for degugging on hyper-v

디버깅하려는 하이퍼바이저 내부에 다른 하이퍼바이저의 게스트로 실행합니다. 간단히 말해서 L0 루트 파티션의 사용자 공간에서 L1 하이퍼바이저와 루트 파티션의 커널을 디버그합니다.

<Nested VM 용어 설명>

  • L0 = 물리적 호스트에서 실행되는 코드. 하이퍼바이저를 실행합니다.
  • L1 = L0의 하이퍼바이저 게스트. 디버그하려는 하이퍼바이저를 실행합니다.
  • L2 = L1의 하이퍼바이저 게스트.

Hyper-V 의 중첩 가상화에 대하여 좀 더 상세한 설명은 여기를 참조해주세요 :)

2) Setting for debugging

하이퍼바이저에 디버그 지원이 내장되어 있어 디버거로 Hyper-V에 연결할 수 있습니다. 활성화하려면 BCD(Boot Configuration Data) 변수에서 몇 가지 설정을 구성해야 합니다.

 

<디버깅 할 VM 설정하기>

  1. Hyper-V 가 활성화되어 있지 않다면 활성화하기(Level0)
    1. 이 문서를 참고하여 Hyper-v 활성화
    2. Host OS 재부팅하기
  2. 디버깅을 위해 새로운 guest VM을 설정하기(Level1)
    1. 여기에 설명된 대로 1세대 Windows 10 게스트를 만듭니다. (2세대 guest에서도 작동하지만 'Secure boot' 를 비활성화해야 함)
      • 참고 이미지 (nested VM)
    2. 게스트 프로세서에서 VT-x를 활성화합니다. 활성화하지 않으면 Hyper-V 플랫폼이 게스트 내부에서 실행되지 않습니다.
      (L1 Guest OS의 전원을 끄고 L0 Host에서 PowerShell(관리자 권한) 에서 활성화 가능)
      • command
        Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true​
      • 참고 이미지
    3. L1게스트 내부에서 하이퍼바이저를 디버깅할 것이므로 L1게스트 내부에서도 Hyper-V를 활성화해야 합니다( 여기에 문서화됨 ). 나중에 게스트 VM을 재부팅합니다.
    4. 이제 디버깅을 활성화하기 위해 BCD 변수를 설정해야 합니다. L1 게스트(방금 설정한 내부 OS) 내부에서 cmd.exe (관리자 권한) 에서 다음을 실행합니다. 아래와 같이 설정을 하면 부팅 후에 적용됩니다
      • command
        # 직렬 포트를 통해 Hyper-V 디버깅 활성화
        bcdedit /hypervisorsettings serial DEBUGPORT:1 BAUDRATE:115200
        bcdedit /set hypervisordebug on
        
        # Hyper-V가 부팅 시 실행되도록 활성화하고 커널을 로드
        bcdedit /set hypervisorlaunchtype auto
        
        # 다른 직렬 포트를 통해 커널 디버그 활성화
        bcdedit /dbgsettings serial DEBUGPORT:2 BAUDRATE:115200
        bcdedit /debug on
        
        # 테스트 커널 드라이버를 load 할 일이 있을 경우, 아래 기능 활성화
        bcdedit /set TESTSIGN on
      • 참고 이미지
  3. 앞서 설정한 직렬포트와 연결하기 위해서는 Level 0 VM에서 아래와 같이 셋팅한다.
    1. Level 1 VM (guestOS) 종료하기
    2. Level 1 VM 설정하기
      • Hyper-V 관리자에서 Level1 VM 오른쪽 버튼 클릭 -> [설정] -> 왼쪽 탭에서 [하드웨어] -> [COM1]을 선택
      • Named Pipe를 선택하고 "debug_kernel"로 설정
      • COM2에 대해서도 동일한 작업을 수행하고 이름을 "debug_hv"로 설정합니다.
      • 참고:  Set-VMComPort cmdlet를 사용해서도 위와 같은 설정을 할 수 있음
    3. 이제 Named Pipe 로써 “\\.\pipe\debug_hv” 와 “\\.\pipe\debug_kernel” 이 생성되었고, 각각 hypervisor와 루트 파티션(Level1 VM) 커널에 디버깅을 할 수 있게 되었다.
      • 참고 이미지
    4. Level 0 VM에서 2개의 windbg를 open하여 named pipe로 연결한다.
      • windbg 열기 -> 디버깅 시작-커널 연결 (ctrl+k)
    5. guest OS (level1 VM)을 재부팅하면 디버깅이 가능하다.
      • 참고 이미지

3) EOD (End-Of-Documentation)

여기까지 Hyper-V의 커널과 하이퍼바이저를 디버깅하기 위해서 어떻게 해야하는지 작성해보았는데요. 이 내용은 MS 내부 직원이 분석하는 방법중 하나로써 MS블로그 글에 기재가 되어 있었습니다.

블로그 글에서 이 방법뿐만 아니라 다른 방법에 대한 링크를 아래와 같이 공유가 되었으니 참고해주세요 :)

 

반응형

들어가기에 앞서..

해당 포스트는 MSRC(Microsoft Security Response Center) 블로그에 작성된 First Ttep Hyper-V Research 내용을 토대로 작성하였습니다.


가상화 Stack에 대한 간략한 소개

1) Partition

Partition은 hypervisor 위에서 실행되는 다른 VM들을 말합니다. 파티션은 Root partition(또는 부모 파티션), enlightened guest partitions, unenlightened guest partitions 와 같이 3가지 유형으로 구분되며, 이 중에서도 Root partion 은 다른 vm과 달리 host OS를 말합니다. root partition은 웹 브라우저처럼 일반적인 프로그램들을 실행할 수 있는 Windows OS 이지만 가상화 스택의 일부는 root partion kernel과 userspace에서 실행됩니다. 루트 파티션은 하이퍼바이저와 함께 작동하는 특별한 권한이 부여된 게스트 VM으로 생각할 수 있습니다.

예를 들어, Hyper-V Management Services 는 root partion 에서 실행되고 새로운 guest partion 을 생성할 수 있습니다. 다시말해 hyper call 을 이용하여 hypervisor kernel과 통신을 합니다. 통신을 하기 위해서는 더 높은 상위 API가 있는데 그 중 하나는 VMBus 입니다. VMBus는 가상화 Stack에서 가장 많이 사용하는 cross-partiion IPC 구성요소 입니다.

2) Enlightened IO

guest partition 용 가상화 기기는 Storage, Networking, Graphic 및 입력 서브 시스템에 대해 Enlightened(계몽or향상) I/O 라는 기능도 활용할 수 있습니다. Enlightened I/O는 VMBus 위에서 실행되는 통신 프로토콜(예: SCSI) 가상화에 적합한 구현입니다. 이것은 게스트가 가상화 스택을 인식하고 있기 때문에(이런 이유로 "englightened"라 칭함) 더 나은 성능과 기능을 제공하는 device emulation layer를 우회합니다. 그러나 이 기능(Enlightended IO) 을 사용하려면 게스트 VM용 특수 드라이버가 필요합니다.

Hyper-V 통합 서비스를 설치할 때 Hyper-V enlightened I/O 와 a hypervisor aware kernel 을 사용할 수 있습니다. VSC(Virtual Server Client) 드라이버를 포함하는 통합 구성 요소는 Windows 및 일반 리눅스 배포판 일부에서 하용할 수 있습니다.

3) Generation (1세대 / 2세대)

Hyper-V에서 게스트 파티션을 만들 때 "1세대" 또는 "2세대" 게스트를 선택할 수 있습니다. 두 가지 유형의 VM 간의 차이점에 대해 설명하지 않겠지만, 1세대 VM은 대부분의 게스트 운영 체제를 지원하는 반면 2세대 VM은 보다 제한된 운영 체제(대부분 64비트)를 지원한다는 점을 알아야 합니다. 이 게시물에서는 1세대 VM만 사용하겠습니다. "1세대"와 "2세대"의 차이점에 대한 자세한 설명은 여기에서 볼 수 있습니다.

4) Summary

요약하자면 일반적인 가상화 설정은 다음과 같습니다.

Root Partition Enlightened child partitions Unenlightened child partitions

Windows
Windows or Linux FreeBSD, legacy Linux ...

5) EOD

이 블로그 게시물에 대해 알아야 할 모든 것입니다. 자세한 내용은 이 프레젠테이션 또는 TLFS를 참조 하세요.

+ Recent posts