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

Drivers: hv: vmbus: Replace the per-CPU channel lists with a global array of channels

2020-04-23T13:17:11+00:00

When Hyper-V sends an interrupt to the guest, the guest has to figure out which channel the interrupt is associated with. Hyper-V sets a bit in a memory page that is shared with the guest, indicating a particular "relid" that the interrupt is associated with. The current Linux code then uses a set of per-CPU linked lists to map a given "relid" to a pointer to a channel structure. This design introduces a synchronization problem if the CPU that Hyper-V will interrupt for a certain channel is changed. If the interrupt comes on the "old CPU" and the channel was already moved to the per-CPU list of the "new CPU", then the relid -> channel mapping will fail and the interrupt is dropped. Similarly, if the interrupt comes on the new CPU but the channel was not moved to the per-CPU list of the new CPU, then the mapping will fail and the interrupt is dropped. Relids are integers ranging from 0 to 2047. The mapping from relids to channel structures can be done by setting up an array with 2048 entries, each entry being a pointer to a channel structure (hence total size ~16K bytes, which is not a problem). The array is global, so there are no per-CPU linked lists to update. The array can be searched and updated by loading from/storing to the array at the specified index. With no per-CPU data structures, the above mentioned synchronization problem is avoided and the relid2channel() function gets simpler. Suggested-by: Michael Kelley Signed-off-by: Andrea Parri (Microsoft) Link: https://lore.kernel.org/r/20200406001514.19876-4-parri.andrea@gmail.com Reviewed-by: Michael Kelley Signed-off-by: Wei Liu

Drivers: hv: vmbus: Always handle the VMBus messages on CPU0

2020-04-23T13:17:11+00:00

A Linux guest have to pick a "connect CPU" to communicate with the Hyper-V host. This CPU can not be taken offline because Hyper-V does not provide a way to change that CPU assignment. Current code sets the connect CPU to whatever CPU ends up running the function vmbus_negotiate_version(), and this will generate problems if that CPU is taken offine. Establish CPU0 as the connect CPU, and add logics to prevents the connect CPU from being taken offline. We could pick some other CPU, and we could pick that "other CPU" dynamically if there was a reason to do so at some point in the future. But for now, #defining the connect CPU to 0 is the most straightforward and least complex solution. While on this, add inline comments explaining "why" offer and rescind messages should not be handled by a same serialized work queue. Suggested-by: Dexuan Cui Signed-off-by: Andrea Parri (Microsoft) Reviewed-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20200406001514.19876-2-parri.andrea@gmail.com Reviewed-by: Michael Kelley Signed-off-by: Wei Liu

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