kernel/git/stable/linux.git/drivers/hv/connection.c, branch linux-3.15.y

Drivers: hv: vmbus: Fix a bug in the channel callback dispatch code

2014-07-17T23:23:14+00:00

commit affb1aff300ddee54df307812b38f166e8a865ef upstream. Starting with Win8, we have implemented several optimizations to improve the scalability and performance of the VMBUS transport between the Host and the Guest. Some of the non-performance critical services cannot leverage these optimization since they only read and process one message at a time. Make adjustments to the callback dispatch code to account for the way non-performance critical drivers handle reading of the channel. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

hv: use correct order when freeing monitor_pages

2014-06-26T19:17:35+00:00

commit a100d88df1e924e5c9678fabf054d1bae7ab74fb upstream. We try to free two pages when only one has been allocated. Cleanup path is unlikely, so I haven't found any trace that would fit, but I hope that free_pages_prepare() does catch it. Signed-off-by: Radim Krčmář Reviewed-by: Amos Kong Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Negotiate version 3.0 when running on ws2012r2 hosts

2014-04-16T21:14:07+00:00

Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS. This functionality is needed by kexec in Linux. To use this functionality we need to negotiate version 3.0 of the VMBUS protocol. Signed-off-by: K. Y. Srinivasan Cc: [3.9+] Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Don't timeout during the initial connection with host

2014-02-07T16:27:34+00:00

When the guest attempts to connect with the host when there may already be a connection with the host (as would be the case during the kdump/kexec path), it is difficult to guarantee timely response from the host. Starting with WS2012 R2, the host supports this ability to re-connect with the host (explicitly to support kexec). Prior to responding to the guest, the host needs to ensure that device states based on the previous connection to the host have been properly torn down. This may introduce unbounded delays. To deal with this issue, don't do a timed wait during the initial connect with the host. Signed-off-by: K. Y. Srinivasan Cc: Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Specify the target CPU that should receive notification

2014-02-07T16:27:34+00:00

During the initial VMBUS connect phase, starting with WS2012 R2, we should specify the VPCU in the guest that should receive the notification. Fix this issue. This fix is required to properly connect to the host in the kexeced kernel. Signed-off-by: K. Y. Srinivasan Cc: [3.9+] Signed-off-by: Greg Kroah-Hartman

Merge 3.12-rc3 into char-misc-next

2013-09-30T01:27:03+00:00

We need/want the mei fixes in here so we can apply other updates that are depending on them. Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Terminate vmbus version negotiation on timeout

2013-09-26T21:20:22+00:00

commit 666b9adc801ef012612c4e43e0f44b2cdc1979cf terminated vmbus version negotiation incorrectly. We need to terminate the version negotiation only if the current negotiation were to timeout. Signed-off-by: K. Y. Srinivasan Cc: Olaf Hering Signed-off-by: Greg Kroah-Hartman

hv: make "monitor_pages" a "real" pointer array

2013-09-26T16:01:16+00:00

monitor_pages was a void pointer, containing an unknown number of arrays that we just "knew" were a child and parent array of a specific size. Instead of that implicit knowledge, let's make them a real pointer, allowing us to have type safety, and a semblance of sane addressing schemes. Tested-by: "K. Y. Srinivasan" Cc: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Do not attempt to negoatiate a new version prematurely

2013-08-30T19:08:04+00:00

The current code would attempt to negotiate a different protocol version if the current negotiation timed out. This triggers an assert in the host (on debug builds). Avoid this by negotiating a newer version only if the host properly rejects the current version being negotiated. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Implement multi-channel support

2013-06-03T21:09:14+00:00

Starting with Win8, the host supports multiple sub-channels for a given device. As in the past, the initial channel offer specifies the device and is associated with both the type and the instance GUIDs. For performance critical devices, the host may support multiple sub-channels. The sub-channels share the same type and instance GUID as the primary channel. The number of sub-channels offerrred to the guest depends on the number of virtual CPUs assigned to the guest. The guest can request the creation of these sub-channels and once created and opened, the guest can distribute the traffic across all the channels (the primary and the sub-channels). A request sent on a sub-channel will have the response delivered on the same sub-channel. At channel (sub-channel) creation we bind the channel interrupt to a CPU and with this sub-channel support we will be able to spread the interrupt load of a given device across all available CPUs. Signed-off-by: K. Y. Srinivasan Reviewed-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman