Thread (4 messages) 4 messages, 3 authors, 2025-01-08

Re: [PATCH v2 1/1] Documentation: hyperv: Add overview of guest VM hibernation

From: Bagas Sanjaya <hidden>
Date: 2025-01-08 04:06:35
Also in: linux-doc, lkml

On Tue, Jan 07, 2025 at 12:20:47PM -0800, mhkelley58@gmail.com wrote:
+VMBus devices are identified by class and instance GUID. (See section
+"VMBus device creation/deletion" in
+Documentation/virt/hyperv/vmbus.rst.) Upon resume from hibernation,
+the resume functions expect that the devices offered by Hyper-V have
+the same class/instance GUIDs as the devices present at the time of
+hibernation. Having the same class/instance GUIDs allows the offered
+devices to be matched to the primary VMBus channel data structures in
+the memory of the now resumed hibernation image. If any devices are
+offered that don't match primary VMBus channel data structures that
+already exist, they are processed normally as newly added devices. If
+primary VMBus channels that exist in the resumed hibernation image are
+not matched with a device offered in the resumed VM, the resume
+sequence waits for 10 seconds, then proceeds. But the unmatched device
+is likely to cause errors in the resumed VM.
Did you mean for example, conflicting synthetic NICs?
+The Linux ends of Hyper-V sockets are forced closed at the time of
+hibernation. The guest can't force closing the host end of the socket,
+but any host-side actions on the host end will produce an error.
Nothing can be done on host-side?
+Virtual PCI devices are physical PCI devices that are mapped directly
+into the VM's physical address space so the VM can interact directly
+the hardware. vPCI devices include those accessed via what Hyper-V
"... interact directly with the hardware."
+calls "Discrete Device Assignment" (DDA), as well as SR-IOV NIC
+Virtual Functions (VF) devices. See Documentation/virt/hyperv/vpci.rst.
+
<snipped>...
+SR-IOV NIC VFs similarly have a VMBus identity as well as a PCI
+identity, and overall are processed similarly to DDA devices. A
+difference is that VFs are not offered to the VM during initial boot
+of the VM. Instead, the VMBus synthetic NIC driver first starts
+operating and communicates to Hyper-V that it is prepared to accept a
+VF, and then the VF offer is made. However, if the VMBus connection is
+unloaded and then re-established without the VM being rebooted (as
+happens in Steps 3 and 5 in the Detailed Hibernation Sequence above,
+and similarly in the Detailed Resume Sequence), VFs are already part
                                                  "... that are already ..."
+of the VM and are offered to the re-established VMBus connection
+without intervention by the synthetic NIC driver.
Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help