From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34882C04AB4 for ; Thu, 16 May 2019 11:48:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 03F4220848 for ; Thu, 16 May 2019 11:48:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558007314; bh=0te2/MatERJ1D9RAWwRpgHkRIsAxhubHijqTPPdWFPk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=DvtrJDiyLcfmzFvXitxVTVflGGI61AUXQxjCmZ/dE8+y1t39qUWeWWToJ/e50kY/+ C3q/7IbX1iyezE1k6TI+HBej8V3i0d/rjrPTsKstCkuQZdRXVu9zOTK5ZQdwgFi8Xq XBAVN7U6F1nAh+Aq1kkUKalW0rf8WSK0FOaxLrnw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728621AbfEPLsd (ORCPT ); Thu, 16 May 2019 07:48:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:47956 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727497AbfEPLjz (ORCPT ); Thu, 16 May 2019 07:39:55 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BCB5720833; Thu, 16 May 2019 11:39:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558006794; bh=0te2/MatERJ1D9RAWwRpgHkRIsAxhubHijqTPPdWFPk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CCeWWz6x4tX2vvvDAwjjXQpMKee6aGf8pVyVGz1P4BJoIpZfm85km713YJopl2IZ4 Z5XN9X8kVUziujj3qVzGxA8Ji7UIJ9wZnAWCToIXsWvvLRdHOFCnjrcUDEj59tjUGS ouf8FiUmuUJG8+uVT+FAwGA0BvHXKzhiKzGhPMbk= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vitaly Kuznetsov , Paolo Bonzini , Sasha Levin , kvm@vger.kernel.org Subject: [PATCH AUTOSEL 5.0 17/34] x86: kvm: hyper-v: deal with buggy TLB flush requests from WS2012 Date: Thu, 16 May 2019 07:39:14 -0400 Message-Id: <20190516113932.8348-17-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190516113932.8348-1-sashal@kernel.org> References: <20190516113932.8348-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Vitaly Kuznetsov [ Upstream commit da66761c2d93a46270d69001abb5692717495a68 ] It was reported that with some special Multi Processor Group configuration, e.g: bcdedit.exe /set groupsize 1 bcdedit.exe /set maxgroup on bcdedit.exe /set groupaware on for a 16-vCPU guest WS2012 shows BSOD on boot when PV TLB flush mechanism is in use. Tracing kvm_hv_flush_tlb immediately reveals the issue: kvm_hv_flush_tlb: processor_mask 0x0 address_space 0x0 flags 0x2 The only flag set in this request is HV_FLUSH_ALL_VIRTUAL_ADDRESS_SPACES, however, processor_mask is 0x0 and no HV_FLUSH_ALL_PROCESSORS is specified. We don't flush anything and apparently it's not what Windows expects. TLFS doesn't say anything about such requests and newer Windows versions seem to be unaffected. This all feels like a WS2012 bug, which is, however, easy to workaround in KVM: let's flush everything when we see an empty flush request, over-flushing doesn't hurt. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin --- arch/x86/kvm/hyperv.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index 371c669696d70..610c0f1fbdd71 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -1371,7 +1371,16 @@ static u64 kvm_hv_flush_tlb(struct kvm_vcpu *current_vcpu, u64 ingpa, valid_bank_mask = BIT_ULL(0); sparse_banks[0] = flush.processor_mask; - all_cpus = flush.flags & HV_FLUSH_ALL_PROCESSORS; + + /* + * Work around possible WS2012 bug: it sends hypercalls + * with processor_mask = 0x0 and HV_FLUSH_ALL_PROCESSORS clear, + * while also expecting us to flush something and crashing if + * we don't. Let's treat processor_mask == 0 same as + * HV_FLUSH_ALL_PROCESSORS. + */ + all_cpus = (flush.flags & HV_FLUSH_ALL_PROCESSORS) || + flush.processor_mask == 0; } else { if (unlikely(kvm_read_guest(kvm, ingpa, &flush_ex, sizeof(flush_ex)))) -- 2.20.1