On Tue, Jun 25, 2019 at 7:39 PM Nadav Amit <na...@vmware.com> wrote: > > > On Jun 25, 2019, at 2:40 PM, Dave Hansen <dave.han...@intel.com> wrote: > > > > On 6/12/19 11:48 PM, Nadav Amit wrote: > >> Support the new interface of flush_tlb_multi, which also flushes the > >> local CPU's TLB, instead of flush_tlb_others that does not. This > >> interface is more performant since it parallelize remote and local TLB > >> flushes. > >> > >> The actual implementation of flush_tlb_multi() is almost identical to > >> that of flush_tlb_others(). > > > > This confused me a bit. I thought we didn't support paravirtualized > > flush_tlb_multi() from reading earlier in the series. > > > > But, it seems like that might be Xen-only and doesn't apply to KVM and > > paravirtualized KVM has no problem supporting flush_tlb_multi(). Is > > that right? It might be good to include some of that background in the > > changelog to set the context. > > I’ll try to improve the change-logs a bit. There is no inherent reason for > PV TLB-flushers not to implement their own flush_tlb_multi(). It is left > for future work, and here are some reasons: > > 1. Hyper-V/Xen TLB-flushing code is not very simple > 2. I don’t have a proper setup > 3. I am lazy >
In the long run, I think that we're going to want a way for one CPU to do a remote flush and then, with appropriate locking, update the tlb_gen fields for the remote CPU. Getting this right may be a bit nontrivial.
