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 -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|