On 12/12/2024 3:17 PM, mhkelley58@xxxxxxxxx wrote:
From: Michael Kelley <mhklinux@xxxxxxxxxxx>
Add documentation on how hibernation works in a guest VM on Hyper-V.
Describe how VMBus devices and the VMBus itself are hibernated and
resumed, along with various limitations.
Signed-off-by: Michael Kelley <mhklinux@xxxxxxxxxxx>
---
Documentation/virt/hyperv/hibernation.rst | 312 ++++++++++++++++++++++
Documentation/virt/hyperv/index.rst | 1 +
2 files changed, 313 insertions(+)
create mode 100644 Documentation/virt/hyperv/hibernation.rst
diff --git a/Documentation/virt/hyperv/hibernation.rst b/Documentation/virt/hyperv/hibernation.rst
new file mode 100644
index 000000000000..9e177c1f5bae
--- /dev/null
+++ b/Documentation/virt/hyperv/hibernation.rst
@@ -0,0 +1,312 @@
+.. SPDX-License-Identifier: GPL-2.0
+
---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8
+Considerations for Guest VM Hibernation
+---------------------------------------
+Linux guests on Hyper-V can also be hibernated, in which case the
+hardware is the virtual hardware provided by Hyper-V to the guest VM.
+Only the targeted guest VM is hibernated, while other guest VMs and
+the underlying Hyper-V host continue to run normally. While the
+underlying Windows Hyper-V and physical hardware on which it is
+running might also be hibernated using hibernation functionality in
+the Windows host, host hibernation and its impact on guest VMs is not
+in scope for this documentation.
+
+Resuming a hibernated guest VM can be more challenging than with
+physical hardware because VMs make it very easy to change the hardware
+configuration between the hibernation and resume. Even when the resume
+is done on the same VM that hibernated, the memory size might be
+changed, or virtual NICs or SCSI controllers might be added or
+removed. Virtual PCI devices assigned to the VM might be added or
+removed. Most such changes cause the resume steps to fail, though
+adding a new virtual NIC, SCSI controller, or vPCI device should work.
+
Would it be useful mentioning the (likely lethal for the VM) risk
of copying the hibernated VM to another host (of the same arch) that has
another set of CPUID bits/features?
---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8
+Key-Value Pair (KVP) Pseudo-Device Anomalies
+--------------------------------------------
---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8
+Virtual PCI devices
+-------------------
+Virtual PCI devices are physical PCI devices that are mapped directly
---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8 ---->8
Appreciated documenting all the intricacies of the hibernation and
resume paths for various devices, an incredible read! Are there
any special considerations known to you for the hibernation of
the devices driven through the Hyper-V UIO?
+out-of-the-box by local Hyper-V and so requires custom scripting.
diff --git a/Documentation/virt/hyperv/index.rst b/Documentation/virt/hyperv/index.rst
index 79bc4080329e..c84c40fd61c9 100644
--- a/Documentation/virt/hyperv/index.rst
+++ b/Documentation/virt/hyperv/index.rst
@@ -11,4 +11,5 @@ Hyper-V Enlightenments
vmbus
clocks
vpci
+ hibernation
coco
Besides these two questions, LGTM.
--
Thank you,
Roman
