From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752935AbdHKMqs (ORCPT ); Fri, 11 Aug 2017 08:46:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:52379 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752703AbdHKMqq (ORCPT ); Fri, 11 Aug 2017 08:46:46 -0400 Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush To: Peter Zijlstra 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 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> <20170811123534.quyckfyspl5fqdrg@hirez.programming.kicks-ass.net> From: Juergen Gross Message-ID: <8d758a18-3db4-41c3-9748-41a649b7950b@suse.com> Date: Fri, 11 Aug 2017 14:46:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170811123534.quyckfyspl5fqdrg@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/08/17 14:35, Peter Zijlstra wrote: > 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. 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). Juergen >