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?
