Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753082AbdHKNj4 (ORCPT ); Fri, 11 Aug 2017 09:39:56 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:59565 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752896AbdHKNjz (ORCPT ); Fri, 11 Aug 2017 09:39:55 -0400 Date: Fri, 11 Aug 2017 15:39:41 +0200 From: Peter Zijlstra To: Juergen Gross Cc: Vitaly Kuznetsov , Jork Loeser , KY Srinivasan , Simon Xiao , Haiyang Zhang , Stephen Hemminger , "torvalds@linux-foundation.org" , "luto@kernel.org" , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , "rostedt@goodmis.org" , "andy.shevchenko@gmail.com" , "tglx@linutronix.de" , "mingo@kernel.org" , "linux-tip-commits@vger.kernel.org" , boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush Message-ID: <20170811133941.z36ttls65idptfw3@hirez.programming.kicks-ass.net> References: <20170810192742.GJ6524@worktop.programming.kicks-ass.net> <87lgmqqwzl.fsf@vitty.brq.redhat.com> <20170811105625.hmdfnp3yh72zut33@hirez.programming.kicks-ass.net> <20170811123534.quyckfyspl5fqdrg@hirez.programming.kicks-ass.net> <8d758a18-3db4-41c3-9748-41a649b7950b@suse.com> <20170811125442.5nyrvcylhdrmryt2@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1325 Lines: 26 On Fri, Aug 11, 2017 at 03:07:29PM +0200, Juergen Gross wrote: > On 11/08/17 14:54, Peter Zijlstra wrote: > > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: > >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the > >> IPI is serving two purposes here: TLB flushing (which is allowed to > >> happen at any time) and serialization regarding access to critical pages > >> (which seems to be broken in the Xen case as you suggest). > > > > Indeed, and now hyper-v as well. > > Is it possible to distinguish between non-critical calls of > flush_tlb_others() (which should be the majority IMHO) and critical ones > regarding above problem? I guess the only problem is the case when a > page table can be freed because its last valid entry is gone, right? > > We might want to add a serialization flag to indicate flushing _and_ > serialization via IPI should be performed. Possible, but not trivial. Esp things like transparent huge pages, which swizzles PMDs around makes things tricky. The by far easiest solution is to switch over to HAVE_RCU_TABLE_FREE when either Xen or Hyper-V is doing this. Ideally it would not have a significant performance hit (needs testing) and we can simply always do this when PARAVIRT, or otherwise we need to get creative with static_keys or something.