다음을 통해 공유

GPU-P 디바이스에서 실시간 마이그레이션

  • 아티클

이 문서에서는 SR-IOV(단일 루트 I/O 가상화) 분할을 통해 가상화된 이종 컴퓨팅 디바이스(GPU, NPU 등)의 실시간 마이그레이션 기능 설계에 대해 설명합니다. WDDM 및 MCDM 드라이버 모델을 통한 분할을 지원하는 디바이스는 이제 가상화 제품의 필수적인 부분입니다. 따라서 실시간 마이그레이션을 지원하고 가상화 추상화가 리소스 할당을 변경해야 할 때 고객에게 미치는 영향을 최대한 안정적으로 유지하도록 돕는 것이 중요합니다. 이 문서에서는 이러한 디바이스의 빠른 마이그레이션 도 설명합니다.

실시간 마이그레이션은 Windows 11 버전 24H2(WDDM 3.2)부터 지원됩니다. 일반적으로 기능을 노출하는 드라이버에 대한 GPU 매개 변수화(GPU-P) DPI의 확장입니다. GPU-P 가상화 인터페이스를 구현하는 MCDM 드라이버는 선택적으로 심사 이벤트가 있는 확장을 포함하여 이러한 라이브 마이그레이션 인터페이스를 구현할 수도 있습니다.

이 문서에서 "GPU"는 단순히 GPU-P 가상화 프레임워크를 구현하는 디바이스, WDDM 또는 MCDM, GPU, NPU 또는 기타 다른 유형의 컴퓨팅 디바이스를 나타냅니다.

리소스 마이그레이션의 종류 및 목적

리소스 마이그레이션은 가상화를 새 물리적 리소스로 이동하는 기능입니다. 다음을 포함하여 가상화된 실행을 이동할 수 있는 다양한 방법이 있습니다.

  • 전원을 늦추지 않습니다. 가상 마더보드를 직접 전원을 공급하여 가상 리소스 실행을 중지할 수 있습니다. powerhit-tolerant가 아닌 모든 애플리케이션은 작동 중인 데이터가 손실되고 모든 디바이스 상태가 초기화됩니다. 그런 다음 VHD(가상 하드 디스크)를 다른 호스트 머신에서 가상화하여 콜드 부팅할 수 있습니다.

  • 소프트 파워 다운. 이 전원 다운은 단순히 게스트 OS에 전원 요청을 전송한다는 점에서 하드 파워 다운과 다릅니다. 그런 다음 게스트 OS는 전원 다운 메커니즘을 애플리케이션에 배포하여 클린 종료합니다. 애플리케이션은 이 알림을 사용하여 모든 데이터를 안전하게 저장하고 부팅 시 다시 시작하도록 등록할 수 있지만 각 애플리케이션의 프로그래밍에 따라 달라집니다. 소프트 다운을 사용하려면 이 클린 종료 메커니즘을 지원하는 게스트 OS와 현재 상태를 저장하고 다시 부팅 시 다시 시작하는 적절한 서비스가 필요합니다.

  • 최대 절전 모드. 게스트가 시작한 이 기술을 사용하면 게스트가 모든 애플리케이션 프로세스가 고정되고, 디바이스 상태가 CPU 메모리로 제거되고, 모든 메모리가 스토리지로 전송되어 하드웨어의 전원이 다운될 수 있는 빠른 시작 절전 상태로 전환할 수 있습니다. 그런 다음 다른 컴퓨터에서 VM 스토리지 VHD를 다시 시작하고 메모리가 로드되고 디바이스 상태가 복원되고 프로세스가 고정되지 않을 수 있습니다. 최대 절전 모드는 이를 지원하는 게스트 OS에서만 사용할 수 있습니다. 게스트 안정성에 의존하는 상당히 침습적인 프로세스이지만 전원 다운 메커니즘이 제공하지 않는 상태로 애플리케이션 프로세스를 복원하는 메커니즘을 제공합니다.

  • 빠른 마이그레이션(VM 저장 및 복원이라고도 함). 이 기술을 사용하면 VM이 일시 중지되고(vCPU 예약 중지) 새 물리적 리소스의 상태를 복원하는 데 필요한 모든 상태가 호스트 OS 내에 수집됩니다(VM의 메모리 및 모든 디바이스의 상태 포함). 그런 다음 이 상태는 모든 vCPU 컨텍스트가 로드된 VM을 만들고, 메모리를 VM 공간에 매핑하고, 디바이스 상태를 복원하는 새 호스트로 전송됩니다. 그런 다음 PowerOnRestore는 vCPU 실행을 다시 시작합니다. 이 기술은 게스트 OS와 독립적이며 게스트 환경에서의 실행에 의존하지 않으므로 최대 절전 모드보다 프로세스 및 디바이스 상태를 기본 더 신뢰할 수 있는 방법입니다. VM 메모리가 많은 GB가 될 수 있고 전송 시간이 눈에 띄기 때문에 가상화 사용자는 상당한 가동 중지 시간을 알 수 있습니다.

  • 실시간 마이그레이션. 가상화된 리소스가 여전히 활성 상태인 동안 콘텐츠를 전송할 수 있고 더러워지는 콘텐츠를 추적할 수 있는 경우 가상화를 활성 상태로 유지하면서 중요한 콘텐츠를 전송할 수 있습니다. 그런 다음 VM이 일시 중지되면 훨씬 적은 콘텐츠를 전송해야 하며 가상화가 실행되지 않는 시간을 최소화할 수 있습니다. 마이그레이션 중에 발생하는 모든 작업이 방해받지 않고 계속 발생하고 리소스 사용률에 미치는 영향이 현재 가능한 한 감소하므로 최종 사용자 영향은 최소화됩니다. 특히 중단 기한(TCP 및 외부 엔드포인트가 있는 다른 프로토콜 시간 제한과 같은 가상화 중단에 대한 외부 시간 제약 조건)을 최소화하거나 제거할 수 있습니다.

각 진행은 가상화의 물리적 할당 변경에 대한 일부(종종 주요) 고객 인식을 줄이거나 제거하므로 가상화가 점점 더 완전하고 투명해집니다. 인프라에 대한 고객 종속성을 구분하는 다른 기술(예: 호스트 크래시 격리)과 함께 가상화 솔루션을 할당 독립성 및 진정한 임시 컴퓨팅의 이상으로 이동합니다.

대규모 디자인

실시간 마이그레이션은 원본 호스트에서 대상 호스트로 가상화 콘텐츠를 전송합니다. 가상화는 메모리, 컴퓨팅 및 스토리지를 포함할 수 있는 다양한 상태 저장 디바이스로 구성되며, 각각 원본의 디바이스에서 대상의 디바이스로 전송해야 하는 데이터가 있습니다. 클러스터에서 가상화를 관리하는 관리 에이전트는 호스트와 통신하여 기존 VM의 원본 마이그레이션(콘텐츠가 호스트를 떠날 때) 또는 새 VM으로 대상 마이그레이션(콘텐츠를 받기 위해)에 대한 오케스트레이션을 설정하도록 알릴 수 있습니다. 이 상호 작용의 주요 플레이어는 다음 다이어그램에 표시됩니다.

:실시간 마이그레이션을 위한 아키텍처 구성 요소를 보여 주는 다이어그램

원본 호스트의 Epoch

다음 다이어그램에서는 원본 쪽 마이그레이션 상태를 보여 줍니다.

:원본 쪽 마이그레이션 상태를 보여 주는 다이어그램

원본 쪽 부팅

호스트가 일반적으로 부팅되면 KMD는 다양한 초기화 호출을 통해 디바이스 기능을 커널에 보고합니다.

KMD가 DXGKQAITYPE_GPUPCAPS 데이터에 대한 DxgkDdiQueryAdapterInfo 호출을 받으면 DXGK_GPUPCAPS 추가된 LiveMigration 기능 비트를 설정할 수 있습니다. KMD가 이 비트를 설정하면 드라이버가 실시간 마이그레이션을 지원한다는 것을 나타냅니다.

실시간 마이그레이션 지원의 필수 조건은 Dirty 비트 추적에 설명된 대로 모든 GPU 로컬 메모리 세그먼트에서 수정된 VRAM 페이지 추적을 지원하는 것입니다. 해당 지원은 다른 지정된 정보 유형에 대한 다른 DxgkDdiQueryAdapterInfo 호출을 통해 보고됩니다. 실시간 마이그레이션에 대한 지원을 보고하는 드라이버는 더티 비트 추적에 대한 지원도 보고해야 합니다. 실시간 마이그레이션을 지원하지만 더티 비트 추적은 잘못된 구성이며 Dxgkrnl이 어댑터를 시작하지 못합니다.

온라인 VM

호스트가 부팅되고 관리 스택이 온라인 상태가 되면 가상 머신 작업이 온라인 상태가 됩니다. VM 시작 및 중지에 대한 요청이 도착하기 시작하고 이러한 가상화에 프로젝션된 GPU-P vGPU를 보기 시작합니다.

성능이 뛰어난 더티 비트 평면 기능을 가정하면 Dxgkrnl은 VF(가상 함수)에 대한 VRAM 리소스를 예약한 후 DxgkDdiStartDirtyTracking을 호출합니다. 이를 통해 시스템은 나중에 VF가 마이그레이션 시나리오에 참여하는 경우 VRAM 클린선을 추적할 수 있습니다.

이 VM 시작은 인터럽트 테이블 액세스를 가로채서 인터럽트 지원을 가상화하기 시작하며, 이는 VM의 수명 동안 진행됩니다.

실시간 마이그레이션 보내기 준비

관리 스택은 컨트롤로 표시될 때 실시간 마이그레이션을 시작하기 위해 이벤트를 보내고, 마이그레이션 상태 컴퓨터 관리는 대상에서 vGPU를 다시 구성하기 위해 가상화(vGPU 파티션 구성 메트릭)의 수명 동안 변경할 수 없는 가상 디바이스에서 모든 상태를 수집합니다. 준비가 되면 전송 버퍼를 준비하고 전송 스택을 초기화하는 프로세스가 시작됩니다.

이 Epoch는 도입된 DxgkDdiPrepareLiveMigration DDI에 대한 호출을 생성합니다. KMD는 VF에 대한 공정한 성능을 유지하면서 호스트의 VRAM에서 더티 콘텐츠를 스트리밍하는 실시간 마이그레이션 기능을 제공하는 PF/VF 예약 정책을 설정해야 합니다. 더티 추적이 성능이 잘못된 것으로 보고되면 이 지점도 더티 추적이 시작되는 위치입니다.

실시간 마이그레이션 보내기

:실시간 마이그레이션 보내기를 보여 주는 다이어그램

그런 다음 더티 VRAM 전송의 활성 단계를 입력합니다. 이 단계에서는 더티 비트플레인 DDI를 통해 호출하여 VF 프레임 버퍼의 스냅샷 가져옵니다. 그런 다음 GPU에서 이전에 준비한 CPU 버퍼로 해당 페이지를 페이징합니다.

이 전송에는 VM 및 모든 가상 디바이스가 일시 중지되는 단계가 있습니다. VF는 게스트에 대한 예약을 중지할 수 있으며, 이때 콘텐츠 페이징을 완료하기 위해 PF에 부여할 수 있는 추가 타임스플라이스가 있어야 합니다. VF와 vCPU가 모두 VM에서 일시 중지되므로 이 시점 이후에 마이그레이션되는 콘텐츠(CPU 또는 디바이스-로컬 메모리)가 더 이상 변경되지 않아야 합니다.

일시 중지된 마이그레이션 보내기

일시 중지된 동안 더티 페이지의 마지막 반복이 전송됩니다. 이 시점에서 활성 상태에서 변경 가능하고 이전 준비에서 전송할 수 없었던 디바이스 및 드라이버 상태의 마지막 부분을 수집하기 위한 호출이 수행됩니다. 이 상태는 다른 쪽에 필요한 상태 재구성, 추적 구조 또는 일반적으로 대상 쪽에서 VF 상태 복원을 완료하는 데 필요한 모든 정보일 수 있습니다.

실시간 마이그레이션 중단

마지막으로 VM 및 모든 가상 디바이스가 상태를 새 물리적 실현으로 전송하면 원본 쪽에서 VM 잔재를 클린 수 있습니다. 버퍼 및 기타 마이그레이션 상태가 지워지고 vGPU가 제거됩니다.

대상 호스트의 Epoch

다음 다이어그램에서는 대상 쪽 마이그레이션 상태를 보여 줍니다.

:대상 쪽 마이그레이션 상태를 보여 주는 다이어그램

대상 쪽 부팅

대상의 부팅은 원본과 동일하게 표시됩니다. 부팅은 전체 시스템용으로, 수명 주기 내내 다른 VF의 원본 및 대상이 될 수 있습니다. 드라이버는 참여하려면 실시간 마이그레이션 지원을 지정하기만 하면됩니다.

실시간 마이그레이션 수신 준비

대상 쪽에서 VM은 마치 새 VM인 것처럼 시작하여 생성됩니다. VM 및 가상 디바이스가 만들어집니다. 이 만들기 프로세스에는 원본 쪽에서 만든 것과 동일한 매개 변수를 사용하여 만든 가상 GPU가 포함됩니다. 만든 후 유효성 검사 데이터가 수신되고 드라이버에 전달되어 대상 쪽이 VM을 복원하기 위해 원본과 호환되는지 확인합니다. 이 시점에서 드라이버 버전, 펌웨어 버전 및 대상 시스템 및 드라이버의 다른 주변 상태를 포함하여 이러한 호환성에 영향을 줄 수 있는 모든 것을 확인해야 합니다. 드라이버는 VF가 아직 활성화되지 않은 동안 일반적으로 VF에 할당되는 모든 페이징에 대한 PF 액세스를 허용하도록 구성됩니다.

실시간 마이그레이션 수신

:실시간 마이그레이션 수신을 보여 주는 다이어그램입니다.

페이징 방향이 CPU 버퍼에서 VRAM으로 이동되는 경우를 제외하고 더티 페이지 데이터를 받는 것은 원본의 단계와 비슷합니다. 모든 전송은 VF가 일시 중지되는 동안 수행되므로 전체 전송은 VF 예산 내에서 수행할 수 있습니다.

VM 시작 및 중단

모든 VRAM 마이그레이션이 완료되면 vGPU는 전송해야 하는 추가 상태(최종 변경 가능한 저장 데이터)를 설정할 기회를 얻습니다. 그런 다음 대상에서 VM을 시작하고 전송에 사용되는 버퍼를 포함하여 마이그레이션 상태를 중단합니다.

성능 목표

실시간 마이그레이션의 중요한 부분은 응답성입니다. 특히 외부에서 응답하지 않는 가상화의 가동 중지 시간을 최소화합니다(가상화 사용자 또는 추가 연결될 수 있는 엔드포인트에 대해). 많은 네트워크 스택 프로토콜에는 재시도/다시 설정이 실패하기 전에 매우 간단한 원격 컴퓨터에서 시간 제한이 있으므로 삭제할 때 사용자에게 방해가 될 수 있습니다. 일반적인 고정 목표로서 전송 및 시작에 대한 총 일시 중지 시간은 1초(750ms)의 3분기 미만이어야 하며, 이로 인해 가장 일반적인 스택 시간 제한으로 연락 시간이 초과됩니다.

또한 활성 시스템의 성능 변경은 가능한 경우 다른 최종 사용자 중단을 트리거해서는 안 됩니다. 이러한 DDIS를 사용하는 디바이스에서 시스템은 예약된 시간 단축을 늦추어 TDR 속도를 크게 증가시켜서는 안 됩니다. 이제 대부분의 TDR은 긴 패킷이 아니라 디바이스를 중단한 것으로 예상하며, 패킷을 실행하는 시간을 두 배로 늘리거나 세 배로 늘리면 대부분의 패킷이 시간 제한 시간(초)에 걸쳐 푸시되지 않아야 합니다. 그러나 일반적인 성능 그림에서 시간 제한을 트리거하지 않는 것을 알아야 합니다.

디바이스 드라이버 인터페이스

일반적으로 실시간 마이그레이션 DDI는 WDDM 및 MCDM DDIS의 일반적인 개념과 특히 GPU-P 가상화 DDI를 참조합니다.

  • hAdapter 는 일반적으로 이 드라이버가 관리하는 특정 디바이스를 나타내는 핸들 토큰을 나타냅니다. 시스템에 의해 열거된 여러 물리적 디바이스가 있는 시스템에는 드라이버가 여러 hAdapter를 관리하므로 hAdapter 는 특정 디바이스로 지역화됩니다.

  • vfIndex 는 참조되는 가상 함수/vDEV를 식별합니다. 특정 가상 디바이스로 지역화됩니다. 파티션 ID라고도 합니다.

  • DeviceLuid 는 특정 가상 디바이스를 지역화하지만 가상 디바이스 관리를 사용하여 UMED 인터페이스의 언어로 다운됩니다.

  • SegmentId 는 VRAM 예약과 같이 디바이스에 저장된 콘텐츠를 참조할 때 특정 VidMm 세그먼트 노출을 식별합니다.

인터페이스 정의에 대한 참고 사항

이 문서에서는 동적으로 크기가 조정된 구조를 참조합니다. 이러한 구조는 참조 페이지에서 다음과 같이 설명하는 동적 크기 배열을 통해 구현됩니다.

    size_t       ArraySize;
    ElementType  Array[ArraySize];

여기서 인터페이스는 구조의 앞부분에서 배열 크기를 전달하고 인터페이스 개체의 구문 분석은 배열이 제공될 때 해당 많은 요소를 반복합니다. 이러한 선언은 정적으로 크기가 조정된 조각을 표현하기 때문에 유효한 C/C++가 아닙니다. 정적 크기의 구조체에서 먼저 읽은 다음 코드에서 동적으로 구문 분석합니다.

디바이스 시작 및 대문자 보고

다음 기능이 DXGK_GPUPCAPS 추가됩니다.

  • LiveMigration 상한은 실시간 마이그레이션 기능에 대한 드라이버 지원을 나타냅니다(일반적으로 DxgkDdiSetVirtualGpuResources2를 제외하고 이 문서에 추가된 DDIS가 멘션).
  • ScatterMapReserve 상한은 향후 릴리스에서 추가될 DxgkDdiSetVirtualGpuResources2에 대한 드라이버 지원을 나타냅니다.

OS가 DXGKQAITYPE_GPUPCAPS 요청으로 DxgkDdiQueryAdapterInfo를 호출할 때 KMD는 이러한 대문자를 채워야 합니다. OS는 DxgkDdiStartDevice가 호출된 후와 어댑터가 GPU 분할을 지원하는 경우 디바이스 초기화 중에 캡을 쿼리합니다.

드라이버가 ScatterMapReserve 상한을 반환하는 경우 OS에서 드라이버의 분산 예약 기능을 쿼리할 수 있도록 다음과 같은 연결된 구조체로 추가된 DXGKQAITYPE_SCATTER_RESERVE 형식을 노출해야 합니다.

  • pInputData에 대한 DXGK_QUERYSCATTERRESERVEIN
  • pOutputData에 대한 DXGK_QUERYSCATTERRESERVEOUT

분산 페이징 지원

연속되지 않은 더티 페이지와 프레임 버퍼 간의 전송을 지원하기 위해 이 기능은 연속된 물리적 주소로 지원되지 않는 GPU-VA 매핑을 가장 먼저 연습하는 기능 중 하나입니다. 현재 페이징 인터페이스는 항상 페이지 테이블에서 지원되는 일반적인 가능성이기 때문에 이 지원을 위해 업데이트할 필요가 없습니다. 그러나 인접성에 대한 가정을 한 잠재적 구현 세부 사항은 이러한 변경으로 인해 노출될 가능성이 높습니다. 따라서 이 OS 메커니즘을 이해하고, 가상 페이징 인터페이스를 실행하는 방법을 이해하고, 페이징이 이 변경에 강력한지 확인하는 것이 중요합니다.

특히 TransferVirtual 인터페이스는 이제 프레임 버퍼에 연속적으로 매핑되지 않은 VA 범위를 전달합니다.

실시간 마이그레이션 시작 송신 쪽

시스템이 마이그레이션의 라이브 구성 요소를 시작하면 추가 된 DxgkDdiPrepareLiveMigration DDI를 호출해야 합니다. 이 호출은 이 Epoch가 시작되었음을 드라이버에 알리고 마이그레이션에 대한 VF 예약 정책을 구성할 수 있도록 하며, PF 페이징에 대한 무료 및 마이그레이션-VF 예산 중 일부를 할당해야 합니다.

그런 다음 Dxgkrnl 은 KMD의 DxgkDdiSaveImmutableMigrationData DDI를 호출하여 대상 쪽에서 복원할 디바이스에 대한 정보를 수집합니다.

시스템이 변경할 수 없는 데이터 및 유효성 검사 데이터를 수집하고 보내면 더티 보내기의 기본 반복 루프가 시작됩니다.

반복 저장/보내기

개요 섹션에 설명된 대로 반복된 저장 작업은 DxgkDdiQueryDirtyBitData를 사용하여 각 반복 시작 시 VF에 대한 현재 더티 비트플레인을 스냅샷 표준 DXGK_OPERATION_VIRTUAL_TRANSFER 작업을 사용하여 보고된 더티 페이지를 페이징합니다. 이 작업이 더티 추적 기능에서 무시할 수 있는 성능 영향이 아니라고 보고한 디바이스에서 발생하는 경우 시스템의 반복 컨트롤은 먼저 더티 추적을 사용하도록 설정한 다음, 더티 비트플레인을 쿼리하기 위한 첫 번째 호출 전에 전체 프레임 버퍼를 전송합니다.

가상 전송의 경우 기본 업데이트 동작은 매핑이 연속된 VA와 연속된 PA가 아니라는 것입니다. 대신 매핑 아래에 PA의 연결이 끊긴 페이지가 있을 수 있습니다. 그렇지 않으면 동작은 원래 페이징 및 더티 비트플레인 추적 설명서에 설명된 대로 수행되며 이 기능은 추가되지 않습니다.

실시간 마이그레이션 종료 송신 쪽

마이그레이션이 끝나면 시스템은 아직 전송되지 않은 상태 다시 빌드 및 추적을 완료하는 데 필요한 모든 디바이스 및 드라이버 상태를 수집해야 합니다. 이 데이터는 이전 마이그레이션 데이터의 불변성 요구 사항에 맞지 않으며 VRAM 더티 콘텐츠가 아니므로 전송할 수 없습니다. Dxgkrnl 은 추가 된 DxgkDdiSaveMutableMigrationData DDI를 호출합니다. 이 DDI의 사용법은 DxgkDdiSaveImmutableMigrationData와 유사합니다.

결국 이 VF 에서 마이그레이션 구성이 더 이상 필요하지 않은 경우 DxgkDdiEndLiveMigration 이 호출됩니다. 모든 일정 및 상태는 비준수 구성으로 돌아가야 합니다.

실시간 마이그레이션 시작 수신 쪽

변경할 수 없는 데이터가 수신 쪽에 들어오면 시스템은 DxgkDdiRestoreImmutableMigrationData에 대한 호출을 통해 KMD에 직접 전달합니다.

이 DDI는 현재 일시 중지된 VF에 대해서만 호출해야 합니다.

반복 복원/받기

다시 말하지만, 분산 페이징은 반복적인 방식으로 작동하지만 이번에는 대상의 더티 비트 평면이 페이징에 의해 생성되기 때문에 VF에서 예약된 프레임 버퍼에 연결된 더티 비트플레인을 검사하기 위한 호출 없이 작동합니다. 페이징 방향이 반전됩니다. 수신된 버퍼의 콘텐츠가 VRAM으로 전송되고 페이지 배치가 결정됩니다.

실시간 마이그레이션 종료 수신 쪽

마이그레이션이 종료되면 수신 쪽 시스템은 복원할 최종 상태 패키지와 함께 드라이버의 DxgkDdiRestoreMutableMigrationData 함수를 호출합니다. 이 패키지는 드라이버가 상태를 복원하고 추적하며 VF 상태를 다시 복원하기 위해 전송할 수 있도록 남아 있는 모든 콘텐츠를 제공해야 기본.

이 DDI는 현재 일시 중지된 VF에 대해서만 호출해야 합니다.

이 호출 후 시스템은 KMD의 DxgkDdiEndLiveMigration 함수를 호출하여 일반 VF 일정 복원을 포함하여 실시간 마이그레이션과 관련된 상태를 클린 대상 쪽에 알릴 수 있도록 합니다.

UMED와의 통신

UMED(사용자 모드 에뮬레이션 DLL) 인터페이스는 실시간 마이그레이션 중에 콘텐츠를 저장하고 유효성을 검사하는 기능을 노출하기 위해 IGPUPMigration 인터페이스로 확장됩니다.

HRESULT SaveImmutableGpup(
    [in]     PLUID     DeviceLuid,
    [in,out] UINT64 *  Length,
    [in,out] BYTE *    SaveBuffer
    );

HRESULT RestoreImmutableGpup(
    [in] PLUID   DeviceLuid,
    [in] UINT64  Length,
    [in] BYTE *  RestoreBuffer
    );

KMD가 유사하게 호출되는 실시간 마이그레이션 준비 작업 중에 UMED는 마이그레이션을 준비하는 데 유용할 수 있는 모든 정보를 전송하거나 UMED 수준에서 마이그레이션을 환경 지원 유효성 검사를 수행할 수 있습니다. UMED(스레딩 및 프로세스 컨텍스트, 제한된 OS 노출 등)에 대한 표준 인터페이스 계약을 사용하는 UMED에 대한 선택적 인터페이스입니다. 호출 패턴은 KMD DD를 모방하고 2단계 저장을 사용합니다. 이러한 호출에는 다른 저장/복원 UMED 인터페이스와 같은 상태 플래그가 없습니다. 디바이스 및 해당 LUID의 수명 동안 유효하고 일정해야 하므로.

UMED의 변경 가능한 상태는 기존 저장/복원 인터페이스에서 전송됩니다. 과거에는 이 인터페이스가 GPU-P 드라이버로 실행되지 않도록 차단되었지만 KMD가 LiveMigration에 대한 지원을 보고할 때 차단이 해제되었습니다. 이러한 UMED 설명선 함수 및 KMD 기능의 연결은 의도적인 것입니다. 실시간 마이그레이션은 시스템에서 이러한 디바이스의 가상화를 위한 빠른 마이그레이션을 구현하는 방법입니다. 동일한 작업 시퀀스가 수행되며 활성 전송이 없는 실시간 마이그레이션의 특수한 경우로 빠른 마이그레이션(저장/복원)을 생각할 수 있습니다. 저장/복원을 지원하는 UMED에는 라이브 마이그레이션 DD를 지원하는 KMD가 있어야 합니다. 마찬가지로 UMED는 IGPUPMigration 인터페이스를 인식하고 KMD가 실시간 마이그레이션되기 전에 설계에 필요한지 여부를 평가해야 합니다.

인터럽트 가상화

마이그레이션 중에 기본 하드웨어가 변경됨에 따라 MSI-X 테이블 액세스를 제대로 서비스하려면 게스트 인터럽트 관리의 물리적 주소를 가상화해야 합니다. UMED는 실시간 마이그레이션을 지원하는 모든 드라이버에 대해 MSI-X 인터럽트 테이블을 가로채야 합니다. 메시지 상한 주소 및 메시지 주소 필드에 대한 모든 읽기 또는 쓰기는 실제 하드웨어 값에 매핑해야 합니다. Dxgkrnl은 가상화된(또는 게스트) 주소의 매핑을 기본 호출 스택에 필요한 경우 대체를 수행합니다.

OS는 테이블이 읽거나 쓰는 게스트 물리적 주소의 가상화/매핑을 관리하며, 실제 인터럽트 서비스에 필요한 호스트 물리적 주소를 사용하여 게스트 쪽을 참조할 수 있습니다. 이 일반적인 경로는 별도의 UMED 구현 또는 커널 전달이 필요하지 않으며 OS가 테이블을 가로챌 때 OS가 UMED에 알리지 않습니다. UMED에 대한 유일한 요구 사항은 테이블의 BAR 페이지에 대해 디바이스에 대한 완화를 설정해야 한다는 것입니다.

그러나 커널 에서 Dxgkrnl 은 KMD가 실제 쓰기를 서비스하기를 원합니다. KMD는 추가 된 DxgkDdiWriteVirtualizedInterrupt 콜백 함수를 구현하여 이를 수행합니다.

UMD는 값비싼 커널 점프가 필요하지 않도록 쓰기(가상화/게스트 번역 형식)를 로컬로 추적하기 때문에 읽기가 필요하지 않습니다. 이 추적은 가상 디바이스로 마이그레이션됩니다.

DDI 동기화 및 IRQL 컨텍스트

Ddi 동기화 수준 IRQL
DxgkDdiPrepareLiveMigration 0 PASSIVE
DxgkDdiEndLiveMigration 0 PASSIVE
DxgkDdiSaveImmutableMigrationData 0 PASSIVE
DxgkDdiSaveMutableMigrationData 0 PASSIVE
DxgkDdiRestoreImmutableMigrationData 0 PASSIVE
DxgkDdiRestoreMutableMigrationData 0 PASSIVE
DxgkDdiWriteVirtualizedInterrupt 0 PASSIVE
DxgkDdiSetVirtualGpuResources2 0 PASSIVE
DxgkDdiSetVirtualFunctionPauseState 0 PASSIVE
IGPUPMigration::SaveImmutableGpup 0 PASSIVE
IGPUPMigration::RestoreImmutableGpup 0 PASSIVE

VF 예약에 대한 중요한 고려 사항

전송의 효율성은 PF에 대한 페이징 전송 예약에 의해 강력하게 결정됩니다. PF가 버스를 포화시키고 최상의 처리량을 얻는 데 사용할 수 있는 디바이스의 페이징 엔진에 더 많이 액세스할수록 전송이 일반적으로 더 성능이 높고 특히 일시 중지된 전송이 수행됩니다. 지정된 시간에 캡처하고 전송할 수 있는 콘텐츠가 많을수록 더 좋습니다. 적어도 네트워크 채도까지.

예약 변경이 페이징 엔진에만 영향을 주며 다른 디바이스 리소스에는 영향을 주지 않는 것이 좋지만, 모든 VF 예약 디자인에서 이를 허용하지는 않습니다. 최소한 다음을 예약하는 것이 좋습니다.

  • 마이그레이션 중인 VF 또는 할당되지 않은 VF 일정에서만 예산을 가져옵니다.
  • 컴퓨터의 다른 가상화에 대한 성능이 저하되지 않습니다.

VF가 전체 전송을 일시 중지하고 전체 예산을 사용할 수 있으므로 대상 쪽에서 이러한 조건을 훨씬 더 쉽게 충족할 수 있습니다. 원본 쪽에서는 마이그레이션 요구 사항과 VM 요구 사항의 분산이 필요하며, 궁극적으로 일시 중지 전송 목표를 충족해야 합니다.