Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753465AbdHKMfx (ORCPT ); Fri, 11 Aug 2017 08:35:53 -0400 Received: from merlin.infradead.org ([205.233.59.134]:49156 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753442AbdHKMfu (ORCPT ); Fri, 11 Aug 2017 08:35:50 -0400 Date: Fri, 11 Aug 2017 14:35:34 +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: <20170811123534.quyckfyspl5fqdrg@hirez.programming.kicks-ass.net> References: <20170802160921.21791-8-vkuznets@redhat.com> <20170810185646.GI6524@worktop.programming.kicks-ass.net> <20170810192742.GJ6524@worktop.programming.kicks-ass.net> <87lgmqqwzl.fsf@vitty.brq.redhat.com> <20170811105625.hmdfnp3yh72zut33@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: 1285 Lines: 29 On Fri, Aug 11, 2017 at 02:22:25PM +0200, Juergen Gross wrote: > Wait - the TLB can be cleared at any time, as Andrew was pointing out. > No cpu can rely on an address being accessible just because IF is being > cleared. All that matters is the existing and valid page table entry. > > So clearing IF on a cpu isn't meant to secure the TLB from being > cleared, but just to avoid interrupts (as the name of the flag is > suggesting). Yes, but by holding off the TLB invalidate IPI, we hold off the freeing of the concurrently unhooked page-table. > In the Xen case the hypervisor does the following: > > - it checks whether any of the vcpus specified in the cpumask of the > flush request is running on any physical cpu > - if any running vcpu is found an IPI will be sent to the physical cpu > and the hypervisor will do the TLB flush there And this will preempt a vcpu which could have IF cleared, right? > - any vcpu addressed by the flush and not running will be flagged to > flush its TLB when being scheduled the next time > > This ensures no TLB entry to be flushed can be used after return of > xen_flush_tlb_others(). But that is not a sufficient guarantee. We need the IF to hold off the TLB invalidate and thereby hold off the freeing of our page-table pages.