path: root/sys/dev/hyperv/include/hyperv.h
diff options
authordelphij <>2016-01-13 08:22:53 +0000
committerdelphij <>2016-01-13 08:22:53 +0000
commite357bdb742b2696dcb81404917b6247f9e840232 (patch)
treea17aa39418224fbb66df1b84b7cd470ef967ef31 /sys/dev/hyperv/include/hyperv.h
parente72f532e157a4f8c7f6ce72a3f59d2a2d865662b (diff)
MFC r292861:
hyperv: vmbus: run non-blocking message handlers in vmbus_msg_swintr() We'll remove the per-channel control_work_queue because it can't properly do serialization of message handling, e.g., when there are 2 NIC devices, vmbus_channel_on_offer() -> hv_queue_work_item() has a race condition: for an SMP VM, vmbus_channel_process_offer() can run concurrently on different CPUs and if the second NIC's vmbus_channel_process_offer() -> hv_vmbus_child_device_register() runs first, the second NIC's name will be hn0 and the first NIC's name will be hn1! We can fix the race condition by removing the per-channel control_work_queue and run all the message handlers in the global hv_vmbus_g_connection.work_queue -- we'll do this in the next patch. With the coming next patch, we have to run the non-blocking handlers directly in the kernel thread vmbus_msg_swintr(), because the special handling of sub-channel: when a sub-channel (e.g., of the storvsc driver) is received and being handled in vmbus_channel_on_offer() running on the global hv_vmbus_g_connection.work_queue, vmbus_channel_process_offer() invokes channel->sc_creation_callback, i.e., storvsc_handle_sc_creation, and the callback will invoke hv_vmbus_channel_open() -> hv_vmbus_post_message and expect a further reply from the host, but the handling of the further messag can't be done because the current message's handling hasn't finished yet; as result, hv_vmbus_channel_open() -> sema_timedwait() will time out and th device can't work. Also renamed the handler type from hv_pfn_channel_msg_handler to vmbus_msg_handler: the 'pfn' and 'channel' in the old name make no sense. Submitted by: Dexuan Cui <decui microsoft com> Reviewed by: royger Differential Revision: MFC r292859: hyperv: vmbus: remove the per-channel control_work_queue Now vmbus_channel_on_offer() -> vmbus_channel_process_offer() can safely run on the global hv_vmbus_g_connection.work_queue now. We remove the per-channel control_work_queue to achieve the proper serialization of the message handling. I removed the bogus TODO in vmbus_channel_on_offer(): a vmbus offer can only come from the parent partition, i.e., the host. PR: kern/205156 Submitted by: Dexuan Cui <decui microsoft com> Reviewed by: Howard Su <howard0su gmail com>, delphij Differential Revision:
Diffstat (limited to 'sys/dev/hyperv/include/hyperv.h')
1 files changed, 0 insertions, 1 deletions
diff --git a/sys/dev/hyperv/include/hyperv.h b/sys/dev/hyperv/include/hyperv.h
index 6727503..b5600ba 100644
--- a/sys/dev/hyperv/include/hyperv.h
+++ b/sys/dev/hyperv/include/hyperv.h
@@ -759,7 +759,6 @@ typedef struct hv_vmbus_channel {
hv_vmbus_ring_buffer_info inbound;
struct mtx inbound_lock;
- hv_vmbus_handle control_work_queue;
hv_vmbus_pfn_channel_callback on_channel_callback;
void* channel_callback_context;
OpenPOWER on IntegriCloud