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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z335xwWRTjyX0u6G@archie.me>
Date: Wed, 8 Jan 2025 11:06:31 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: mhklinux@...look.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
	decui@...rosoft.com, kys@...rosoft.com, corbet@....net,
	linux-kernel@...r.kernel.org, linux-hyperv@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH v2 1/1] Documentation: hyperv: Add overview of guest VM
 hibernation

On Tue, Jan 07, 2025 at 12:20:47PM -0800, mhkelley58@...il.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

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)