Received: by 10.192.165.148 with SMTP id m20csp563651imm; Wed, 25 Apr 2018 04:20:08 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/dhGwpU7v9NnjdhXIAFkj8jStmIbH+9715lD9u6Lh96aFUuUXVZVtOo3jNIx54gmU767aD X-Received: by 10.98.33.28 with SMTP id h28mr26947729pfh.249.1524655208163; Wed, 25 Apr 2018 04:20:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524655208; cv=none; d=google.com; s=arc-20160816; b=VEOYLtKrSl/mJtHcepRX9j1KQwZa4g30zB6QMNfS8NMAwt9jYH16XgW66PZO+hpDj3 YvtD1Q86XVrKEbi9b2zHttcgvAt3/3uLMvsnYJepk6W42olsSGXbFDU2g24Omw4jBwsm UR6fcjfGwiYTBQqBWPwwEGs/HSOD+msyx5/QF39IKwW+5oT1H0FzE8Od9tmsC08nXPes Ef3CUQXP8rst18xGQijp63GFavKoD2WcoH4zQXV3NW4ILfI5V+1r1ce99sGni15VlVUQ QgervVUCQyxWXuAGq6HoURLQ0caXBzNzYS2fLDMb7vApsXpNANf+PTvpUDgcpGpoOouV IhMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=QDDFxpDa6Qc0gfbFbhjHXJJsxKHEH9NBm4jhz1Vudmw=; b=zBZtL54oGn+qYM4j4Ay41CH1pI+LWtOE6XXXt2E6Rq5PwQJC3Msn98KhR/CDmuh7r8 Qor0lnuTCIIbqbF+L2QFWMVneU2RGsTiDQx2fWjjPg8p0CC3Ro4Srp0h946498lCWT9u O11ob+gVXfn4JNSBWSJ0dnEgERuFIE486xR7RX/33EOdCdXJHZnrgBI3uo/PfXH4smgb fYRPrHzzIlFVOnphDxa0yhbHwxN051TDcEjBuBlE7Cthu5E8q0j4vCWfTdLMTt4qRRhz gWJG1jDx/0fBFXbisf9NPhHhCHpXGyauwW6e/VxBwyx35jPBV2qT3VnjDk71AOrzvCbV xSIg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si9101397pgr.72.2018.04.25.04.19.53; Wed, 25 Apr 2018 04:20:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753307AbeDYLRk (ORCPT + 99 others); Wed, 25 Apr 2018 07:17:40 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:52174 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753568AbeDYKkh (ORCPT ); Wed, 25 Apr 2018 06:40:37 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 9FD1436; Wed, 25 Apr 2018 10:40:36 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vitaly Kuznetsov , Thomas Gleixner , David Zhang , Stephen Hemminger , Haiyang Zhang , "Michael Kelley (EOSG)" , Andy Lutomirski , devel@linuxdriverproject.org, "K. Y. Srinivasan" , Aditya Bhandari , Sasha Levin Subject: [PATCH 4.14 087/183] x86/hyperv: Stop suppressing X86_FEATURE_PCID Date: Wed, 25 Apr 2018 12:35:07 +0200 Message-Id: <20180425103245.991958948@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180425103242.532713678@linuxfoundation.org> References: <20180425103242.532713678@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Vitaly Kuznetsov [ Upstream commit 617ab45c9a8900e64a78b43696c02598b8cad68b ] When hypercall-based TLB flush was enabled for Hyper-V guests PCID feature was deliberately suppressed as a precaution: back then PCID was never exposed to Hyper-V guests and it wasn't clear what will happen if some day it becomes available. The day came and PCID/INVPCID features are already exposed on certain Hyper-V hosts. >From TLFS (as of 5.0b) it is unclear how TLB flush hypercalls combine with PCID. In particular the usage of PCID is per-cpu based: the same mm gets different CR3 values on different CPUs. If the hypercall does exact matching this will fail. However, this is not the case. David Zhang explains: "In practice, the AddressSpace argument is ignored on any VM that supports PCIDs. Architecturally, the AddressSpace argument must match the CR3 with PCID bits stripped out (i.e., the low 12 bits of AddressSpace should be 0 in long mode). The flush hypercalls flush all PCIDs for the specified AddressSpace." With this, PCID can be enabled. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Thomas Gleixner Cc: David Zhang Cc: Stephen Hemminger Cc: Haiyang Zhang Cc: "Michael Kelley (EOSG)" Cc: Andy Lutomirski Cc: devel@linuxdriverproject.org Cc: "K. Y. Srinivasan" Cc: Aditya Bhandari Link: https://lkml.kernel.org/r/20180124103629.29980-1-vkuznets@redhat.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- arch/x86/hyperv/mmu.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/arch/x86/hyperv/mmu.c +++ b/arch/x86/hyperv/mmu.c @@ -137,7 +137,12 @@ static void hyperv_flush_tlb_others(cons } if (info->mm) { + /* + * AddressSpace argument must match the CR3 with PCID bits + * stripped out. + */ flush->address_space = virt_to_phys(info->mm->pgd); + flush->address_space &= CR3_ADDR_MASK; flush->flags = 0; } else { flush->address_space = 0; @@ -219,7 +224,12 @@ static void hyperv_flush_tlb_others_ex(c } if (info->mm) { + /* + * AddressSpace argument must match the CR3 with PCID bits + * stripped out. + */ flush->address_space = virt_to_phys(info->mm->pgd); + flush->address_space &= CR3_ADDR_MASK; flush->flags = 0; } else { flush->address_space = 0; @@ -278,8 +288,6 @@ void hyperv_setup_mmu_ops(void) if (!(ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED)) return; - setup_clear_cpu_cap(X86_FEATURE_PCID); - if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) { pr_info("Using hypercall for remote TLB flush\n"); pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;