On Fri, Aug 11, 2017 at 03:07:29PM +0200, Juergen Gross wrote: > On 11/08/17 14:54, Peter Zijlstra wrote: > > On Fri, Aug 11, 2017 at 02:46:41PM +0200, Juergen Gross wrote: > >> Aah, okay. Now I understand the problem. The TLB isn't the issue but the > >> IPI is serving two purposes here: TLB flushing (which is allowed to > >> happen at any time) and serialization regarding access to critical pages > >> (which seems to be broken in the Xen case as you suggest). > > > > Indeed, and now hyper-v as well. > > Is it possible to distinguish between non-critical calls of > flush_tlb_others() (which should be the majority IMHO) and critical ones > regarding above problem? I guess the only problem is the case when a > page table can be freed because its last valid entry is gone, right? > > We might want to add a serialization flag to indicate flushing _and_ > serialization via IPI should be performed.
Possible, but not trivial. Esp things like transparent huge pages, which swizzles PMDs around makes things tricky. The by far easiest solution is to switch over to HAVE_RCU_TABLE_FREE when either Xen or Hyper-V is doing this. Ideally it would not have a significant performance hit (needs testing) and we can simply always do this when PARAVIRT, or otherwise we need to get creative with static_keys or something.
