Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush

From: Peter Zijlstra <peterz@infradead.org>
To: Jork Loeser <Jork.Loeser@microsoft.com>
Cc: KY Srinivasan <kys@microsoft.com>,
	Simon Xiao <sixiao@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	"luto@kernel.org" <luto@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"vkuznets@redhat.com" <vkuznets@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"linux-tip-commits@vger.kernel.org" 
	<linux-tip-commits@vger.kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [tip:x86/platform] x86/hyper-v: Use hypercall for remote TLB flush
Date: Fri, 11 Aug 2017 11:03:36 +0200	[thread overview]
Message-ID: <20170811090336.lfznz6qzrbhiqwvi@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CY4PR21MB0631989FA0C9135AAD2DD1F8F1890@CY4PR21MB0631.namprd21.prod.outlook.com>

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?