kernel.git/drivers/hv/hyperv_vmbus.h, branch linux-4.4.y

hyperv/vmbus: include linux/bitops.h

2021-11-26T10:58:34Z

[ Upstream commit 8017c99680fa65e1e8d999df1583de476a187830 ] On arm64 randconfig builds, hyperv sometimes fails with this error: In file included from drivers/hv/hv_trace.c:3: In file included from drivers/hv/hyperv_vmbus.h:16: In file included from arch/arm64/include/asm/sync_bitops.h:5: arch/arm64/include/asm/bitops.h:11:2: error: only can be included directly In file included from include/asm-generic/bitops/hweight.h:5: include/asm-generic/bitops/arch_hweight.h:9:9: error: implicit declaration of function '__sw_hweight32' [-Werror,-Wimplicit-function-declaration] include/asm-generic/bitops/atomic.h:17:7: error: implicit declaration of function 'BIT_WORD' [-Werror,-Wimplicit-function-declaration] Include the correct header first. Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20211018131929.2260087-1-arnd@kernel.org Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

Drivers: hv: kvp: fix IP Failover

2018-10-20T07:52:38Z

commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc upstream. Hyper-V VMs can be replicated to another hosts and there is a feature to set different IP for replicas, it is called 'Failover TCP/IP'. When such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon as we finish negotiation procedure. The problem is that it can happen (and it actually happens) before userspace daemon connects and we reply with HV_E_FAIL to the message. As there are no repetitions we fail to set the requested IP. Solve the issue by postponing our reply to the negotiation message till userspace daemon is connected. We can't wait too long as there is a host-side timeout (cca. 75 seconds) and if we fail to reply in this time frame the whole KVP service will become inactive. The solution is not ideal - if it takes userspace daemon more than 60 seconds to connect IP Failover will still fail but I don't see a solution with our current separation between kernel and userspace parts. Other two modules (VSS and FCOPY) don't require such delay, leave them untouched. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Dexuan Cui Signed-off-by: Greg Kroah-Hartman

Drivers: hv: avoid vfree() on crash

2017-03-26T10:13:18Z

commit a9f61ca793becabdefab03b77568d6c6f8c1bc79 upstream. When we crash from NMI context (e.g. after NMI injection from host when 'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit kernel BUG at mm/vmalloc.c:1530! as vfree() is denied. While the issue could be solved with in_nmi() check instead I opted for skipping vfree on all sorts of crashes to reduce the amount of work which can cause consequent crashes. We don't really need to free anything on crash. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Cc: Sumit Semwal Signed-off-by: Greg Kroah-Hartman

Drivers: hv: utils: run polling callback always in interrupt context

2016-09-15T06:27:40Z

[ Upstream commit 3cace4a616108539e2730f8dc21a636474395e0f ] All channel interrupts are bound to specific VCPUs in the guest at the point channel is created. While currently, we invoke the polling function on the correct CPU (the CPU to which the channel is bound to) in some cases we may run the polling function in a non-interrupt context. This potentially can cause an issue as the polling function can be interrupted by the channel callback function. Fix the issue by running the polling function on the appropriate CPU at interrupt level. Additional details of the issue being addressed by this patch are given below: Currently hv_fcopy_onchannelcallback is called from interrupts and also via the ->write function of hv_utils. Since the used global variables to maintain state are not thread safe the state can get out of sync. This affects the variable state as well as the channel inbound buffer. As suggested by KY adjust hv_poll_channel to always run the given callback on the cpu which the channel is bound to. This avoids the need for locking because all the util services are single threaded and only one transaction is active at any given point in time. Additionally, remove the context variable, they will always be the same as recv_channel. Signed-off-by: Olaf Hering Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Drivers: hv: util: Increase the timeout for util services

2016-09-15T06:27:40Z

[ Upstream commit c0b200cfb0403740171c7527b3ac71d03f82947a ] Util services such as KVP and FCOPY need assistance from daemon's running in user space. Increase the timeout so we don't prematurely terminate the transaction in the kernel. Host sets up a 60 second timeout for all util driver transactions. The host will retry the transaction if it times out. Set the guest timeout at 30 seconds. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drivers/hv: share Hyper-V SynIC constants with userspace

2015-11-04T15:24:33Z

Moved Hyper-V synic contants from guest Hyper-V drivers private header into x86 arch uapi Hyper-V header. Added Hyper-V synic msr's flags into x86 arch uapi Hyper-V header. Signed-off-by: Andrey Smetanin Reviewed-by: Roman Kagan Signed-off-by: Denis V. Lunev CC: Vitaly Kuznetsov CC: "K. Y. Srinivasan" CC: Gleb Natapov CC: Paolo Bonzini Signed-off-by: Paolo Bonzini

Drivers: hv: vmbus: Implement a clocksource based on the TSC page

2015-08-05T18:44:29Z

The current Hyper-V clock source is based on the per-partition reference counter and this counter is being accessed via s synthetic MSR - HV_X64_MSR_TIME_REF_COUNT. Hyper-V has a more efficient way of computing the per-partition reference counter value that does not involve reading a synthetic MSR. We implement a time source based on this mechanism. Tested-by: Vivek Yadav Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Improve the CPU affiliation for channels

2015-08-05T18:41:31Z

The current code tracks the assigned CPUs within a NUMA node in the context of the primary channel. So, if we have a VM with a single NUMA node with 8 VCPUs, we may end up unevenly distributing the channel load. Fix the issue by tracking affiliations globally. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: fix typo in hv_port_info struct

2015-08-05T05:29:45Z

This fixes a typo: base_flag_bumber to base_flag_number Signed-off-by: Nik Nyby Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Implement the protocol for tearing down vmbus state

2015-05-24T19:18:24Z

Implement the protocol for tearing down the monitor state established with the host. Signed-off-by: K. Y. Srinivasan Tested-by: Vitaly Kuznetsov Signed-off-by: Greg Kroah-Hartman