linux.git/drivers/hv/connection.c, branch v5.5

Drivers: hv: vmbus: Remove dependencies on guest page size

2019-11-22T01:10:45+00:00

Hyper-V assumes page size to be 4K. This might not be the case for ARM64
architecture. Hence use hyper-v page size and page allocation function
to avoid conflicts between different host and guest page size on ARM64.

Signed-off-by: Himadri Pandya 
Reviewed-by: Michael Kelley 
Signed-off-by: Sasha Levin

drivers: hv: vmbus: Introduce latency testing

2019-11-22T01:10:44+00:00

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: Add module parameter to cap the VMBus version

2019-11-22T01:10:44+00:00

Currently, Linux guests negotiate the VMBus version with Hyper-V
and use the highest available VMBus version they can connect to.
This has some drawbacks: by using the highest available version,
certain code paths are never executed and can not be tested when
the guest runs on the newest host.

Add the module parameter "max_version", to upper-bound the VMBus
versions guests can negotiate.

Suggested-by: Dexuan Cui 
Signed-off-by: Andrea Parri 
Reviewed-by: Wei Liu 
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:43+00:00

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:43+00:00

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

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

2019-09-06T18:52:44+00:00

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: Suspend after cleaning up hv_sock and sub channels

2019-09-06T18:52:44+00:00

Before suspend, Linux must make sure all the hv_sock channels have been
properly cleaned up, because a hv_sock connection can not persist across
hibernation, and the user-space app must be properly notified of the
state change of the connection.

Before suspend, Linux also must make sure all the sub-channels have been
destroyed, i.e. the related channel structs of the sub-channels must be
properly removed, otherwise they would cause a conflict when the
sub-channels are recreated upon resume.

Add a counter to track such channels, and vmbus_bus_suspend() should wait
for the counter to drop to zero.

Signed-off-by: Dexuan Cui 
Reviewed-by: Michael Kelley 
Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation

2019-09-06T18:52:44+00:00

Before Linux enters hibernation, it sends the CHANNELMSG_UNLOAD message to
the host so all the offers are gone. After hibernation, Linux needs to
re-negotiate with the host using the same vmbus protocol version (which
was in use before hibernation), and ask the host to re-offer the vmbus
devices.

Signed-off-by: Dexuan Cui 
Reviewed-by: Michael Kelley 
Signed-off-by: Sasha Levin

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 320

2019-06-05T15:37:05+00:00

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms and conditions of the gnu general public license
  version 2 as published by the free software foundation this program
  is distributed in the hope it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details you should have received a copy of the gnu general
  public license along with this program if not write to the free
  software foundation inc 59 temple place suite 330 boston ma 02111
  1307 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 33 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Allison Randal 
Reviewed-by: Kate Stewart 
Reviewed-by: Alexios Zavras 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190530000435.254582722@linutronix.de
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-12-03T07:01:01+00:00

vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.

The above is also true for primary channels, if the related device
drivers use sync probing mode by default.

And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.

The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).

The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.

So actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.

Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: stable@vger.kernel.org
Cc: Stephen Hemminger 
Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Signed-off-by: Dexuan Cui 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman