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

[Kirill A. Shutemov]

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