2019-05-30 02:57:35 +03:00
/* SPDX-License-Identifier: GPL-2.0-only */
2011-05-13 06:34:28 +04: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 06:34:33 +04:00
# include <linux/list.h>
2021-10-18 16:19:08 +03:00
# include <linux/bitops.h>
2011-05-13 06:34:33 +04:00
# include <asm/sync_bitops.h>
2018-03-20 17:02:05 +03:00
# include <asm/hyperv-tlfs.h>
2011-05-13 06:34:33 +04:00
# include <linux/atomic.h>
2011-10-04 23:29:52 +04:00
# include <linux/hyperv.h>
2017-02-12 09:02:19 +03:00
# include <linux/interrupt.h>
2011-05-13 06:34:33 +04:00
2017-10-29 22:21:00 +03:00
# include "hv_trace.h"
2015-12-15 03:01:32 +03:00
/*
* Timeout for services such as KVP and fcopy .
*/
# define HV_UTIL_TIMEOUT 30
2016-05-01 05:21:33 +03:00
/*
* Timeout for guest - host handshake for services .
*/
2016-11-07 00:14:06 +03:00
# define HV_UTIL_NEGO_TIMEOUT 55
2016-05-01 05:21:33 +03:00
2011-05-13 06:34:29 +04: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-19 21:51:59 +03:00
# define HV_HYPERCALL_PARAM_ALIGN sizeof(u64)
2011-05-13 06:34:29 +04:00
/* Definition of the hv_post_message hypercall input structure. */
struct hv_input_post_message {
union hv_connection_id connectionid ;
u32 reserved ;
2015-11-30 19:22:13 +03:00
u32 message_type ;
2011-05-13 06:34:29 +04:00
u32 payload_size ;
u64 payload [ HV_MESSAGE_PAYLOAD_QWORD_COUNT ] ;
} ;
2011-05-13 06:34:30 +04: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 12:30:33 +03:00
VMBUS_MESSAGE_CONNECTION_ID_4 = 4 ,
2011-05-13 06:34:30 +04: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 09:02:19 +03:00
/*
* Per cpu state for channel handling
*/
struct hv_per_cpu_context {
void * synic_message_page ;
void * synic_event_page ;
2023-08-24 11:07:09 +03:00
/*
* The page is only used in hv_post_message ( ) for a TDX VM ( with the
* paravisor ) to post a messages to Hyper - V : when such a VM calls
* HVCALL_POST_MESSAGE , it can ' t use the hyperv_pcpu_input_arg ( which
* is encrypted in such a VM ) as the hypercall input page , because
* the input page for HVCALL_POST_MESSAGE must be decrypted in such a
* VM , so post_msg_page ( which is decrypted in hv_synic_alloc ( ) ) is
* introduced for this purpose . See hyperv_init ( ) for more comments .
*/
void * post_msg_page ;
2017-02-12 09:02:19 +03:00
/*
* 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 06:34:30 +04:00
struct hv_context {
/* We only support running on top of Hyper-V
2017-03-05 04:27:17 +03:00
* So at this point this really can only contain the Hyper - V ID
*/
2011-05-13 06:34:30 +04:00
u64 guestid ;
2017-02-12 09:02:19 +03:00
struct hv_per_cpu_context __percpu * cpu_context ;
2015-08-05 10:52:38 +03:00
/*
* To manage allocations in a NUMA node .
* Array indexed by numa node ID .
*/
struct cpumask * hv_numa_map ;
2011-05-13 06:34:30 +04:00
} ;
extern struct hv_context hv_context ;
/* Hv Interface */
extern int hv_init ( void ) ;
2012-03-28 10:58:07 +04:00
extern int hv_post_message ( union hv_connection_id connection_id ,
2011-05-13 06:34:30 +04:00
enum hv_message_type message_type ,
void * payload , size_t payload_size ) ;
2013-06-19 07:28:10 +04:00
extern int hv_synic_alloc ( void ) ;
extern void hv_synic_free ( void ) ;
2019-09-06 02:01:15 +03:00
extern void hv_synic_enable_regs ( unsigned int cpu ) ;
2016-12-08 01:53:11 +03:00
extern int hv_synic_init ( unsigned int cpu ) ;
2011-05-13 06:34:30 +04:00
2019-09-06 02:01:15 +03:00
extern void hv_synic_disable_regs ( unsigned int cpu ) ;
2016-12-08 01:53:11 +03:00
extern int hv_synic_cleanup ( unsigned int cpu ) ;
2011-05-13 06:34:30 +04:00
2011-05-13 06:34:31 +04:00
/* Interface */
2019-03-14 23:05:15 +03:00
void hv_ringbuffer_pre_init ( struct vmbus_channel * channel ) ;
2011-05-13 06:34:31 +04:00
2016-09-02 15:58:20 +03:00
int hv_ringbuffer_init ( struct hv_ring_buffer_info * ring_info ,
2021-04-08 19:14:39 +03:00
struct page * pages , u32 pagecnt , u32 max_pkt_size ) ;
2011-05-13 06:34:31 +04:00
void hv_ringbuffer_cleanup ( struct hv_ring_buffer_info * ring_info ) ;
2016-11-07 00:14:17 +03:00
int hv_ringbuffer_write ( struct vmbus_channel * channel ,
2020-11-09 13:04:00 +03:00
const struct kvec * kv_list , u32 kv_count ,
2022-04-19 15:23:22 +03:00
u64 requestid , u64 * trans_id ) ;
2011-05-13 06:34:31 +04:00
2016-11-07 00:14:18 +03:00
int hv_ringbuffer_read ( struct vmbus_channel * channel ,
2015-12-15 06:02:01 +03:00
void * buffer , u32 buflen , u32 * buffer_actual_len ,
2016-11-07 00:14:18 +03:00
u64 * requestid , bool raw ) ;
2011-05-13 06:34:31 +04:00
2011-05-13 06:34:32 +04:00
/*
2020-12-06 13:48:50 +03:00
* The Maximum number of channels ( 16384 ) is determined by the size of the
2019-07-12 11:25:18 +03: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 06:34:32 +04:00
*/
2019-07-12 11:25:18 +03:00
# define MAX_NUM_CHANNELS ((HV_HYP_PAGE_SIZE >> 1) << 3)
2011-05-13 06:34:32 +04:00
/* The value here must be in multiple of 32 */
# define MAX_NUM_CHANNELS_SUPPORTED 256
2020-04-06 03:15:06 +03:00
# define MAX_CHANNEL_RELIDS \
max ( MAX_NUM_CHANNELS_SUPPORTED , HV_EVENT_FLAGS_COUNT )
2011-05-13 06:34:32 +04:00
enum vmbus_connect_state {
DISCONNECTED ,
CONNECTING ,
CONNECTED ,
DISCONNECTING
} ;
# define MAX_SIZE_CHANNEL_MESSAGE HV_MESSAGE_PAYLOAD_BYTE_COUNT
2020-04-06 03:15:04 +03: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 02:21:18 +03:00
2020-04-06 03:15:04 +03: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 12:30:33 +03:00
u32 msg_conn_id ;
2017-05-01 02:21:18 +03:00
atomic_t offer_in_progress ;
2011-05-13 06:34:32 +04:00
enum vmbus_connect_state conn_state ;
atomic_t next_gpadl_handle ;
2015-04-23 07:31:32 +03:00
struct completion unload_event ;
2011-05-13 06:34:32 +04: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 - 1 st page for parent - > child notification and 2 nd
* is child - > parent notification
*/
2013-09-13 22:32:55 +04:00
struct hv_monitor_page * monitor_pages [ 2 ] ;
2011-05-13 06:34:32 +04:00
struct list_head chn_msg_list ;
spinlock_t channelmsg_lock ;
/* List of channels */
struct list_head chn_list ;
2015-12-15 03:01:51 +03:00
struct mutex channel_mutex ;
2011-05-13 06:34:32 +04:00
2020-04-06 03:15:06 +03: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 03:54:35 +03: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 06:34:32 +04: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 03:54:35 +03:00
struct workqueue_struct * handle_primary_chan_wq ;
struct workqueue_struct * handle_sub_chan_wq ;
2022-07-11 07:11:47 +03:00
struct workqueue_struct * rescind_work_queue ;
/*
* On suspension of the vmbus , the accumulated offer messages
* must be dropped .
*/
bool ignore_any_offer_msg ;
2019-09-06 02:01:21 +03: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 02:01:22 +03: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 06:34:32 +04:00
} ;
struct vmbus_msginfo {
/* Bookkeeping stuff */
struct list_head msglist_entry ;
/* The message itself */
2020-03-20 00:32:26 +03:00
unsigned char msg [ ] ;
2011-05-13 06:34:32 +04:00
} ;
extern struct vmbus_connection vmbus_connection ;
2019-09-06 02:01:19 +03:00
int vmbus_negotiate_version ( struct vmbus_channel_msginfo * msginfo , u32 version ) ;
2017-02-06 03:20:31 +03:00
static inline void vmbus_send_interrupt ( u32 relid )
{
sync_set_bit ( relid , vmbus_connection . send_int_page ) ;
}
2015-03-27 19:10:08 +03: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 13:43:26 +03:00
u32 min_payload_len ;
2015-03-27 19:10:08 +03:00
} ;
2017-03-05 04:27:16 +03:00
extern const struct vmbus_channel_message_table_entry
2015-03-27 19:10:08 +03:00
channel_message_table [ CHANNELMSG_COUNT ] ;
2016-02-27 02:13:17 +03:00
2011-05-13 06:34:32 +04:00
/* General vmbus interface */
2019-01-10 17:25:32 +03:00
struct hv_device * vmbus_device_create ( const guid_t * type ,
const guid_t * instance ,
2014-06-03 19:38:15 +04:00
struct vmbus_channel * channel ) ;
2011-05-13 06:34:32 +04:00
2011-09-08 18:24:13 +04:00
int vmbus_device_register ( struct hv_device * child_device_obj ) ;
2011-09-08 18:24:14 +04:00
void vmbus_device_unregister ( struct hv_device * device_obj ) ;
2017-09-22 06:58:49 +03:00
int vmbus_add_channel_kobj ( struct hv_device * device_obj ,
struct vmbus_channel * channel ) ;
2011-05-13 06:34:32 +04:00
2019-03-19 07:04:01 +03:00
void vmbus_remove_channel_attr_group ( struct vmbus_channel * channel ) ;
2020-04-06 03:15:06 +03:00
void vmbus_channel_map_relid ( struct vmbus_channel * channel ) ;
void vmbus_channel_unmap_relid ( struct vmbus_channel * channel ) ;
2015-03-27 19:10:09 +03:00
struct vmbus_channel * relid2channel ( u32 relid ) ;
2011-05-13 06:34:32 +04:00
2011-12-12 21:29:17 +04:00
void vmbus_free_channels ( void ) ;
2011-05-13 06:34:32 +04:00
/* Connection interface */
int vmbus_connect ( void ) ;
2015-02-27 22:25:54 +03:00
void vmbus_disconnect ( void ) ;
2011-05-13 06:34:32 +04:00
2016-12-07 12:16:24 +03:00
int vmbus_post_msg ( void * buffer , size_t buflen , bool can_sleep ) ;
2011-05-13 06:34:32 +04:00
void vmbus_on_event ( unsigned long data ) ;
2016-02-27 02:13:21 +03:00
void vmbus_on_msg_dpc ( unsigned long data ) ;
2011-05-13 06:34:32 +04:00
2017-03-05 04:27:17 +03:00
int hv_kvp_init ( struct hv_util_service * srv ) ;
2015-04-12 04:07:39 +03:00
void hv_kvp_deinit ( void ) ;
2020-01-26 08:49:44 +03:00
int hv_kvp_pre_suspend ( void ) ;
int hv_kvp_pre_resume ( void ) ;
2017-03-05 04:27:17 +03:00
void hv_kvp_onchannelcallback ( void * context ) ;
2015-04-12 04:07:39 +03:00
2017-03-05 04:27:17 +03:00
int hv_vss_init ( struct hv_util_service * srv ) ;
2015-04-12 04:07:39 +03:00
void hv_vss_deinit ( void ) ;
2020-01-26 08:49:44 +03:00
int hv_vss_pre_suspend ( void ) ;
int hv_vss_pre_resume ( void ) ;
2017-03-05 04:27:17 +03:00
void hv_vss_onchannelcallback ( void * context ) ;
2015-04-12 04:07:39 +03:00
2017-03-05 04:27:17 +03:00
int hv_fcopy_init ( struct hv_util_service * srv ) ;
2014-02-16 23:34:30 +04:00
void hv_fcopy_deinit ( void ) ;
2020-01-26 08:49:44 +03:00
int hv_fcopy_pre_suspend ( void ) ;
int hv_fcopy_pre_resume ( void ) ;
2017-03-05 04:27:17 +03:00
void hv_fcopy_onchannelcallback ( void * context ) ;
2016-02-27 02:13:16 +03:00
void vmbus_initiate_unload ( bool crash ) ;
2014-02-16 23:34:30 +04:00
2015-04-12 04:07:41 +03:00
static inline void hv_poll_channel ( struct vmbus_channel * channel ,
void ( * cb ) ( void * ) )
{
if ( ! channel )
return ;
2020-04-06 03:15:08 +03:00
cb ( channel ) ;
2015-04-12 04:07:41 +03:00
}
2011-05-13 06:34:32 +04:00
2015-04-12 04:07:46 +03: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 00:01:49 +03: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-22 20:19:01 +03: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 13:34:11 +03: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-22 20:19:01 +03: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 13:34:11 +03: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-22 20:19:01 +03:00
{
cpumask_set_cpu ( cpu , & hv_context . hv_numa_map [ cpu_to_node ( cpu ) ] ) ;
}
2022-01-28 13:34:11 +03: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-22 20:19:01 +03:00
{
2022-01-28 13:34:11 +03: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-22 20:19:01 +03:00
return ;
cpumask_clear_cpu ( cpu , & hv_context . hv_numa_map [ cpu_to_node ( cpu ) ] ) ;
}
2022-01-28 13:34:11 +03: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-22 20:19:01 +03:00
unsigned int new_cpu )
{
2022-01-28 13:34:11 +03: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-22 20:19:01 +03:00
}
2019-10-04 00:01:49 +03: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 06:34:28 +04:00
# endif /* _HYPERV_VMBUS_H */