Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752704AbdHKK4s (ORCPT ); Fri, 11 Aug 2017 06:56:48 -0400 Received: from merlin.infradead.org ([205.233.59.134]:47840 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751891AbdHKK4q (ORCPT ); Fri, 11 Aug 2017 06:56:46 -0400 Date: Fri, 11 Aug 2017 12:56:25 +0200 From: Peter Zijlstra To: Vitaly Kuznetsov Cc: 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" , Juergen Gross , 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: <20170811105625.hmdfnp3yh72zut33@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lgmqqwzl.fsf@vitty.brq.redhat.com> 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: 1894 Lines: 42 On Fri, Aug 11, 2017 at 11:23:10AM +0200, Vitaly Kuznetsov wrote: > Peter Zijlstra writes: > > > On Thu, Aug 10, 2017 at 07:08:22PM +0000, Jork Loeser wrote: > > > >> > > Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush > >> > >> > > Hold on.. if we don't IPI for TLB invalidation. What serializes our > >> > > software page table walkers like fast_gup() ? > >> > > >> > Hypervisor may implement this functionality via an IPI. > >> > > >> > K. Y > >> > >> HvFlushVirtualAddressList() states: > >> This call guarantees that by the time control returns back to the > >> caller, the observable effects of all flushes on the specified virtual > >> processors have occurred. > >> > >> HvFlushVirtualAddressListEx() refers to HvFlushVirtualAddressList() as adding sparse target VP lists. > >> > >> Is this enough of a guarantee, or do you see other races? > > > > That's nowhere near enough. We need the remote CPU to have completed any > > guest IF section that was in progress at the time of the call. > > > > So if a host IPI can interrupt a guest while the guest has IF cleared, > > and we then process the host IPI -- clear the TLBs -- before resuming the > > guest, which still has IF cleared, we've got a problem. > > > > Because at that point, our software page-table walker, that relies on IF > > being clear to guarantee the page-tables exist, because it holds off the > > TLB invalidate and thereby the freeing of the pages, gets its pages > > ripped out from under it. > > Oh, I see your concern. Hyper-V, however, is not the first x86 > hypervisor trying to avoid IPIs on remote TLB flush, Xen does this > too. Briefly looking at xen_flush_tlb_others() I don't see anything > special, do we know how serialization is achieved there? No idea on how Xen works, I always just hope it goes away :-) But lets ask some Xen folks.