From patchwork Mon Jan 29 11:47:55 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: 867065 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 3zVSSW4Hh7z9s74; Mon, 29 Jan 2018 22:48:11 +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 1eg7ux-0004FE-4Q; Mon, 29 Jan 2018 11:48:07 +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 1eg7uw-0004F1-2b for kernel-team@lists.ubuntu.com; Mon, 29 Jan 2018 11:48:06 +0000 Received: from mail-qk0-f198.google.com ([209.85.220.198]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1eg7uv-0001TR-PK for kernel-team@lists.ubuntu.com; Mon, 29 Jan 2018 11:48:05 +0000 Received: by mail-qk0-f198.google.com with SMTP id p141so4056126qke.4 for ; Mon, 29 Jan 2018 03:48:05 -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=H9aOBhtBy9VeiATp2bS/4btO4YDQMonC1xFG2VcMFeQ=; b=Lt6cGrEZUXrkA1zIOKKOPSBx66BapNZH2RQQlRjwaO/Df9Esdtb/fMDl0rkOvP7wfZ ekiCiJqLsO++NwtKJTrjs3nGPdvdWrHUWhd7rZNETCXdD4m2G7waU2EW9eOSTj770/py UPYu1ZfdNWFx7Gx5D3hL0KF263ZSEDIPyI7nSEjowE85KhXOGOG3x0bmkgvbs1GeYjWV MJkL8ZT8DTmD6qnefRu2NYMiPw9YEC0OvSdwfU74Wl0LWn5PcLMvLRi5KRVBgET+TeDe EZ3da9LRGBrEfY3fG+MC8boqrfbEOF23huHdhetaaGXLs/mrBncMyawo8z811q+aUkK9 +iiw== X-Gm-Message-State: AKwxytf7EM1tTSIDTbGMGUpjBDfAdfKx1NQCIzU5uOuj/GNs2UZ1PCPV yavAJ7AhqyK5EYx1u4QQEBYOs2vv6ejuhk9PSUADAdCMjjUNun1FVTePv6M/LB2QuUNIASXZX3g o6pBzbBUMzTAt86E6p1BFhQBqIlqFL5rDnsgDphvo X-Received: by 10.200.23.136 with SMTP id o8mr41427941qtj.255.1517226484488; Mon, 29 Jan 2018 03:48:04 -0800 (PST) X-Google-Smtp-Source: AH8x225jz40GbZHN2ruBFT7XRpbEwEukZiAnWUlmuR6jPYCN9hWCsqkKsqOlBvlXCuI7Jar1eUS1jg== X-Received: by 10.200.23.136 with SMTP id o8mr41427925qtj.255.1517226484181; Mon, 29 Jan 2018 03:48:04 -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 d199sm7233922qkc.46.2018.01.29.03.48.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Jan 2018 03:48:02 -0800 (PST) From: Marcelo Henrique Cerri To: kernel-team@lists.ubuntu.com Subject: [azure][PATCH] x86/hyperv: Stop suppressing X86_FEATURE_PCID Date: Mon, 29 Jan 2018 09:47:55 -0200 Message-Id: <1517226475-21015-1-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 (cherry picked from linux-next commit 617ab45c9a8900e64a78b43696c02598b8cad68b) Signed-off-by: Marcelo Henrique Cerri Acked-by: Kleber Sacilotto de Souza Acked-by: Colin Ian King --- arch/x86/hyperv/mmu.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c index 9cc9e1c1e2db..56c9ebac946f 100644 --- a/arch/x86/hyperv/mmu.c +++ b/arch/x86/hyperv/mmu.c @@ -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;