2019-05-29 16:57:35 -07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2011-05-12 19:34:28 -07: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-12 19:34:33 -07:00
|
|
|
#include <linux/list.h>
|
2021-10-18 15:19:08 +02:00
|
|
|
#include <linux/bitops.h>
|
2011-05-12 19:34:33 -07:00
|
|
|
#include <asm/sync_bitops.h>
|
|
|
|
|
#include <linux/atomic.h>
|
2011-10-04 12:29:52 -07:00
|
|
|
#include <linux/hyperv.h>
|
2017-02-11 23:02:19 -07:00
|
|
|
#include <linux/interrupt.h>
|
2024-11-25 15:24:43 -08:00
|
|
|
#include <hyperv/hvhdk.h>
|
2011-05-12 19:34:33 -07:00
|
|
|
|
2017-10-29 12:21:00 -07:00
|
|
|
#include "hv_trace.h"
|
|
|
|
|
|
2015-12-14 16:01:32 -08:00
|
|
|
/*
|
|
|
|
|
* Timeout for services such as KVP and fcopy.
|
|
|
|
|
*/
|
|
|
|
|
#define HV_UTIL_TIMEOUT 30
|
|
|
|
|
|
2016-04-30 19:21:33 -07:00
|
|
|
/*
|
|
|
|
|
* Timeout for guest-host handshake for services.
|
|
|
|
|
*/
|
2016-11-06 13:14:06 -08:00
|
|
|
#define HV_UTIL_NEGO_TIMEOUT 55
|
2016-04-30 19:21:33 -07:00
|
|
|
|
2011-05-12 19:34:29 -07: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 11:51:59 -07:00
|
|
|
#define HV_HYPERCALL_PARAM_ALIGN sizeof(u64)
|
|
|
|
|
|
2011-05-12 19:34:29 -07: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-12 19:34:29 -07:00
|
|
|
u32 payload_size;
|
|
|
|
|
u64 payload[HV_MESSAGE_PAYLOAD_QWORD_COUNT];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
2011-05-12 19:34:30 -07: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 02:30:33 -07:00
|
|
|
VMBUS_MESSAGE_CONNECTION_ID_4 = 4,
|
2011-05-12 19:34:30 -07: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-11 23:02:19 -07:00
|
|
|
/*
|
|
|
|
|
* Per cpu state for channel handling
|
|
|
|
|
*/
|
|
|
|
|
struct hv_per_cpu_context {
|
|
|
|
|
void *synic_message_page;
|
|
|
|
|
void *synic_event_page;
|
|
|
|
|
|
2023-08-24 01:07:09 -07: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-11 23:02:19 -07: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-12 19:34:30 -07:00
|
|
|
struct hv_context {
|
|
|
|
|
/* We only support running on top of Hyper-V
|
2017-03-04 18:27:17 -07:00
|
|
|
* So at this point this really can only contain the Hyper-V ID
|
|
|
|
|
*/
|
2011-05-12 19:34:30 -07:00
|
|
|
u64 guestid;
|
|
|
|
|
|
2017-02-11 23:02:19 -07:00
|
|
|
struct hv_per_cpu_context __percpu *cpu_context;
|
|
|
|
|
|
2015-08-05 00:52:38 -07:00
|
|
|
/*
|
|
|
|
|
* To manage allocations in a NUMA node.
|
|
|
|
|
* Array indexed by numa node ID.
|
|
|
|
|
*/
|
|
|
|
|
struct cpumask *hv_numa_map;
|
2011-05-12 19:34:30 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern struct hv_context hv_context;
|
|
|
|
|
|
|
|
|
|
/* Hv Interface */
|
|
|
|
|
|
|
|
|
|
extern int hv_init(void);
|
|
|
|
|
|
2012-03-28 09:58:07 +03:00
|
|
|
extern int hv_post_message(union hv_connection_id connection_id,
|
2011-05-12 19:34:30 -07: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-05 23:01:15 +00:00
|
|
|
extern void hv_synic_enable_regs(unsigned int cpu);
|
2016-12-07 14:53:11 -08:00
|
|
|
extern int hv_synic_init(unsigned int cpu);
|
2011-05-12 19:34:30 -07:00
|
|
|
|
2019-09-05 23:01:15 +00:00
|
|
|
extern void hv_synic_disable_regs(unsigned int cpu);
|
2016-12-07 14:53:11 -08:00
|
|
|
extern int hv_synic_cleanup(unsigned int cpu);
|
2011-05-12 19:34:30 -07:00
|
|
|
|
2011-05-12 19:34:31 -07:00
|
|
|
/* Interface */
|
|
|
|
|
|
2019-03-14 16:05:15 -04:00
|
|
|
void hv_ringbuffer_pre_init(struct vmbus_channel *channel);
|
2011-05-12 19:34:31 -07:00
|
|
|
|
2016-09-02 05:58:20 -07:00
|
|
|
int hv_ringbuffer_init(struct hv_ring_buffer_info *ring_info,
|
2021-04-08 18:14:39 +02:00
|
|
|
struct page *pages, u32 pagecnt, u32 max_pkt_size);
|
2011-05-12 19:34:31 -07:00
|
|
|
|
|
|
|
|
void hv_ringbuffer_cleanup(struct hv_ring_buffer_info *ring_info);
|
|
|
|
|
|
2016-11-06 13:14:17 -08:00
|
|
|
int hv_ringbuffer_write(struct vmbus_channel *channel,
|
2020-11-09 11:04:00 +01:00
|
|
|
const struct kvec *kv_list, u32 kv_count,
|
2022-04-19 14:23:22 +02:00
|
|
|
u64 requestid, u64 *trans_id);
|
2011-05-12 19:34:31 -07:00
|
|
|
|
2016-11-06 13:14:18 -08:00
|
|
|
int hv_ringbuffer_read(struct vmbus_channel *channel,
|
2015-12-14 19:02:01 -08:00
|
|
|
void *buffer, u32 buflen, u32 *buffer_actual_len,
|
2016-11-06 13:14:18 -08:00
|
|
|
u64 *requestid, bool raw);
|
2011-05-12 19:34:31 -07:00
|
|
|
|
2011-05-12 19:34:32 -07:00
|
|
|
/*
|
2020-12-06 11:48:50 +01:00
|
|
|
* The Maximum number of channels (16384) is determined by the size of the
|
2019-07-12 08:25:18 +00: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-12 19:34:32 -07:00
|
|
|
*/
|
2019-07-12 08:25:18 +00:00
|
|
|
#define MAX_NUM_CHANNELS ((HV_HYP_PAGE_SIZE >> 1) << 3)
|
2011-05-12 19:34:32 -07:00
|
|
|
|
|
|
|
|
/* The value here must be in multiple of 32 */
|
|
|
|
|
#define MAX_NUM_CHANNELS_SUPPORTED 256
|
|
|
|
|
|
2020-04-06 02:15:06 +02:00
|
|
|
#define MAX_CHANNEL_RELIDS \
|
|
|
|
|
max(MAX_NUM_CHANNELS_SUPPORTED, HV_EVENT_FLAGS_COUNT)
|
2011-05-12 19:34:32 -07:00
|
|
|
|
|
|
|
|
enum vmbus_connect_state {
|
|
|
|
|
DISCONNECTED,
|
|
|
|
|
CONNECTING,
|
|
|
|
|
CONNECTED,
|
|
|
|
|
DISCONNECTING
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define MAX_SIZE_CHANNEL_MESSAGE HV_MESSAGE_PAYLOAD_BYTE_COUNT
|
|
|
|
|
|
2020-04-06 02:15:04 +02: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-04-30 16:21:18 -07:00
|
|
|
|
2020-04-06 02:15:04 +02: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 02:30:33 -07:00
|
|
|
u32 msg_conn_id;
|
|
|
|
|
|
2017-04-30 16:21:18 -07:00
|
|
|
atomic_t offer_in_progress;
|
|
|
|
|
|
2011-05-12 19:34:32 -07:00
|
|
|
enum vmbus_connect_state conn_state;
|
|
|
|
|
|
|
|
|
|
atomic_t next_gpadl_handle;
|
|
|
|
|
|
2015-04-22 21:31:32 -07:00
|
|
|
struct completion unload_event;
|
2011-05-12 19:34:32 -07: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-13 11:32:55 -07:00
|
|
|
struct hv_monitor_page *monitor_pages[2];
|
2011-05-12 19:34:32 -07:00
|
|
|
struct list_head chn_msg_list;
|
|
|
|
|
spinlock_t channelmsg_lock;
|
|
|
|
|
|
|
|
|
|
/* List of channels */
|
|
|
|
|
struct list_head chn_list;
|
2015-12-14 16:01:51 -08:00
|
|
|
struct mutex channel_mutex;
|
2011-05-12 19:34:32 -07:00
|
|
|
|
2020-04-06 02:15:06 +02: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 00:54:35 +00: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-12 19:34:32 -07: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 00:54:35 +00:00
|
|
|
struct workqueue_struct *handle_primary_chan_wq;
|
|
|
|
|
struct workqueue_struct *handle_sub_chan_wq;
|
2022-07-10 21:11:47 -07: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-05 23:01:21 +00: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-05 23:01:22 +00:00
|
|
|
|
|
|
|
|
/*
|
2025-01-02 13:07:10 +00:00
|
|
|
* Completed once the host has offered all boot-time channels.
|
|
|
|
|
* Note that some channels may still be under process on a workqueue.
|
2019-09-05 23:01:22 +00:00
|
|
|
*/
|
2025-01-02 13:07:10 +00:00
|
|
|
struct completion all_offers_delivered_event;
|
2011-05-12 19:34:32 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
struct vmbus_msginfo {
|
|
|
|
|
/* Bookkeeping stuff */
|
|
|
|
|
struct list_head msglist_entry;
|
|
|
|
|
|
|
|
|
|
/* The message itself */
|
2020-03-19 16:32:26 -05:00
|
|
|
unsigned char msg[];
|
2011-05-12 19:34:32 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
extern struct vmbus_connection vmbus_connection;
|
|
|
|
|
|
2019-09-05 23:01:19 +00:00
|
|
|
int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version);
|
|
|
|
|
|
2017-02-05 17:20:31 -07:00
|
|
|
static inline void vmbus_send_interrupt(u32 relid)
|
|
|
|
|
{
|
|
|
|
|
sync_set_bit(relid, vmbus_connection.send_int_page);
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-27 09:10:08 -07: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 12:43:26 +02:00
|
|
|
u32 min_payload_len;
|
2015-03-27 09:10:08 -07:00
|
|
|
};
|
|
|
|
|
|
2017-03-04 18:27:16 -07:00
|
|
|
extern const struct vmbus_channel_message_table_entry
|
2015-03-27 09:10:08 -07:00
|
|
|
channel_message_table[CHANNELMSG_COUNT];
|
|
|
|
|
|
2016-02-26 15:13:17 -08:00
|
|
|
|
2011-05-12 19:34:32 -07:00
|
|
|
/* General vmbus interface */
|
|
|
|
|
|
2019-01-10 16:25:32 +02:00
|
|
|
struct hv_device *vmbus_device_create(const guid_t *type,
|
|
|
|
|
const guid_t *instance,
|
2014-06-03 08:38:15 -07:00
|
|
|
struct vmbus_channel *channel);
|
2011-05-12 19:34:32 -07:00
|
|
|
|
2011-09-08 07:24:13 -07:00
|
|
|
int vmbus_device_register(struct hv_device *child_device_obj);
|
2011-09-08 07:24:14 -07:00
|
|
|
void vmbus_device_unregister(struct hv_device *device_obj);
|
2017-09-21 20:58:49 -07:00
|
|
|
int vmbus_add_channel_kobj(struct hv_device *device_obj,
|
|
|
|
|
struct vmbus_channel *channel);
|
2011-05-12 19:34:32 -07:00
|
|
|
|
2019-03-19 00:04:01 -04:00
|
|
|
void vmbus_remove_channel_attr_group(struct vmbus_channel *channel);
|
|
|
|
|
|
2020-04-06 02:15:06 +02:00
|
|
|
void vmbus_channel_map_relid(struct vmbus_channel *channel);
|
|
|
|
|
void vmbus_channel_unmap_relid(struct vmbus_channel *channel);
|
|
|
|
|
|
2015-03-27 09:10:09 -07:00
|
|
|
struct vmbus_channel *relid2channel(u32 relid);
|
2011-05-12 19:34:32 -07:00
|
|
|
|
2011-12-12 09:29:17 -08:00
|
|
|
void vmbus_free_channels(void);
|
2011-05-12 19:34:32 -07:00
|
|
|
|
|
|
|
|
/* Connection interface */
|
|
|
|
|
|
|
|
|
|
int vmbus_connect(void);
|
2015-02-27 11:25:54 -08:00
|
|
|
void vmbus_disconnect(void);
|
2011-05-12 19:34:32 -07:00
|
|
|
|
2016-12-07 01:16:24 -08:00
|
|
|
int vmbus_post_msg(void *buffer, size_t buflen, bool can_sleep);
|
2011-05-12 19:34:32 -07:00
|
|
|
|
|
|
|
|
void vmbus_on_event(unsigned long data);
|
2016-02-26 15:13:21 -08:00
|
|
|
void vmbus_on_msg_dpc(unsigned long data);
|
2011-05-12 19:34:32 -07:00
|
|
|
|
2017-03-04 18:27:17 -07:00
|
|
|
int hv_kvp_init(struct hv_util_service *srv);
|
Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet
If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is
fully initialized, we can hit the panic below:
hv_utils: Registering HyperV Utility Driver
hv_vmbus: registering driver hv_utils
...
BUG: kernel NULL pointer dereference, address: 0000000000000000
CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1
RIP: 0010:hv_pkt_iter_first+0x12/0xd0
Call Trace:
...
vmbus_recvpacket
hv_kvp_onchannelcallback
vmbus_on_event
tasklet_action_common
tasklet_action
handle_softirqs
irq_exit_rcu
sysvec_hyperv_stimer0
</IRQ>
<TASK>
asm_sysvec_hyperv_stimer0
...
kvp_register_done
hvt_op_read
vfs_read
ksys_read
__x64_sys_read
This can happen because the KVP/VSS channel callback can be invoked
even before the channel is fully opened:
1) as soon as hv_kvp_init() -> hvutil_transport_init() creates
/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and
register itself to the driver by writing a message KVP_OP_REGISTER1 to the
file (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and
reading the file for the driver's response, which is handled by
hvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().
2) the problem with kvp_register_done() is that it can cause the
channel callback to be called even before the channel is fully opened,
and when the channel callback is starting to run, util_probe()->
vmbus_open() may have not initialized the ringbuffer yet, so the
callback can hit the panic of NULL pointer dereference.
To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in
__vmbus_open(), just before the first hv_ringbuffer_init(), and then we
unload and reload the driver hv_utils, and run the daemon manually within
the 10 seconds.
Fix the panic by reordering the steps in util_probe() so the char dev
entry used by the KVP or VSS daemon is not created until after
vmbus_open() has completed. This reordering prevents the race condition
from happening.
Reported-by: Dexuan Cui <decui@microsoft.com>
Fixes: e0fa3e5e7df6 ("Drivers: hv: utils: fix a race on userspace daemons registration")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20241106154247.2271-3-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20241106154247.2271-3-mhklinux@outlook.com>
2024-11-06 07:42:47 -08:00
|
|
|
int hv_kvp_init_transport(void);
|
2015-04-11 18:07:39 -07:00
|
|
|
void hv_kvp_deinit(void);
|
2020-01-25 21:49:44 -08:00
|
|
|
int hv_kvp_pre_suspend(void);
|
|
|
|
|
int hv_kvp_pre_resume(void);
|
2017-03-04 18:27:17 -07:00
|
|
|
void hv_kvp_onchannelcallback(void *context);
|
2015-04-11 18:07:39 -07:00
|
|
|
|
2017-03-04 18:27:17 -07:00
|
|
|
int hv_vss_init(struct hv_util_service *srv);
|
Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet
If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is
fully initialized, we can hit the panic below:
hv_utils: Registering HyperV Utility Driver
hv_vmbus: registering driver hv_utils
...
BUG: kernel NULL pointer dereference, address: 0000000000000000
CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1
RIP: 0010:hv_pkt_iter_first+0x12/0xd0
Call Trace:
...
vmbus_recvpacket
hv_kvp_onchannelcallback
vmbus_on_event
tasklet_action_common
tasklet_action
handle_softirqs
irq_exit_rcu
sysvec_hyperv_stimer0
</IRQ>
<TASK>
asm_sysvec_hyperv_stimer0
...
kvp_register_done
hvt_op_read
vfs_read
ksys_read
__x64_sys_read
This can happen because the KVP/VSS channel callback can be invoked
even before the channel is fully opened:
1) as soon as hv_kvp_init() -> hvutil_transport_init() creates
/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and
register itself to the driver by writing a message KVP_OP_REGISTER1 to the
file (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and
reading the file for the driver's response, which is handled by
hvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().
2) the problem with kvp_register_done() is that it can cause the
channel callback to be called even before the channel is fully opened,
and when the channel callback is starting to run, util_probe()->
vmbus_open() may have not initialized the ringbuffer yet, so the
callback can hit the panic of NULL pointer dereference.
To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in
__vmbus_open(), just before the first hv_ringbuffer_init(), and then we
unload and reload the driver hv_utils, and run the daemon manually within
the 10 seconds.
Fix the panic by reordering the steps in util_probe() so the char dev
entry used by the KVP or VSS daemon is not created until after
vmbus_open() has completed. This reordering prevents the race condition
from happening.
Reported-by: Dexuan Cui <decui@microsoft.com>
Fixes: e0fa3e5e7df6 ("Drivers: hv: utils: fix a race on userspace daemons registration")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Link: https://lore.kernel.org/r/20241106154247.2271-3-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20241106154247.2271-3-mhklinux@outlook.com>
2024-11-06 07:42:47 -08:00
|
|
|
int hv_vss_init_transport(void);
|
2015-04-11 18:07:39 -07:00
|
|
|
void hv_vss_deinit(void);
|
2020-01-25 21:49:44 -08:00
|
|
|
int hv_vss_pre_suspend(void);
|
|
|
|
|
int hv_vss_pre_resume(void);
|
2017-03-04 18:27:17 -07:00
|
|
|
void hv_vss_onchannelcallback(void *context);
|
2016-02-26 15:13:16 -08:00
|
|
|
void vmbus_initiate_unload(bool crash);
|
2014-02-16 11:34:30 -08:00
|
|
|
|
2015-04-11 18:07:41 -07:00
|
|
|
static inline void hv_poll_channel(struct vmbus_channel *channel,
|
|
|
|
|
void (*cb)(void *))
|
|
|
|
|
{
|
|
|
|
|
if (!channel)
|
|
|
|
|
return;
|
2020-04-06 02:15:08 +02:00
|
|
|
cb(channel);
|
2015-04-11 18:07:41 -07:00
|
|
|
}
|
2011-05-12 19:34:32 -07:00
|
|
|
|
2015-04-11 18:07:46 -07: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-03 17:01:49 -04: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 19:19:01 +02: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;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-30 01:51:57 -07:00
|
|
|
static inline size_t hv_dev_ring_size(struct vmbus_channel *channel)
|
|
|
|
|
{
|
|
|
|
|
return vmbus_devs[channel->device_id].pref_ring_size;
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-28 11:34:11 +01: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 19:19:01 +02: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 11:34:11 +01: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 19:19:01 +02:00
|
|
|
{
|
|
|
|
|
cpumask_set_cpu(cpu, &hv_context.hv_numa_map[cpu_to_node(cpu)]);
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-28 11:34:11 +01: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 19:19:01 +02:00
|
|
|
{
|
2022-01-28 11:34:11 +01: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 19:19:01 +02:00
|
|
|
return;
|
|
|
|
|
cpumask_clear_cpu(cpu, &hv_context.hv_numa_map[cpu_to_node(cpu)]);
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-28 11:34:11 +01: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 19:19:01 +02:00
|
|
|
unsigned int new_cpu)
|
|
|
|
|
{
|
2022-01-28 11:34:11 +01: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 19:19:01 +02:00
|
|
|
}
|
|
|
|
|
|
2019-10-03 17:01:49 -04: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 */
|
|
|
|
|
|
uio_hv_generic: Fix sysfs creation path for ring buffer
On regular bootup, devices get registered to VMBus first, so when
uio_hv_generic driver for a particular device type is probed,
the device is already initialized and added, so sysfs creation in
hv_uio_probe() works fine. However, when the device is removed
and brought back, the channel gets rescinded and the device again gets
registered to VMBus. However this time, the uio_hv_generic driver is
already registered to probe for that device and in this case sysfs
creation is tried before the device's kobject gets initialized
completely.
Fix this by moving the core logic of sysfs creation of ring buffer,
from uio_hv_generic to HyperV's VMBus driver, where the rest of the
sysfs attributes for the channels are defined. While doing that, make
use of attribute groups and macros, instead of creating sysfs
directly, to ensure better error handling and code flow.
Problematic path:
vmbus_process_offer (A new offer comes for the VMBus device)
vmbus_add_channel_work
vmbus_device_register
|-> device_register
| |...
| |-> hv_uio_probe
| |...
| |-> sysfs_create_bin_file (leads to a warning as
| the primary channel's kobject, which is used to
| create the sysfs file, is not yet initialized)
|-> kset_create_and_add
|-> vmbus_add_channel_kobj (initialization of the primary
channel's kobject happens later)
Above code flow is sequential and the warning is always reproducible in
this path.
Fixes: 9ab877a6ccf8 ("uio_hv_generic: make ring buffer attribute for primary channel")
Cc: stable@kernel.org
Suggested-by: Saurabh Sengar <ssengar@linux.microsoft.com>
Suggested-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
Link: https://lore.kernel.org/r/20250502074811.2022-2-namjain@linux.microsoft.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-02 13:18:10 +05:30
|
|
|
/* Create and remove sysfs entry for memory mapped ring buffers for a channel */
|
|
|
|
|
int hv_create_ring_sysfs(struct vmbus_channel *channel,
|
|
|
|
|
int (*hv_mmap_ring_buffer)(struct vmbus_channel *channel,
|
|
|
|
|
struct vm_area_struct *vma));
|
|
|
|
|
int hv_remove_ring_sysfs(struct vmbus_channel *channel);
|
|
|
|
|
|
2011-05-12 19:34:28 -07:00
|
|
|
#endif /* _HYPERV_VMBUS_H */
|