Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752950AbdHJS4z (ORCPT ); Thu, 10 Aug 2017 14:56:55 -0400 Received: from merlin.infradead.org ([205.233.59.134]:42790 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752629AbdHJS4x (ORCPT ); Thu, 10 Aug 2017 14:56:53 -0400 Date: Thu, 10 Aug 2017 20:56:46 +0200 From: Peter Zijlstra To: sixiao@microsoft.com, haiyangz@microsoft.com, Jork.Loeser@microsoft.com, sthemmin@microsoft.com, torvalds@linux-foundation.org, luto@kernel.org, hpa@zytor.com, vkuznets@redhat.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, andy.shevchenko@gmail.com, tglx@linutronix.de, kys@microsoft.com, mingo@kernel.org Cc: linux-tip-commits@vger.kernel.org Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush Message-ID: <20170810185646.GI6524@worktop.programming.kicks-ass.net> References: <20170802160921.21791-8-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1337 Lines: 28 On Thu, Aug 10, 2017 at 11:21:49AM -0700, tip-bot for Vitaly Kuznetsov wrote: > Commit-ID: 2ffd9e33ce4af4e8cfa3e17bf493defe8474e2eb > Gitweb: http://git.kernel.org/tip/2ffd9e33ce4af4e8cfa3e17bf493defe8474e2eb > Author: Vitaly Kuznetsov > AuthorDate: Wed, 2 Aug 2017 18:09:19 +0200 > Committer: Ingo Molnar > CommitDate: Thu, 10 Aug 2017 20:16:44 +0200 > > x86/hyper-v: Use hypercall for remote TLB flush > > Hyper-V host can suggest us to use hypercall for doing remote TLB flush, > this is supposed to work faster than IPIs. > > Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls > we need to put the input somewhere in memory and we don't really want to > have memory allocation on each call so we pre-allocate per cpu memory areas > on boot. > > pv_ops patching is happening very early so we need to separate > hyperv_setup_mmu_ops() and hyper_alloc_mmu(). > > It is possible and easy to implement local TLB flushing too and there is > even a hint for that. However, I don't see a room for optimization on the > host side as both hypercall and native tlb flush will result in vmexit. The > hint is also not set on modern Hyper-V versions. Hold on.. if we don't IPI for TLB invalidation. What serializes our software page table walkers like fast_gup() ?