user/sven/linux.git/include/linux/hyperv.h, branch v5.6.10

hv_utils: Add the support of hibernation

2020-01-27T03:10:17Z

Add util_pre_suspend() and util_pre_resume() for some hv_utils devices (e.g. kvp/vss/fcopy), because they need special handling before util_suspend() calls vmbus_close(). For kvp, all the possible pending work items should be cancelled. For vss and fcopy, some extra clean-up needs to be done, i.e. fake a THAW message for hv_vss_daemon and fake a CANCEL_FCOPY message for hv_fcopy_daemon, otherwise when the VM resums back, the daemons can end up in an inconsistent state (i.e. the file systems are frozen but will never be thawed; the file transmitted via fcopy may not be complete). Note: there is an extra patch for the daemons: "Tools: hv: Reopen the devices if read() or write() returns errors", because the hv_utils driver can not guarantee the whole transaction finishes completely once util_suspend() starts to run (at this time, all the userspace processes are frozen). util_probe() disables channel->callback_event to avoid the race with the channel callback. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23)

2020-01-25T21:52:11Z

When a Linux hv_sock app tries to connect to a Service GUID on which no host app is listening, a recent host (RS3+) sends a CHANNELMSG_TL_CONNECT_RESULT (23) message to Linux and this triggers such a warning: unknown msgtype=23 WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:1031 vmbus_on_msg_dpc Actually Linux can safely ignore the message because the Linux app's connect() will time out in 2 seconds: see VSOCK_DEFAULT_CONNECT_TIMEOUT and vsock_stream_connect(). We don't bother to make use of the message because: 1) it's only supported on recent hosts; 2) a non-trivial effort is required to use the message in Linux, but the benefit is small. So, let's not see the warning by silently ignoring the message. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

drivers: hv: vmbus: Introduce latency testing

2019-11-22T01:10:44Z

Introduce user specified latency in the packet reception path By exposing the test parameters as part of the debugfs channel attributes. We will control the testing state via these attributes. Signed-off-by: Branden Bonaby Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Enable VMBus protocol versions 4.1, 5.1 and 5.2

2019-11-22T01:10:43Z

Hyper-V has added VMBus protocol versions 5.1 and 5.2 in recent release versions. Allow Linux guests to negotiate these new protocol versions on versions of Hyper-V that support them. While on this, also allow guests to negotiate the VMBus protocol version 4.1 (which was missing). Signed-off-by: Andrea Parri Reviewed-by: Wei Liu Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Introduce table of VMBus protocol versions

2019-11-22T01:10:43Z

The technique used to get the next VMBus version seems increasisly clumsy as the number of VMBus versions increases. Performance is not a concern since this is only done once during system boot; it's just that we'll end up with more lines of code than is really needed. As an alternative, introduce a table with the version numbers listed in order (from the most recent to the oldest). vmbus_connect() loops through the versions listed in the table until it gets an accepted connection or gets to the end of the table (invalid version). Suggested-by: Michael Kelley Signed-off-by: Andrea Parri Reviewed-by: Wei Liu Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

Merge tag 'hyperv-next-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux

2019-09-24T19:36:31Z

Pull Hyper-V updates from Sasha Levin: - first round of vmbus hibernation support (Dexuan Cui) - remove dependencies on PAGE_SIZE (Maya Nakamura) - move the hyper-v tools/ code into the tools build system (Andy Shevchenko) - hyper-v balloon cleanups (Dexuan Cui) * tag 'hyperv-next-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: Drivers: hv: vmbus: Resume after fixing up old primary channels Drivers: hv: vmbus: Suspend after cleaning up hv_sock and sub channels Drivers: hv: vmbus: Clean up hv_sock channels by force upon suspend Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation Drivers: hv: vmbus: Ignore the offers when resuming from hibernation Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for hibernation Drivers: hv: vmbus: Add a helper function is_sub_channel() Drivers: hv: vmbus: Suspend/resume the synic for hibernation Drivers: hv: vmbus: Break out synic enable and disable operations HID: hv: Remove dependencies on PAGE_SIZE for ring buffer Tools: hv: move to tools buildsystem hv_balloon: Reorganize the probe function hv_balloon: Use a static page for the balloon_up send buffer

Drivers: hv: vmbus: Resume after fixing up old primary channels

2019-09-06T18:52:44Z

When the host re-offers the primary channels upon resume, the host only guarantees the Instance GUID doesn't change, so vmbus_bus_suspend() should invalidate channel->offermsg.child_relid and figure out the number of primary channels that need to be fixed up upon resume. Upon resume, vmbus_onoffer() finds the old channel structs, and maps the new offers to the old channels, and fixes up the old structs, and finally the resume callbacks of the VSC drivers will re-open the channels. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for hibernation

2019-09-06T18:52:44Z

The high-level VSC drivers will implement device-specific callbacks. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Add a helper function is_sub_channel()

2019-09-06T18:52:44Z

The existing method of telling if a channel is sub-channel in vmbus_process_offer() is cumbersome. This new simple helper function is preferred in future. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

PCI: hv: Add a Hyper-V PCI interface driver for software backchannel interface

2019-08-22T07:25:12Z

This interface driver is a helper driver allows other drivers to have a common interface with the Hyper-V PCI frontend driver. Signed-off-by: Haiyang Zhang Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller