Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752866AbdHKL3g (ORCPT ); Fri, 11 Aug 2017 07:29:36 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:34041 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752096AbdHKL3e (ORCPT ); Fri, 11 Aug 2017 07:29:34 -0400 Date: Fri, 11 Aug 2017 14:29:28 +0300 From: "Kirill A. Shutemov" To: Peter Zijlstra Cc: Jork Loeser , KY Srinivasan , Simon Xiao , Haiyang Zhang , Stephen Hemminger , "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" , "mingo@kernel.org" , "linux-tip-commits@vger.kernel.org" , "Kirill A. Shutemov" Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush Message-ID: <20170811112928.vyl7226gvg2yb7y2@node.shutemov.name> References: <20170802160921.21791-8-vkuznets@redhat.com> <20170810185646.GI6524@worktop.programming.kicks-ass.net> <20170810192742.GJ6524@worktop.programming.kicks-ass.net> <20170811090336.lfznz6qzrbhiqwvi@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170811090336.lfznz6qzrbhiqwvi@hirez.programming.kicks-ass.net> 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: 1836 Lines: 40 On Fri, Aug 11, 2017 at 11:03:36AM +0200, Peter Zijlstra wrote: > On Fri, Aug 11, 2017 at 01:15:18AM +0000, Jork Loeser wrote: > > > > > 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. > > > > I see, IF is used as a locking mechanism for the pages. Would > > CONFIG_HAVE_RCU_TABLE_FREE be an option for x86? There are caveats > > (statically enabled, RCU for page-free), yet if the resulting perf is > > still a gain it would be worthwhile for Hyper-V targeted kernels. > > I'm sure we talked about using HAVE_RCU_TABLE_FREE for x86 (and yes that > would make it work again), but this was some years ago and I cannot > readily find those emails. > > Kirill would you have any opinions? I guess we can try this. The main question is what would be performance implications of such move. -- Kirill A. Shutemov