요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
Overview
========
The Linux kernel contains a variety of code for running as a fully
enlightened guest on Microsoft's Hyper-V hypervisor. Hyper-V
consists primarily of a bare-metal hypervisor plus a virtual machine
management service running in the parent partition (roughly
equivalent to KVM and QEMU, for example). Guest VMs run in child
partitions. In this documentation, references to Hyper-V usually
encompass both the hypervisor and the VMM service without making a
distinction about which functionality is provided by which
component.
Hyper-V runs on x86/x64 and arm64 architectures, and Linux guests
are supported on both. The functionality and behavior of Hyper-V is
generally the same on both architectures unless noted otherwise.
Linux Guest Communication with Hyper-V
--------------------------------------
Linux guests communicate with Hyper-V in four different ways:
* Implicit traps: As defined by the x86/x64 or arm64 architecture,
some guest actions trap to Hyper-V. Hyper-V emulates the action and
returns control to the guest. This behavior is generally invisible
to the Linux kernel.
* Explicit hypercalls: Linux makes an explicit function call to
Hyper-V, passing parameters. Hyper-V performs the requested action
and returns control to the caller. Parameters are passed in
processor registers or in memory shared between the Linux guest and
Hyper-V. On x86/x64, hypercalls use a Hyper-V specific calling
sequence. On arm64, hypercalls use the ARM standard SMCCC calling
sequence.
* Synthetic register access: Hyper-V implements a variety of
synthetic registers. On x86/x64 these registers appear as MSRs in
the guest, and the Linux kernel can read or write these MSRs using
the normal mechanisms defined by the x86/x64 architecture. On
arm64, these synthetic registers must be accessed using explicit
hypercalls.
* VMBus: VMBus is a higher-level software construct that is built on
the other 3 mechanisms. It is a message passing interface between
the Hyper-V host and the Linux guest. It uses memory that is shared
between Hyper-V and the guest, along with various signaling
mechanisms.
The first three communication mechanisms are documented in the
`Hyper-V Top Level Functional Spec (TLFS)`_. The TLFS describes
general Hyper-V functionality and provides details on the hypercalls
and synthetic registers. The TLFS is currently written for the
x86/x64 architecture only.
.. _Hyper-V Top Level Functional Spec (TLFS): https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs
VMBus is not documented. This documentation provides a high-level
overview of VMBus and how it works, but the details can be discerned
only from the code.
Sharing Memory
--------------
Many aspects are communication between Hyper-V and Linux are based
on sharing memory. Such sharing is generally accomplished as
follows:
* Linux allocates memory from its physical address space using
standard Linux mechanisms.
* Linux tells Hyper-V the guest physical address (GPA) of the
allocated memory. Many shared areas are kept to 1 page so that a
single GPA is sufficient. Larger shared areas require a list of
GPAs, which usually do not need to be contiguous in the guest
physical address space. How Hyper-V is told about the GPA or list
of GPAs varies. In some cases, a single GPA is written to a
synthetic register. In other cases, a GPA or list of GPAs is sent
in a VMBus message.
* Hyper-V translates the GPAs into "real" physical memory addresses,
and creates a virtual mapping that it can use to access the memory.
* Linux can later revoke sharing it has previously established by
telling Hyper-V to set the shared GPA to zero.
Hyper-V operates with a page size of 4 Kbytes. GPAs communicated to
Hyper-V may be in the form of page numbers, and always describe a
range of 4 Kbytes. Since the Linux guest page size on x86/x64 is
also 4 Kbytes, the mapping from guest page to Hyper-V page is 1-to-1.
On arm64, Hyper-V supports guests with 4/16/64 Kbyte pages as
defined by the arm64 architecture. If Linux is using 16 or 64
Kbyte pages, Linux code must be careful to communicate with Hyper-V
only in terms of 4 Kbyte pages. HV_HYP_PAGE_SIZE and related macros
are used in code that communicates with Hyper-V so that it works
correctly in all configurations.
As described in the TLFS, a few memory pages shared between Hyper-V
and the Linux guest are "overlay" pages. With overlay pages, Linux
uses the usual approach of allocating guest memory and telling
Hyper-V the GPA of the allocated memory. But Hyper-V then replaces
that physical memory page with a page it has allocated, and the
original physical memory page is no longer accessible in the guest
VM. Linux may access the memory normally as if it were the memory
that it originally allocated. The "overlay" behavior is visible
only because the contents of the page (as seen by Linux) change at
the time that Linux originally establishes the sharing and the
overlay page is inserted. Similarly, the contents change if Linux
revokes the sharing, in which case Hyper-V removes the overlay page,
and the guest page originally allocated by Linux becomes visible
again.
Before Linux does a kexec to a kdump kernel or any other kernel,
memory shared with Hyper-V should be revoked. Hyper-V could modify
a shared page or remove an overlay page after the new kernel is
using the page for a different purpose, corrupting the new kernel.
Hyper-V does not provide a single "set everything" operation to
guest VMs, so Linux code must individually revoke all sharing before
doing kexec. See hv_kexec_handler() and hv_crash_handler(). But
the crash/panic path still has holes in cleanup because some shared
pages are set using per-CPU synthetic registers and there's no
mechanism to revoke the shared pages for CPUs other than the CPU
running the panic path.
CPU Management
--------------
Hyper-V does not have a ability to hot-add or hot-remove a CPU
from a running VM. However, Windows Server 2019 Hyper-V and
earlier versions may provide guests with ACPI tables that indicate
more CPUs than are actually present in the VM. As is normal, Linux
treats these additional CPUs as potential hot-add CPUs, and reports
them as such even though Hyper-V will never actually hot-add them.
Starting in Windows Server 2022 Hyper-V, the ACPI tables reflect
only the CPUs actually present in the VM, so Linux does not report
any hot-add CPUs.
A Linux guest CPU may be taken offline using the normal Linux
mechanisms, provided no VMBus channel interrupts are assigned to
the CPU. See the section on VMBus Interrupts for more details
on how VMBus channel interrupts can be re-assigned to permit
taking a CPU offline.
32-bit and 64-bit
-----------------
On x86/x64, Hyper-V supports 32-bit and 64-bit guests, and Linux
will build and run in either version. While the 32-bit version is
expected to work, it is used rarely and may suffer from undetected
regressions.
On arm64, Hyper-V supports only 64-bit guests.
Endian-ness
-----------
All communication between Hyper-V and guest VMs uses Little-Endian
format on both x86/x64 and arm64. Big-endian format on arm64 is not
supported by Hyper-V, and Linux code does not use endian-ness macros
when accessing data shared with Hyper-V.
Versioning
----------
Current Linux kernels operate correctly with older versions of
Hyper-V back to Windows Server 2012 Hyper-V. Support for running
on the original Hyper-V release in Windows Server 2008/2008 R2
has been removed.
A Linux guest on Hyper-V outputs in dmesg the version of Hyper-V
it is running on. This version is in the form of a Windows build
number and is for display purposes only. Linux code does not
test this version number at runtime to determine available features
and functionality. Hyper-V indicates feature/function availability
via flags in synthetic MSRs that Hyper-V provides to the guest,
and the guest code tests these flags.
VMBus has its own protocol version that is negotiated during the
initial VMBus connection from the guest to Hyper-V. This version
number is also output to dmesg during boot. This version number
is checked in a few places in the code to determine if specific
functionality is present.
Furthermore, each synthetic device on VMBus also has a protocol
version that is separate from the VMBus protocol version. Device
drivers for these synthetic devices typically negotiate the device
protocol version, and may test that protocol version to determine
if specific device functionality is present.
Code Packaging
--------------
Hyper-V related code appears in the Linux kernel code tree in three
main areas:
1. drivers/hv
2. arch/x86/hyperv and arch/arm64/hyperv
3. individual device driver areas such as drivers/scsi, drivers/net,
drivers/clocksource, etc.
A few miscellaneous files appear elsewhere. See the full list under
"Hyper-V/Azure CORE AND DRIVERS" and "DRM DRIVER FOR HYPERV
SYNTHETIC VIDEO DEVICE" in the MAINTAINERS file.
The code in #1 and #2 is built only when CONFIG_HYPERV is set.
Similarly, the code for most Hyper-V related drivers is built only
when CONFIG_HYPERV is set.
Most Hyper-V related code in #1 and #3 can be built as a module.
The architecture specific code in #2 must be built-in. Also,
drivers/hv/hv_common.c is low-level code that is common across
architectures and must be built-in.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Hyper-V 구성과 지원 architecture
1-18Linux kernel에는 Microsoft Hyper-V에서 fully enlightened guest로 실행하기 위한 여러 코드가 있습니다. Hyper-V는 주로 bare-metal hypervisor와 parent partition에서 실행되는 VM management service로 구성되며 대략 KVM과 QEMU의 관계에 대응합니다.
Guest VM은 child partition에서 실행됩니다. 이 문서에서 `Hyper-V`라는 표현은 기능이 hypervisor와 VMM service 중 어디에 구현됐는지 구분하지 않고 둘을 함께 가리킵니다.
Hyper-V는 x86/x64와 arm64에서 실행되고 두 architecture 모두 Linux guest를 지원합니다. 별도 언급이 없으면 기능과 동작은 대체로 같습니다.
Parent partition의 management service와 child partition guest의 관계입니다.
.. SPDX-License-Identifier: GPL-2.0
Overview
========
The Linux kernel contains a variety of code for running as a fully
enlightened guest on Microsoft's Hyper-V hypervisor. Hyper-V
consists primarily of a bare-metal hypervisor plus a virtual machine
management service running in the parent partition (roughly
equivalent to KVM and QEMU, for example). Guest VMs run in child
partitions. In this documentation, references to Hyper-V usually
encompass both the hypervisor and the VMM service without making a
distinction about which functionality is provided by which
component.
Hyper-V runs on x86/x64 and arm64 architectures, and Linux guests
are supported on both. The functionality and behavior of Hyper-V is
generally the same on both architectures unless noted otherwise.
Linux guest와 Hyper-V의 네 통신 방식
19-60Linux guest는 implicit trap, explicit hypercall, synthetic register access, VMBus의 네 방식으로 Hyper-V와 통신합니다.
Implicit trap은 architecture가 정한 guest action이 Hyper-V로 trap되면 Hyper-V가 emulate한 뒤 guest로 control을 돌려주는 방식으로, 일반적으로 Linux kernel에는 보이지 않습니다.
Explicit hypercall은 Linux가 parameter와 함께 Hyper-V function을 직접 호출하는 방식입니다. Parameter는 processor register 또는 guest·Hyper-V shared memory로 전달합니다. x86/x64는 Hyper-V 전용 calling sequence, arm64는 ARM 표준 SMCCC sequence를 사용합니다.
Synthetic register는 x86/x64 guest에서 MSR처럼 보여 표준 MSR read·write mechanism으로 접근합니다. arm64에서는 synthetic register access에도 explicit hypercall이 필요합니다.
VMBus는 앞의 세 mechanism 위에 만든 고수준 message-passing interface입니다. Hyper-V host와 Linux guest가 shared memory와 여러 signaling mechanism으로 통신합니다.
앞의 세 방식은 Hyper-V Top Level Functional Specification(TLFS)에 설명되어 있습니다. TLFS는 일반 Hyper-V 기능, hypercall과 synthetic register를 자세히 다루지만 현재 x86/x64 기준입니다. VMBus 세부 명세는 공개 문서가 없어 이 문서의 개요와 실제 code로 파악해야 합니다.
Architecture 차이와 추상화 수준을 비교합니다.
Linux Guest Communication with Hyper-V
--------------------------------------
Linux guests communicate with Hyper-V in four different ways:
* Implicit traps: As defined by the x86/x64 or arm64 architecture,
some guest actions trap to Hyper-V. Hyper-V emulates the action and
returns control to the guest. This behavior is generally invisible
to the Linux kernel.
* Explicit hypercalls: Linux makes an explicit function call to
Hyper-V, passing parameters. Hyper-V performs the requested action
and returns control to the caller. Parameters are passed in
processor registers or in memory shared between the Linux guest and
Hyper-V. On x86/x64, hypercalls use a Hyper-V specific calling
sequence. On arm64, hypercalls use the ARM standard SMCCC calling
sequence.
* Synthetic register access: Hyper-V implements a variety of
synthetic registers. On x86/x64 these registers appear as MSRs in
the guest, and the Linux kernel can read or write these MSRs using
the normal mechanisms defined by the x86/x64 architecture. On
arm64, these synthetic registers must be accessed using explicit
hypercalls.
* VMBus: VMBus is a higher-level software construct that is built on
the other 3 mechanisms. It is a message passing interface between
the Hyper-V host and the Linux guest. It uses memory that is shared
between Hyper-V and the guest, along with various signaling
mechanisms.
The first three communication mechanisms are documented in the
`Hyper-V Top Level Functional Spec (TLFS)`_. The TLFS describes
general Hyper-V functionality and provides details on the hypercalls
and synthetic registers. The TLFS is currently written for the
x86/x64 architecture only.
.. _Hyper-V Top Level Functional Spec (TLFS): https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/tlfs
VMBus is not documented. This documentation provides a high-level
overview of VMBus and how it works, but the details can be discerned
only from the code.
Memory 공유 절차
61-84많은 Hyper-V·Linux 통신은 memory sharing을 기반으로 합니다. Linux가 표준 mechanism으로 guest physical memory를 할당하고 그 GPA(guest physical address)를 Hyper-V에 알려주는 것으로 시작합니다.
Shared area가 한 page면 단일 GPA로 충분합니다. 더 큰 영역은 guest physical address에서 contiguous일 필요가 없는 GPA list를 사용합니다. 단일 GPA를 synthetic register에 쓰거나 GPA·list를 VMBus message로 보내는 등 전달 방법은 용도마다 다릅니다.
Hyper-V는 GPA를 실제 physical memory address로 변환하고 자신이 접근할 virtual mapping을 만듭니다. Linux는 나중에 shared GPA를 0으로 설정하라고 알려 기존 sharing을 revoke할 수 있습니다.
할당부터 revoke까지의 기본 수명 주기입니다.
Sharing Memory
--------------
Many aspects are communication between Hyper-V and Linux are based
on sharing memory. Such sharing is generally accomplished as
follows:
* Linux allocates memory from its physical address space using
standard Linux mechanisms.
* Linux tells Hyper-V the guest physical address (GPA) of the
allocated memory. Many shared areas are kept to 1 page so that a
single GPA is sufficient. Larger shared areas require a list of
GPAs, which usually do not need to be contiguous in the guest
physical address space. How Hyper-V is told about the GPA or list
of GPAs varies. In some cases, a single GPA is written to a
synthetic register. In other cases, a GPA or list of GPAs is sent
in a VMBus message.
* Hyper-V translates the GPAs into "real" physical memory addresses,
and creates a virtual mapping that it can use to access the memory.
* Linux can later revoke sharing it has previously established by
telling Hyper-V to set the shared GPA to zero.
4-KByte Hyper-V page 규칙
85-95Hyper-V는 4 Kbyte page size로 동작합니다. Hyper-V에 전달하는 GPA는 page number 형태일 수 있으며 언제나 4-Kbyte 범위를 나타냅니다.
x86/x64 Linux guest page도 4 Kbyte이므로 guest page와 Hyper-V page가 1:1로 대응합니다. Arm64 guest는 4/16/64 Kbyte page를 지원하므로 16·64 Kbyte 구성을 쓸 때도 Hyper-V와는 반드시 4-Kbyte 단위로 통신해야 합니다.
`HV_HYP_PAGE_SIZE`와 관련 macro가 모든 구성에서 이 단위를 올바르게 유지합니다.
Hyper-V interface는 architecture와 무관하게 4 Kbyte입니다.
Hyper-V operates with a page size of 4 Kbytes. GPAs communicated to
Hyper-V may be in the form of page numbers, and always describe a
range of 4 Kbytes. Since the Linux guest page size on x86/x64 is
also 4 Kbytes, the mapping from guest page to Hyper-V page is 1-to-1.
On arm64, Hyper-V supports guests with 4/16/64 Kbyte pages as
defined by the arm64 architecture. If Linux is using 16 or 64
Kbyte pages, Linux code must be careful to communicate with Hyper-V
only in terms of 4 Kbyte pages. HV_HYP_PAGE_SIZE and related macros
are used in code that communicates with Hyper-V so that it works
correctly in all configurations.
Overlay page
96-110TLFS에 정의된 일부 shared page는 `overlay` page입니다. Linux가 guest memory를 할당하고 GPA를 알리는 시작은 일반 sharing과 같지만 Hyper-V가 그 physical page를 자신이 할당한 page로 대체합니다.
원래 guest physical page는 VM에서 접근할 수 없게 되지만 Linux는 자신이 할당했던 memory처럼 같은 주소를 정상 접근합니다. Sharing을 설정해 overlay를 넣는 순간 Linux가 보는 내용이 바뀌므로 이 동작을 관찰할 수 있습니다.
Linux가 sharing을 revoke하면 Hyper-V가 overlay page를 제거하고 Linux가 처음 할당한 guest page가 다시 보입니다.
동일 GPA에서 backing page가 교체됐다가 복원됩니다.
As described in the TLFS, a few memory pages shared between Hyper-V
and the Linux guest are "overlay" pages. With overlay pages, Linux
uses the usual approach of allocating guest memory and telling
Hyper-V the GPA of the allocated memory. But Hyper-V then replaces
that physical memory page with a page it has allocated, and the
original physical memory page is no longer accessible in the guest
VM. Linux may access the memory normally as if it were the memory
that it originally allocated. The "overlay" behavior is visible
only because the contents of the page (as seen by Linux) change at
the time that Linux originally establishes the sharing and the
overlay page is inserted. Similarly, the contents change if Linux
revokes the sharing, in which case Hyper-V removes the overlay page,
and the guest page originally allocated by Linux becomes visible
again.
kexec 전 shared memory 정리
111-122Linux가 kdump kernel이나 다른 kernel로 `kexec`하기 전에 Hyper-V와 공유한 memory를 모두 revoke해야 합니다. 새 kernel이 page를 다른 용도로 사용한 뒤 Hyper-V가 shared page를 수정하거나 overlay를 제거하면 새 kernel memory가 손상될 수 있습니다.
Hyper-V에는 guest의 모든 sharing을 한 번에 reset하는 operation이 없으므로 Linux가 `kexec` 전에 각각 revoke해야 합니다. 관련 함수는 `hv_kexec_handler()`와 `hv_crash_handler()`입니다.
Crash·panic path에는 아직 빈틈이 있습니다. 일부 shared page는 per-CPU synthetic register로 설정되며 panic path를 실행하는 CPU 외의 CPU가 등록한 page를 revoke할 mechanism이 없습니다.
Old kernel의 Hyper-V mapping이 새 kernel을 손상하지 않게 합니다.
Before Linux does a kexec to a kdump kernel or any other kernel,
memory shared with Hyper-V should be revoked. Hyper-V could modify
a shared page or remove an overlay page after the new kernel is
using the page for a different purpose, corrupting the new kernel.
Hyper-V does not provide a single "set everything" operation to
guest VMs, so Linux code must individually revoke all sharing before
doing kexec. See hv_kexec_handler() and hv_crash_handler(). But
the crash/panic path still has holes in cleanup because some shared
pages are set using per-CPU synthetic registers and there's no
mechanism to revoke the shared pages for CPUs other than the CPU
running the panic path.
CPU 관리
123-140Hyper-V는 실행 중인 VM에 CPU를 hot-add하거나 hot-remove하는 기능이 없습니다.
Windows Server 2019 Hyper-V와 이전 version은 실제 VM CPU보다 많은 CPU를 나타내는 ACPI table을 제공할 수 있습니다. Linux는 추가 CPU를 잠재적 hot-add CPU로 정상 보고하지만 Hyper-V가 실제로 추가하지는 않습니다.
Windows Server 2022 Hyper-V부터 ACPI table에는 실제 VM CPU만 나타나므로 Linux가 hot-add CPU를 별도로 보고하지 않습니다.
VMBus channel interrupt가 할당되지 않은 CPU는 표준 Linux mechanism으로 offline할 수 있습니다. CPU를 offline하려면 VMBus interrupt 절에 설명된 방식으로 channel interrupt를 다른 CPU에 재할당해야 합니다.
실제 hot-add와 Linux offline을 구분합니다.
CPU Management
--------------
Hyper-V does not have a ability to hot-add or hot-remove a CPU
from a running VM. However, Windows Server 2019 Hyper-V and
earlier versions may provide guests with ACPI tables that indicate
more CPUs than are actually present in the VM. As is normal, Linux
treats these additional CPUs as potential hot-add CPUs, and reports
them as such even though Hyper-V will never actually hot-add them.
Starting in Windows Server 2022 Hyper-V, the ACPI tables reflect
only the CPUs actually present in the VM, so Linux does not report
any hot-add CPUs.
A Linux guest CPU may be taken offline using the normal Linux
mechanisms, provided no VMBus channel interrupts are assigned to
the CPU. See the section on VMBus Interrupts for more details
on how VMBus channel interrupts can be re-assigned to permit
taking a CPU offline.
32-bit와 64-bit
141-149x86/x64에서 Hyper-V는 32-bit와 64-bit guest를 모두 지원하고 Linux도 두 형태로 build·실행됩니다. 32-bit version은 동작할 것으로 기대되지만 사용이 드물어 발견되지 않은 regression이 있을 수 있습니다.
Arm64 Hyper-V는 64-bit guest만 지원합니다.
32-bit and 64-bit
-----------------
On x86/x64, Hyper-V supports 32-bit and 64-bit guests, and Linux
will build and run in either version. While the 32-bit version is
expected to work, it is used rarely and may suffer from undetected
regressions.
On arm64, Hyper-V supports only 64-bit guests.
Endian 형식
150-156Hyper-V와 guest VM 사이의 모든 통신은 x86/x64와 arm64 모두 Little-Endian 형식을 사용합니다.
Hyper-V는 arm64 Big-Endian을 지원하지 않으므로 Linux code는 Hyper-V shared data에 접근할 때 endian 변환 macro를 사용하지 않습니다.
Endian-ness
-----------
All communication between Hyper-V and guest VMs uses Little-Endian
format on both x86/x64 and arm64. Big-endian format on arm64 is not
supported by Hyper-V, and Linux code does not use endian-ness macros
when accessing data shared with Hyper-V.
Versioning과 feature 탐색
157-183현재 Linux kernel은 Windows Server 2012 Hyper-V까지의 구 version에서 올바르게 동작합니다. Windows Server 2008/2008 R2의 최초 Hyper-V release 지원은 제거됐습니다.
Linux guest는 실행 중인 Hyper-V version을 Windows build number 형태로 dmesg에 출력하지만 표시용일 뿐 runtime feature 판단에는 사용하지 않습니다. Feature·function 지원 여부는 Hyper-V가 synthetic MSR flag로 제공하고 guest code가 이 flag를 검사합니다.
VMBus는 guest가 Hyper-V와 initial connection을 만들 때 별도 protocol version을 협상하며 boot dmesg에 출력합니다. Code 일부는 이 version으로 특정 기능의 존재를 판단합니다.
각 VMBus synthetic device도 VMBus protocol과 독립된 device protocol version을 가집니다. Device driver가 보통 이를 협상하고 세부 device 기능 지원 여부를 검사합니다.
표시용 host build와 기능 협상 version을 구분합니다.
Versioning
----------
Current Linux kernels operate correctly with older versions of
Hyper-V back to Windows Server 2012 Hyper-V. Support for running
on the original Hyper-V release in Windows Server 2008/2008 R2
has been removed.
A Linux guest on Hyper-V outputs in dmesg the version of Hyper-V
it is running on. This version is in the form of a Windows build
number and is for display purposes only. Linux code does not
test this version number at runtime to determine available features
and functionality. Hyper-V indicates feature/function availability
via flags in synthetic MSRs that Hyper-V provides to the guest,
and the guest code tests these flags.
VMBus has its own protocol version that is negotiated during the
initial VMBus connection from the guest to Hyper-V. This version
number is also output to dmesg during boot. This version number
is checked in a few places in the code to determine if specific
functionality is present.
Furthermore, each synthetic device on VMBus also has a protocol
version that is separate from the VMBus protocol version. Device
drivers for these synthetic devices typically negotiate the device
protocol version, and may test that protocol version to determine
if specific device functionality is present.
Kernel code 배치와 build 조건
184-207Hyper-V 관련 code는 주로 `drivers/hv`, `arch/x86/hyperv`와 `arch/arm64/hyperv`, 그리고 `drivers/scsi`, `drivers/net`, `drivers/clocksource` 같은 개별 device driver 영역에 있습니다.
그 밖의 파일은 `MAINTAINERS`의 `Hyper-V/Azure CORE AND DRIVERS`와 `DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE` 항목에서 전체 목록을 찾을 수 있습니다.
첫 두 영역과 대부분의 Hyper-V driver code는 `CONFIG_HYPERV`가 설정될 때만 build됩니다.
`drivers/hv`와 개별 driver 영역의 code 대부분은 module로 만들 수 있지만 architecture-specific code는 built-in이어야 합니다. Architecture 공통 low-level code인 `drivers/hv/hv_common.c`도 built-in이어야 합니다.
소스 위치와 module 가능 여부입니다.
Code Packaging
--------------
Hyper-V related code appears in the Linux kernel code tree in three
main areas:
1. drivers/hv
2. arch/x86/hyperv and arch/arm64/hyperv
3. individual device driver areas such as drivers/scsi, drivers/net,
drivers/clocksource, etc.
A few miscellaneous files appear elsewhere. See the full list under
"Hyper-V/Azure CORE AND DRIVERS" and "DRM DRIVER FOR HYPERV
SYNTHETIC VIDEO DEVICE" in the MAINTAINERS file.
The code in #1 and #2 is built only when CONFIG_HYPERV is set.
Similarly, the code for most Hyper-V related drivers is built only
when CONFIG_HYPERV is set.
Most Hyper-V related code in #1 and #3 can be built as a module.
The architecture specific code in #2 must be built-in. Also,
drivers/hv/hv_common.c is low-level code that is common across
architectures and must be built-in.
요약·해설
overview.rst:1-207Hyper-V Linux 지원은 trap·hypercall·synthetic register·VMBus라는 네 통신 층을 사용합니다. Shared memory는 GPA 등록과 revoke 수명 주기를 엄격히 지켜야 하며 arm64의 큰 Linux page도 Hyper-V에는 4-Kbyte 단위로 표현합니다. 기능 판정은 host build number보다 synthetic MSR, VMBus, device protocol 협상에 의존합니다.