From patchwork Fri Jan 26 22:02:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marcelo Henrique Cerri X-Patchwork-Id: 866623 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3zStF14Sr4z9t34; Sat, 27 Jan 2018 09:02:45 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1efC50-0005FE-Gv; Fri, 26 Jan 2018 22:02:38 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1efC4y-0005Ew-C9 for kernel-team@lists.ubuntu.com; Fri, 26 Jan 2018 22:02:36 +0000 Received: from mail-qt0-f198.google.com ([209.85.216.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1efC4y-0005PR-1n for kernel-team@lists.ubuntu.com; Fri, 26 Jan 2018 22:02:36 +0000 Received: by mail-qt0-f198.google.com with SMTP id f34so2685191qtb.4 for ; Fri, 26 Jan 2018 14:02:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=OSP+uCX7+6btQvylShisTdqC0T7kWuOvqq7s4pLnjqg=; b=nGnwZrkfNj0PkvuqIhGp7abKc36FHkR/s1k6h2To0QRTmyBdLEQJBj397YK69l4SvR KiX+CeeCIQZzPyj+UvIt03j7UqPcnnntGvczzQ9vORgj4/UvWGmy+dotozEfQeu05GUr i8MK9nliy0mj8A5SFrz0cLDtZ9cErt+6QUs1PmLGpQdN1ZpDEvYmttIQIm4OUtm76toQ fT0SFRYakcPa1Kl8u9+FJA++tbsg22GuxLya9h/MxBzs7UYQVvIw2cxNe4tRTAltf+0H 1SIrCpAtrNbXHchd+TV9Puj16Nl/4TqHPRQiEmxydkCYDFTBbASpua6tBfSmayrCaUwu qnNw== X-Gm-Message-State: AKwxytefHa85TjMhx9KQcHQuTV2Yrpk3ZKymSsqRGFOgZOjkZQXPs3iC gLrxRkBUJC5cFNV6IZ7U4oWGBiOJH3IwaRrznkuZt+wHGk6cPLeYdE8sFUIgyfrPG4oAhMNLHSL oficmfWZiUVklLNI9kH7YmjLm/leMs4Y0uUoxdtnv X-Received: by 10.55.34.6 with SMTP id i6mr21669444qki.11.1517004154785; Fri, 26 Jan 2018 14:02:34 -0800 (PST) X-Google-Smtp-Source: AH8x224N79rFAZ96Wb6+K9Xc81RTt2Fkxr66uy6pptJd18E65xtJnotg53Wo2DHQ3YX+o2reRFM/bg== X-Received: by 10.55.34.6 with SMTP id i6mr21669417qki.11.1517004154557; Fri, 26 Jan 2018 14:02:34 -0800 (PST) Received: from localhost.localdomain (189-19-124-180.dsl.telesp.net.br. [189.19.124.180]) by smtp.gmail.com with ESMTPSA id f90sm2892124qtb.31.2018.01.26.14.02.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Jan 2018 14:02:33 -0800 (PST) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [azure][PATCH] UBUNTU: SAUCE: x86/hyperv: Stop suppressing X86_FEATURE_PCID Date: Fri, 26 Jan 2018 20:02:24 -0200 Message-Id: <1517004144-8588-2-git-send-email-marcelo.cerri@canonical.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1517004144-8588-1-git-send-email-marcelo.cerri@canonical.com> References: <1517004144-8588-1-git-send-email-marcelo.cerri@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Vitaly Kuznetsov BugLink: http://bugs.launchpad.net/bugs/1745247 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: Marcelo Henrique Cerri --- arch/x86/hyperv/mmu.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c index 9cc9e1c1e2db..694abf1e2956 100644 --- a/arch/x86/hyperv/mmu.c +++ b/arch/x86/hyperv/mmu.c @@ -111,7 +111,7 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus, int cpu, vcpu, gva_n, max_gvas; struct hv_flush_pcpu **flush_pcpu; struct hv_flush_pcpu *flush; - u64 status = U64_MAX; + u64 base, status = U64_MAX; unsigned long flags; trace_hyperv_mmu_flush_tlb_others(cpus, info); @@ -137,7 +137,12 @@ static void hyperv_flush_tlb_others(const struct cpumask *cpus, } 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(const struct cpumask *cpus, } 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;