Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754578AbcL3Tka (ORCPT ); Fri, 30 Dec 2016 14:40:30 -0500 Received: from p3plsmtps2ded02.prod.phx3.secureserver.net ([208.109.80.59]:33118 "EHLO p3plsmtps2ded02.prod.phx3.secureserver.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754168AbcL3Tje (ORCPT ); Fri, 30 Dec 2016 14:39:34 -0500 x-originating-ip: 72.167.245.219 From: kys@exchange.microsoft.com To: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com, jasowang@redhat.com, leann.ogasawara@canonical.com, rkagan@virtuozzo.com, x86@kernel.org, tglx@linutronix.de, hpa@zytor.com Cc: "K. Y. Srinivasan" Subject: [PATCH 09/18] Drivers: hv: vmbus: Move the code to signal end of message Date: Fri, 30 Dec 2016 13:36:03 -0800 Message-Id: <1483133772-29776-9-git-send-email-kys@exchange.microsoft.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1483133772-29776-1-git-send-email-kys@exchange.microsoft.com> References: <1483133701-29738-1-git-send-email-kys@exchange.microsoft.com> <1483133772-29776-1-git-send-email-kys@exchange.microsoft.com> Reply-To: kys@microsoft.com X-CMAE-Envelope: MS4wfOoSKSMkiNKHwKJKtZna5EHQNMceJ1pwYHf6OtHkJTRo52FOzl/mxeQAvgsJa5CDzNodwjMqXHiZWTdCs+sShuSadM4yXgoEGRSstsHBXWR4c8E4Smu7 RZ91KHd21zBGBWPChn1PBHgzxIt3d+ovMT7t3X/sd39zQbgMH0LxKpVfg+/xk/7JDgd3lOnYi1PmjqDuS+mj2NwHCAg0FUVTkqbudpIEjjIUHJoprM7J7ny8 DHleVF1sLczBwXkvwNexi5mvkDfVFQRv4cuFPmQUD0lsbbDxNwKOdBcyPHNza2eHXDkpjD/RZY8fjIeEIPy8rgV58khICL4PDZzKcSE0oUkvC2Lp5cb5m6Sw PaVcApZf7v8A5vuEnlKWSl0KbOFixANiY/1m5yVkzQ398VWkyrXq7rnV5imXRTcqOwin3QQ1Q5qAoPzCj6uQm5LfYcVNLZ0Ruc6aYeYZK/6oY41rt2IgoIZh aSZINyD2iZYpghvPoGhKbAHi+/H+5OEcNt0fH4LZNBwRiWrfmPB0zThqZxgWLiO8VYX84Vnly80VxPEhTFIHjdCWU0OZUNfpb+4YXA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3963 Lines: 120 From: K. Y. Srinivasan As part of the effort to separate out architecture specific code, move the code for signaling end of message. Signed-off-by: K. Y. Srinivasan --- arch/x86/include/asm/mshyperv.h | 37 +++++++++++++++++++++++++++++++++++++ drivers/hv/channel_mgmt.c | 1 + drivers/hv/hyperv_vmbus.h | 35 ----------------------------------- 3 files changed, 38 insertions(+), 35 deletions(-) diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h index c843ef6..b57b470 100644 --- a/arch/x86/include/asm/mshyperv.h +++ b/arch/x86/include/asm/mshyperv.h @@ -99,6 +99,43 @@ static inline __u64 generate_guest_id(__u64 d_info1, __u64 kernel_version, return guest_id; } + +/* Free the message slot and signal end-of-message if required */ +static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type) +{ + /* + * On crash we're reading some other CPU's message page and we need + * to be careful: this other CPU may already had cleared the header + * and the host may already had delivered some other message there. + * In case we blindly write msg->header.message_type we're going + * to lose it. We can still lose a message of the same type but + * we count on the fact that there can only be one + * CHANNELMSG_UNLOAD_RESPONSE and we don't care about other messages + * on crash. + */ + if (cmpxchg(&msg->header.message_type, old_msg_type, + HVMSG_NONE) != old_msg_type) + return; + + /* + * Make sure the write to MessageType (ie set to + * HVMSG_NONE) happens before we read the + * MessagePending and EOMing. Otherwise, the EOMing + * will not deliver any more messages since there is + * no empty slot + */ + mb(); + + if (msg->header.message_flags.msg_pending) { + /* + * This will cause message queue rescan to + * possibly deliver another msg from the + * hypervisor + */ + wrmsrl(HV_X64_MSR_EOM, 0); + } +} + void hyperv_callback_vector(void); #ifdef CONFIG_TRACING #define trace_hyperv_callback_vector hyperv_callback_vector diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index 0af7e39..49d77be 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -31,6 +31,7 @@ #include #include #include +#include #include "hyperv_vmbus.h" diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h index 59eb28c..e9f5d2c 100644 --- a/drivers/hv/hyperv_vmbus.h +++ b/drivers/hv/hyperv_vmbus.h @@ -521,41 +521,6 @@ struct vmbus_channel_message_table_entry { extern struct vmbus_channel_message_table_entry channel_message_table[CHANNELMSG_COUNT]; -/* Free the message slot and signal end-of-message if required */ -static inline void vmbus_signal_eom(struct hv_message *msg, u32 old_msg_type) -{ - /* - * On crash we're reading some other CPU's message page and we need - * to be careful: this other CPU may already had cleared the header - * and the host may already had delivered some other message there. - * In case we blindly write msg->header.message_type we're going - * to lose it. We can still lose a message of the same type but - * we count on the fact that there can only be one - * CHANNELMSG_UNLOAD_RESPONSE and we don't care about other messages - * on crash. - */ - if (cmpxchg(&msg->header.message_type, old_msg_type, - HVMSG_NONE) != old_msg_type) - return; - - /* - * Make sure the write to MessageType (ie set to - * HVMSG_NONE) happens before we read the - * MessagePending and EOMing. Otherwise, the EOMing - * will not deliver any more messages since there is - * no empty slot - */ - mb(); - - if (msg->header.message_flags.msg_pending) { - /* - * This will cause message queue rescan to - * possibly deliver another msg from the - * hypervisor - */ - wrmsrl(HV_X64_MSR_EOM, 0); - } -} /* General vmbus interface */ -- 1.7.4.1