2019-05-30 07:57:35 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2011-05-13 10:34:28 +08:00
|
|
|
/*
|
|
|
|
*
|
|
|
|
* Copyright (c) 2011, Microsoft Corporation.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Haiyang Zhang <haiyangz@microsoft.com>
|
|
|
|
* Hank Janssen <hjanssen@microsoft.com>
|
|
|
|
* K. Y. Srinivasan <kys@microsoft.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _HYPERV_VMBUS_H
|
|
|
|
#define _HYPERV_VMBUS_H
|
|
|
|
|
2011-05-13 10:34:33 +08:00
|
|
|
#include <linux/list.h>
|
2021-10-18 21:19:08 +08:00
|
|
|
#include <linux/bitops.h>
|
2011-05-13 10:34:33 +08:00
|
|
|
#include <asm/sync_bitops.h>
|
2018-03-20 22:02:05 +08:00
|
|
|
#include <asm/hyperv-tlfs.h>
|
2011-05-13 10:34:33 +08:00
|
|
|
#include <linux/atomic.h>
|
2011-10-05 03:29:52 +08:00
|
|
|
#include <linux/hyperv.h>
|
2017-02-12 14:02:19 +08:00
|
|
|
#include <linux/interrupt.h>
|
2011-05-13 10:34:33 +08:00
|
|
|
|
2017-10-30 03:21:00 +08:00
|
|
|
#include "hv_trace.h"
|
|
|
|
|
2015-12-15 08:01:32 +08:00
|
|
|
/*
|
|
|
|
* Timeout for services such as KVP and fcopy.
|
|
|
|
*/
|
|
|
|
#define HV_UTIL_TIMEOUT 30
|
|
|
|
|
2016-05-01 10:21:33 +08:00
|
|
|
/*
|
|
|
|
* Timeout for guest-host handshake for services.
|
|
|
|
*/
|
2016-11-07 05:14:06 +08:00
|
|
|
#define HV_UTIL_NEGO_TIMEOUT 55
|
2016-05-01 10:21:33 +08:00
|
|
|
|
2011-05-13 10:34:29 +08:00
|
|
|
|
|
|
|
/* Definitions for the monitored notification facility */
|
|
|
|
union hv_monitor_trigger_group {
|
|
|
|
u64 as_uint64;
|
|
|
|
struct {
|
|
|
|
u32 pending;
|
|
|
|
u32 armed;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
struct hv_monitor_parameter {
|
|
|
|
union hv_connection_id connectionid;
|
|
|
|
u16 flagnumber;
|
|
|
|
u16 rsvdz;
|
|
|
|
};
|
|
|
|
|
|
|
|
union hv_monitor_trigger_state {
|
|
|
|
u32 asu32;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u32 group_enable:4;
|
|
|
|
u32 rsvdz:28;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
/* struct hv_monitor_page Layout */
|
|
|
|
/* ------------------------------------------------------ */
|
|
|
|
/* | 0 | TriggerState (4 bytes) | Rsvd1 (4 bytes) | */
|
|
|
|
/* | 8 | TriggerGroup[0] | */
|
|
|
|
/* | 10 | TriggerGroup[1] | */
|
|
|
|
/* | 18 | TriggerGroup[2] | */
|
|
|
|
/* | 20 | TriggerGroup[3] | */
|
|
|
|
/* | 28 | Rsvd2[0] | */
|
|
|
|
/* | 30 | Rsvd2[1] | */
|
|
|
|
/* | 38 | Rsvd2[2] | */
|
|
|
|
/* | 40 | NextCheckTime[0][0] | NextCheckTime[0][1] | */
|
|
|
|
/* | ... | */
|
|
|
|
/* | 240 | Latency[0][0..3] | */
|
|
|
|
/* | 340 | Rsvz3[0] | */
|
|
|
|
/* | 440 | Parameter[0][0] | */
|
|
|
|
/* | 448 | Parameter[0][1] | */
|
|
|
|
/* | ... | */
|
|
|
|
/* | 840 | Rsvd4[0] | */
|
|
|
|
/* ------------------------------------------------------ */
|
|
|
|
struct hv_monitor_page {
|
|
|
|
union hv_monitor_trigger_state trigger_state;
|
|
|
|
u32 rsvdz1;
|
|
|
|
|
|
|
|
union hv_monitor_trigger_group trigger_group[4];
|
|
|
|
u64 rsvdz2[3];
|
|
|
|
|
|
|
|
s32 next_checktime[4][32];
|
|
|
|
|
|
|
|
u16 latency[4][32];
|
|
|
|
u64 rsvdz3[32];
|
|
|
|
|
|
|
|
struct hv_monitor_parameter parameter[4][32];
|
|
|
|
|
|
|
|
u8 rsvdz4[1984];
|
|
|
|
};
|
|
|
|
|
2017-01-20 02:51:59 +08:00
|
|
|
#define HV_HYPERCALL_PARAM_ALIGN sizeof(u64)
|
|
|
|
|
2011-05-13 10:34:29 +08:00
|
|
|
/* Definition of the hv_post_message hypercall input structure. */
|
|
|
|
struct hv_input_post_message {
|
|
|
|
union hv_connection_id connectionid;
|
|
|
|
u32 reserved;
|
2015-12-01 00:22:13 +08:00
|
|
|
u32 message_type;
|
2011-05-13 10:34:29 +08:00
|
|
|
u32 payload_size;
|
|
|
|
u64 payload[HV_MESSAGE_PAYLOAD_QWORD_COUNT];
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-05-13 10:34:30 +08:00
|
|
|
enum {
|
|
|
|
VMBUS_MESSAGE_CONNECTION_ID = 1,
|
Drivers: hv: vmbus: enable VMBus protocol version 5.0
With VMBus protocol 5.0, we're able to better support new features, e.g.
running two or more VMBus drivers simultaneously in a single VM -- note:
we can't simply load the current VMBus driver twice, instead, a secondary
VMBus driver must be implemented.
This patch adds the support for the new VMBus protocol, which is available
on new Windows hosts, by:
1) We still use SINT2 for compatibility;
2) We must use Connection ID 4 for the Initiate Contact Message, and for
subsequent messages, we must use the Message Connection ID field in
the host-returned VersionResponse Message.
Notes for developers of the secondary VMBus driver:
1) Must use VMBus protocol 5.0 as well;
2) Must use a different SINT number that is not in use.
3) Must use Connection ID 4 for the Initiate Contact Message, and for
subsequent messages, must use the Message Connection ID field in
the host-returned VersionResponse Message.
4) It's possible that the primary VMBus driver using protocol version 4.0
can work with a secondary VMBus driver using protocol version 5.0, but it's
recommended that both should use 5.0 for new Hyper-V features in the future.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-12 17:30:33 +08:00
|
|
|
VMBUS_MESSAGE_CONNECTION_ID_4 = 4,
|
2011-05-13 10:34:30 +08:00
|
|
|
VMBUS_MESSAGE_PORT_ID = 1,
|
|
|
|
VMBUS_EVENT_CONNECTION_ID = 2,
|
|
|
|
VMBUS_EVENT_PORT_ID = 2,
|
|
|
|
VMBUS_MONITOR_CONNECTION_ID = 3,
|
|
|
|
VMBUS_MONITOR_PORT_ID = 3,
|
|
|
|
VMBUS_MESSAGE_SINT = 2,
|
|
|
|
};
|
|
|
|
|
2017-02-12 14:02:19 +08:00
|
|
|
/*
|
|
|
|
* Per cpu state for channel handling
|
|
|
|
*/
|
|
|
|
struct hv_per_cpu_context {
|
|
|
|
void *synic_message_page;
|
|
|
|
void *synic_event_page;
|
|
|
|
/*
|
|
|
|
* buffer to post messages to the host.
|
|
|
|
*/
|
|
|
|
void *post_msg_page;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Starting with win8, we can take channel interrupts on any CPU;
|
|
|
|
* we will manage the tasklet that handles events messages on a per CPU
|
|
|
|
* basis.
|
|
|
|
*/
|
|
|
|
struct tasklet_struct msg_dpc;
|
|
|
|
};
|
|
|
|
|
2011-05-13 10:34:30 +08:00
|
|
|
struct hv_context {
|
|
|
|
/* We only support running on top of Hyper-V
|
2017-03-05 09:27:17 +08:00
|
|
|
* So at this point this really can only contain the Hyper-V ID
|
|
|
|
*/
|
2011-05-13 10:34:30 +08:00
|
|
|
u64 guestid;
|
|
|
|
|
2017-02-12 14:02:19 +08:00
|
|
|
struct hv_per_cpu_context __percpu *cpu_context;
|
|
|
|
|
2015-08-05 15:52:38 +08:00
|
|
|
/*
|
|
|
|
* To manage allocations in a NUMA node.
|
|
|
|
* Array indexed by numa node ID.
|
|
|
|
*/
|
|
|
|
struct cpumask *hv_numa_map;
|
2011-05-13 10:34:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
extern struct hv_context hv_context;
|
|
|
|
|
|
|
|
/* Hv Interface */
|
|
|
|
|
|
|
|
extern int hv_init(void);
|
|
|
|
|
2012-03-28 14:58:07 +08:00
|
|
|
extern int hv_post_message(union hv_connection_id connection_id,
|
2011-05-13 10:34:30 +08:00
|
|
|
enum hv_message_type message_type,
|
|
|
|
void *payload, size_t payload_size);
|
|
|
|
|
2013-06-19 11:28:10 +08:00
|
|
|
extern int hv_synic_alloc(void);
|
|
|
|
|
|
|
|
extern void hv_synic_free(void);
|
|
|
|
|
2019-09-06 07:01:15 +08:00
|
|
|
extern void hv_synic_enable_regs(unsigned int cpu);
|
2016-12-08 06:53:11 +08:00
|
|
|
extern int hv_synic_init(unsigned int cpu);
|
2011-05-13 10:34:30 +08:00
|
|
|
|
2019-09-06 07:01:15 +08:00
|
|
|
extern void hv_synic_disable_regs(unsigned int cpu);
|
2016-12-08 06:53:11 +08:00
|
|
|
extern int hv_synic_cleanup(unsigned int cpu);
|
2011-05-13 10:34:30 +08:00
|
|
|
|
2011-05-13 10:34:31 +08:00
|
|
|
/* Interface */
|
|
|
|
|
2019-03-15 04:05:15 +08:00
|
|
|
void hv_ringbuffer_pre_init(struct vmbus_channel *channel);
|
2011-05-13 10:34:31 +08:00
|
|
|
|
2016-09-02 20:58:20 +08:00
|
|
|
int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info,
|
2021-04-09 00:14:39 +08:00
|
|
|
struct page *pages, u32 pagecnt, u32 max_pkt_size);
|
2011-05-13 10:34:31 +08:00
|
|
|
|
|
|
|
void hv_ringbuffer_cleanup(struct hv_ring_buffer_info *ring_info);
|
|
|
|
|
2016-11-07 05:14:17 +08:00
|
|
|
int hv_ringbuffer_write(struct vmbus_channel *channel,
|
2020-11-09 18:04:00 +08:00
|
|
|
const struct kvec *kv_list, u32 kv_count,
|
|
|
|
u64 requestid);
|
2011-05-13 10:34:31 +08:00
|
|
|
|
2016-11-07 05:14:18 +08:00
|
|
|
int hv_ringbuffer_read(struct vmbus_channel *channel,
|
2015-12-15 11:02:01 +08:00
|
|
|
void *buffer, u32 buflen, u32 *buffer_actual_len,
|
2016-11-07 05:14:18 +08:00
|
|
|
u64 *requestid, bool raw);
|
2011-05-13 10:34:31 +08:00
|
|
|
|
2011-05-13 10:34:32 +08:00
|
|
|
/*
|
2020-12-06 18:48:50 +08:00
|
|
|
* The Maximum number of channels (16384) is determined by the size of the
|
2019-07-12 16:25:18 +08:00
|
|
|
* interrupt page, which is HV_HYP_PAGE_SIZE. 1/2 of HV_HYP_PAGE_SIZE is to
|
|
|
|
* send endpoint interrupts, and the other is to receive endpoint interrupts.
|
2011-05-13 10:34:32 +08:00
|
|
|
*/
|
2019-07-12 16:25:18 +08:00
|
|
|
#define MAX_NUM_CHANNELS ((HV_HYP_PAGE_SIZE >> 1) << 3)
|
2011-05-13 10:34:32 +08:00
|
|
|
|
|
|
|
/* The value here must be in multiple of 32 */
|
|
|
|
#define MAX_NUM_CHANNELS_SUPPORTED 256
|
|
|
|
|
2020-04-06 08:15:06 +08:00
|
|
|
#define MAX_CHANNEL_RELIDS \
|
|
|
|
max(MAX_NUM_CHANNELS_SUPPORTED, HV_EVENT_FLAGS_COUNT)
|
2011-05-13 10:34:32 +08:00
|
|
|
|
|
|
|
enum vmbus_connect_state {
|
|
|
|
DISCONNECTED,
|
|
|
|
CONNECTING,
|
|
|
|
CONNECTED,
|
|
|
|
DISCONNECTING
|
|
|
|
};
|
|
|
|
|
|
|
|
#define MAX_SIZE_CHANNEL_MESSAGE HV_MESSAGE_PAYLOAD_BYTE_COUNT
|
|
|
|
|
2020-04-06 08:15:04 +08:00
|
|
|
/*
|
|
|
|
* The CPU that Hyper-V will interrupt for VMBUS messages, such as
|
|
|
|
* CHANNELMSG_OFFERCHANNEL and CHANNELMSG_RESCIND_CHANNELOFFER.
|
|
|
|
*/
|
|
|
|
#define VMBUS_CONNECT_CPU 0
|
2017-05-01 07:21:18 +08:00
|
|
|
|
2020-04-06 08:15:04 +08:00
|
|
|
struct vmbus_connection {
|
Drivers: hv: vmbus: enable VMBus protocol version 5.0
With VMBus protocol 5.0, we're able to better support new features, e.g.
running two or more VMBus drivers simultaneously in a single VM -- note:
we can't simply load the current VMBus driver twice, instead, a secondary
VMBus driver must be implemented.
This patch adds the support for the new VMBus protocol, which is available
on new Windows hosts, by:
1) We still use SINT2 for compatibility;
2) We must use Connection ID 4 for the Initiate Contact Message, and for
subsequent messages, we must use the Message Connection ID field in
the host-returned VersionResponse Message.
Notes for developers of the secondary VMBus driver:
1) Must use VMBus protocol 5.0 as well;
2) Must use a different SINT number that is not in use.
3) Must use Connection ID 4 for the Initiate Contact Message, and for
subsequent messages, must use the Message Connection ID field in
the host-returned VersionResponse Message.
4) It's possible that the primary VMBus driver using protocol version 4.0
can work with a secondary VMBus driver using protocol version 5.0, but it's
recommended that both should use 5.0 for new Hyper-V features in the future.
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-12 17:30:33 +08:00
|
|
|
u32 msg_conn_id;
|
|
|
|
|
2017-05-01 07:21:18 +08:00
|
|
|
atomic_t offer_in_progress;
|
|
|
|
|
2011-05-13 10:34:32 +08:00
|
|
|
enum vmbus_connect_state conn_state;
|
|
|
|
|
|
|
|
atomic_t next_gpadl_handle;
|
|
|
|
|
2015-04-23 12:31:32 +08:00
|
|
|
struct completion unload_event;
|
2011-05-13 10:34:32 +08:00
|
|
|
/*
|
|
|
|
* Represents channel interrupts. Each bit position represents a
|
|
|
|
* channel. When a channel sends an interrupt via VMBUS, it finds its
|
|
|
|
* bit in the sendInterruptPage, set it and calls Hv to generate a port
|
|
|
|
* event. The other end receives the port event and parse the
|
|
|
|
* recvInterruptPage to see which bit is set
|
|
|
|
*/
|
|
|
|
void *int_page;
|
|
|
|
void *send_int_page;
|
|
|
|
void *recv_int_page;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 2 pages - 1st page for parent->child notification and 2nd
|
|
|
|
* is child->parent notification
|
|
|
|
*/
|
2013-09-14 02:32:55 +08:00
|
|
|
struct hv_monitor_page *monitor_pages[2];
|
2021-10-25 20:21:13 +08:00
|
|
|
void *monitor_pages_original[2];
|
|
|
|
phys_addr_t monitor_pages_pa[2];
|
2011-05-13 10:34:32 +08:00
|
|
|
struct list_head chn_msg_list;
|
|
|
|
spinlock_t channelmsg_lock;
|
|
|
|
|
|
|
|
/* List of channels */
|
|
|
|
struct list_head chn_list;
|
2015-12-15 08:01:51 +08:00
|
|
|
struct mutex channel_mutex;
|
2011-05-13 10:34:32 +08:00
|
|
|
|
2020-04-06 08:15:06 +08:00
|
|
|
/* Array of channels */
|
|
|
|
struct vmbus_channel **channels;
|
|
|
|
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
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 <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-03 08:54:35 +08:00
|
|
|
/*
|
|
|
|
* An offer message is handled first on the work_queue, and then
|
|
|
|
* is further handled on handle_primary_chan_wq or
|
|
|
|
* handle_sub_chan_wq.
|
|
|
|
*/
|
2011-05-13 10:34:32 +08:00
|
|
|
struct workqueue_struct *work_queue;
|
Drivers: hv: vmbus: Offload the handling of channels to two workqueues
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 <sthemmin@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-03 08:54:35 +08:00
|
|
|
struct workqueue_struct *handle_primary_chan_wq;
|
|
|
|
struct workqueue_struct *handle_sub_chan_wq;
|
2019-09-06 07:01:21 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The number of sub-channels and hv_sock channels that should be
|
|
|
|
* cleaned up upon suspend: sub-channels will be re-created upon
|
|
|
|
* resume, and hv_sock channels should not survive suspend.
|
|
|
|
*/
|
|
|
|
atomic_t nr_chan_close_on_suspend;
|
|
|
|
/*
|
|
|
|
* vmbus_bus_suspend() waits for "nr_chan_close_on_suspend" to
|
|
|
|
* drop to zero.
|
|
|
|
*/
|
|
|
|
struct completion ready_for_suspend_event;
|
2019-09-06 07:01:22 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The number of primary channels that should be "fixed up"
|
|
|
|
* upon resume: these channels are re-offered upon resume, and some
|
|
|
|
* fields of the channel offers (i.e. child_relid and connection_id)
|
|
|
|
* can change, so the old offermsg must be fixed up, before the resume
|
|
|
|
* callbacks of the VSC drivers start to further touch the channels.
|
|
|
|
*/
|
|
|
|
atomic_t nr_chan_fixup_on_resume;
|
|
|
|
/*
|
|
|
|
* vmbus_bus_resume() waits for "nr_chan_fixup_on_resume" to
|
|
|
|
* drop to zero.
|
|
|
|
*/
|
|
|
|
struct completion ready_for_resume_event;
|
2011-05-13 10:34:32 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
struct vmbus_msginfo {
|
|
|
|
/* Bookkeeping stuff */
|
|
|
|
struct list_head msglist_entry;
|
|
|
|
|
|
|
|
/* The message itself */
|
2020-03-20 05:32:26 +08:00
|
|
|
unsigned char msg[];
|
2011-05-13 10:34:32 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
extern struct vmbus_connection vmbus_connection;
|
|
|
|
|
2019-09-06 07:01:19 +08:00
|
|
|
int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version);
|
|
|
|
|
2017-02-06 08:20:31 +08:00
|
|
|
static inline void vmbus_send_interrupt(u32 relid)
|
|
|
|
{
|
|
|
|
sync_set_bit(relid, vmbus_connection.send_int_page);
|
|
|
|
}
|
|
|
|
|
2015-03-28 00:10:08 +08:00
|
|
|
enum vmbus_message_handler_type {
|
|
|
|
/* The related handler can sleep. */
|
|
|
|
VMHT_BLOCKING = 0,
|
|
|
|
|
|
|
|
/* The related handler must NOT sleep. */
|
|
|
|
VMHT_NON_BLOCKING = 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct vmbus_channel_message_table_entry {
|
|
|
|
enum vmbus_channel_message_type message_type;
|
|
|
|
enum vmbus_message_handler_type handler_type;
|
|
|
|
void (*message_handler)(struct vmbus_channel_message_header *msg);
|
2020-04-06 18:43:26 +08:00
|
|
|
u32 min_payload_len;
|
2015-03-28 00:10:08 +08:00
|
|
|
};
|
|
|
|
|
2017-03-05 09:27:16 +08:00
|
|
|
extern const struct vmbus_channel_message_table_entry
|
2015-03-28 00:10:08 +08:00
|
|
|
channel_message_table[CHANNELMSG_COUNT];
|
|
|
|
|
2016-02-27 07:13:17 +08:00
|
|
|
|
2011-05-13 10:34:32 +08:00
|
|
|
/* General vmbus interface */
|
|
|
|
|
2019-01-10 22:25:32 +08:00
|
|
|
struct hv_device *vmbus_device_create(const guid_t *type,
|
|
|
|
const guid_t *instance,
|
2014-06-03 23:38:15 +08:00
|
|
|
struct vmbus_channel *channel);
|
2011-05-13 10:34:32 +08:00
|
|
|
|
2011-09-08 22:24:13 +08:00
|
|
|
int vmbus_device_register(struct hv_device *child_device_obj);
|
2011-09-08 22:24:14 +08:00
|
|
|
void vmbus_device_unregister(struct hv_device *device_obj);
|
2017-09-22 11:58:49 +08:00
|
|
|
int vmbus_add_channel_kobj(struct hv_device *device_obj,
|
|
|
|
struct vmbus_channel *channel);
|
2011-05-13 10:34:32 +08:00
|
|
|
|
2019-03-19 12:04:01 +08:00
|
|
|
void vmbus_remove_channel_attr_group(struct vmbus_channel *channel);
|
|
|
|
|
2020-04-06 08:15:06 +08:00
|
|
|
void vmbus_channel_map_relid(struct vmbus_channel *channel);
|
|
|
|
void vmbus_channel_unmap_relid(struct vmbus_channel *channel);
|
|
|
|
|
2015-03-28 00:10:09 +08:00
|
|
|
struct vmbus_channel *relid2channel(u32 relid);
|
2011-05-13 10:34:32 +08:00
|
|
|
|
2011-12-13 01:29:17 +08:00
|
|
|
void vmbus_free_channels(void);
|
2011-05-13 10:34:32 +08:00
|
|
|
|
|
|
|
/* Connection interface */
|
|
|
|
|
|
|
|
int vmbus_connect(void);
|
2015-02-28 03:25:54 +08:00
|
|
|
void vmbus_disconnect(void);
|
2011-05-13 10:34:32 +08:00
|
|
|
|
2016-12-07 17:16:24 +08:00
|
|
|
int vmbus_post_msg(void *buffer, size_t buflen, bool can_sleep);
|
2011-05-13 10:34:32 +08:00
|
|
|
|
|
|
|
void vmbus_on_event(unsigned long data);
|
2016-02-27 07:13:21 +08:00
|
|
|
void vmbus_on_msg_dpc(unsigned long data);
|
2011-05-13 10:34:32 +08:00
|
|
|
|
2017-03-05 09:27:17 +08:00
|
|
|
int hv_kvp_init(struct hv_util_service *srv);
|
2015-04-12 09:07:39 +08:00
|
|
|
void hv_kvp_deinit(void);
|
2020-01-26 13:49:44 +08:00
|
|
|
int hv_kvp_pre_suspend(void);
|
|
|
|
int hv_kvp_pre_resume(void);
|
2017-03-05 09:27:17 +08:00
|
|
|
void hv_kvp_onchannelcallback(void *context);
|
2015-04-12 09:07:39 +08:00
|
|
|
|
2017-03-05 09:27:17 +08:00
|
|
|
int hv_vss_init(struct hv_util_service *srv);
|
2015-04-12 09:07:39 +08:00
|
|
|
void hv_vss_deinit(void);
|
2020-01-26 13:49:44 +08:00
|
|
|
int hv_vss_pre_suspend(void);
|
|
|
|
int hv_vss_pre_resume(void);
|
2017-03-05 09:27:17 +08:00
|
|
|
void hv_vss_onchannelcallback(void *context);
|
2015-04-12 09:07:39 +08:00
|
|
|
|
2017-03-05 09:27:17 +08:00
|
|
|
int hv_fcopy_init(struct hv_util_service *srv);
|
2014-02-17 03:34:30 +08:00
|
|
|
void hv_fcopy_deinit(void);
|
2020-01-26 13:49:44 +08:00
|
|
|
int hv_fcopy_pre_suspend(void);
|
|
|
|
int hv_fcopy_pre_resume(void);
|
2017-03-05 09:27:17 +08:00
|
|
|
void hv_fcopy_onchannelcallback(void *context);
|
2016-02-27 07:13:16 +08:00
|
|
|
void vmbus_initiate_unload(bool crash);
|
2014-02-17 03:34:30 +08:00
|
|
|
|
2015-04-12 09:07:41 +08:00
|
|
|
static inline void hv_poll_channel(struct vmbus_channel *channel,
|
|
|
|
void (*cb)(void *))
|
|
|
|
{
|
|
|
|
if (!channel)
|
|
|
|
return;
|
2020-04-06 08:15:08 +08:00
|
|
|
cb(channel);
|
2015-04-12 09:07:41 +08:00
|
|
|
}
|
2011-05-13 10:34:32 +08:00
|
|
|
|
2015-04-12 09:07:46 +08:00
|
|
|
enum hvutil_device_state {
|
|
|
|
HVUTIL_DEVICE_INIT = 0, /* driver is loaded, waiting for userspace */
|
|
|
|
HVUTIL_READY, /* userspace is registered */
|
|
|
|
HVUTIL_HOSTMSG_RECEIVED, /* message from the host was received */
|
|
|
|
HVUTIL_USERSPACE_REQ, /* request to userspace was sent */
|
|
|
|
HVUTIL_USERSPACE_RECV, /* reply from userspace was received */
|
|
|
|
HVUTIL_DEVICE_DYING, /* driver unload is in progress */
|
|
|
|
};
|
|
|
|
|
2019-10-04 05:01:49 +08:00
|
|
|
enum delay {
|
|
|
|
INTERRUPT_DELAY = 0,
|
|
|
|
MESSAGE_DELAY = 1,
|
|
|
|
};
|
|
|
|
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-23 01:19:01 +08:00
|
|
|
extern const struct vmbus_device vmbus_devs[];
|
|
|
|
|
|
|
|
static inline bool hv_is_perf_channel(struct vmbus_channel *channel)
|
|
|
|
{
|
|
|
|
return vmbus_devs[channel->device_id].perf_device;
|
|
|
|
}
|
|
|
|
|
2022-01-28 18:34:11 +08:00
|
|
|
static inline bool hv_is_allocated_cpu(unsigned int cpu)
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-23 01:19:01 +08:00
|
|
|
{
|
|
|
|
struct vmbus_channel *channel, *sc;
|
|
|
|
|
|
|
|
lockdep_assert_held(&vmbus_connection.channel_mutex);
|
|
|
|
/*
|
|
|
|
* List additions/deletions as well as updates of the target CPUs are
|
|
|
|
* protected by channel_mutex.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
|
|
|
|
if (!hv_is_perf_channel(channel))
|
|
|
|
continue;
|
|
|
|
if (channel->target_cpu == cpu)
|
|
|
|
return true;
|
|
|
|
list_for_each_entry(sc, &channel->sc_list, sc_list) {
|
|
|
|
if (sc->target_cpu == cpu)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2022-01-28 18:34:11 +08:00
|
|
|
static inline void hv_set_allocated_cpu(unsigned int cpu)
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-23 01:19:01 +08:00
|
|
|
{
|
|
|
|
cpumask_set_cpu(cpu, &hv_context.hv_numa_map[cpu_to_node(cpu)]);
|
|
|
|
}
|
|
|
|
|
2022-01-28 18:34:11 +08:00
|
|
|
static inline void hv_clear_allocated_cpu(unsigned int cpu)
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-23 01:19:01 +08:00
|
|
|
{
|
2022-01-28 18:34:11 +08:00
|
|
|
if (hv_is_allocated_cpu(cpu))
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-23 01:19:01 +08:00
|
|
|
return;
|
|
|
|
cpumask_clear_cpu(cpu, &hv_context.hv_numa_map[cpu_to_node(cpu)]);
|
|
|
|
}
|
|
|
|
|
2022-01-28 18:34:11 +08:00
|
|
|
static inline void hv_update_allocated_cpus(unsigned int old_cpu,
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-23 01:19:01 +08:00
|
|
|
unsigned int new_cpu)
|
|
|
|
{
|
2022-01-28 18:34:11 +08:00
|
|
|
hv_set_allocated_cpu(new_cpu);
|
|
|
|
hv_clear_allocated_cpu(old_cpu);
|
Drivers: hv: vmbus: Resolve more races involving init_vp_index()
init_vp_index() uses the (per-node) hv_numa_map[] masks to record the
CPUs allocated for channel interrupts at a given time, and distribute
the performance-critical channels across the available CPUs: in part.,
the mask of "candidate" target CPUs in a given NUMA node, for a newly
offered channel, is determined by XOR-ing the node's CPU mask and the
node's hv_numa_map. This operation/mechanism assumes that no offline
CPUs is set in the hv_numa_map mask, an assumption that does not hold
since such mask is currently not updated when a channel is removed or
assigned to a different CPU.
To address the issues described above, this adds hooks in the channel
removal path (hv_process_channel_removal()) and in target_cpu_store()
in order to clear, resp. to update, the hv_numa_map[] masks as needed.
This also adds a (missed) update of the masks in init_vp_index() (cf.,
e.g., the memory-allocation failure path in this function).
Like in the case of init_vp_index(), such hooks require to determine
if the given channel is performance critical. init_vp_index() does
this by parsing the channel's offer, it can not rely on the device
data structure (device_obj) to retrieve such information because the
device data structure has not been allocated/linked with the channel
by the time that init_vp_index() executes. A similar situation may
hold in hv_is_alloced_cpu() (defined below); the adopted approach is
to "cache" the device type of the channel, as computed by parsing the
channel's offer, in the channel structure itself.
Fixes: 7527810573436f ("Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type")
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20200522171901.204127-3-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-05-23 01:19:01 +08:00
|
|
|
}
|
|
|
|
|
2019-10-04 05:01:49 +08:00
|
|
|
#ifdef CONFIG_HYPERV_TESTING
|
|
|
|
|
|
|
|
int hv_debug_add_dev_dir(struct hv_device *dev);
|
|
|
|
void hv_debug_rm_dev_dir(struct hv_device *dev);
|
|
|
|
void hv_debug_rm_all_dir(void);
|
|
|
|
int hv_debug_init(void);
|
|
|
|
void hv_debug_delay_test(struct vmbus_channel *channel, enum delay delay_type);
|
|
|
|
|
|
|
|
#else /* CONFIG_HYPERV_TESTING */
|
|
|
|
|
|
|
|
static inline void hv_debug_rm_dev_dir(struct hv_device *dev) {};
|
|
|
|
static inline void hv_debug_rm_all_dir(void) {};
|
|
|
|
static inline void hv_debug_delay_test(struct vmbus_channel *channel,
|
|
|
|
enum delay delay_type) {};
|
|
|
|
static inline int hv_debug_init(void)
|
|
|
|
{
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int hv_debug_add_dev_dir(struct hv_device *dev)
|
|
|
|
{
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_HYPERV_TESTING */
|
|
|
|
|
2011-05-13 10:34:28 +08:00
|
|
|
#endif /* _HYPERV_VMBUS_H */
|