On Sep 22, 2016 05:27, "Jan Beulich" <jbeul...@suse.com> wrote: > > >>> On 22.09.16 at 12:35, <tamas.leng...@zentific.com> wrote: > > On Sep 22, 2016 02:56, "Jan Beulich" <jbeul...@suse.com> wrote: > >> > >> >>> On 21.09.16 at 17:30, <tamas.leng...@zentific.com> wrote: > >> > What I'm saying is that the guest OS should be in charge of managing > >> > its own TLB when VPID is in use. Whether it does flush the TLB or not > >> > is not of our concern. If it's a sane OS it will likely flush when it > >> > needs to, but we should not be jumping in and doing it as we do right > >> > now. We are actually breaking the architectural behavior by forcing a > >> > flush, MOV-TO-CR3 doesn't by itself flush the TLB on real hardware. > >> > >> I continue to not understand where you take this from. Writes to > >> CR3 have always been doing TLB flushes - full ones prior to the > >> introduction of global pages, and flushes of only non-global entries > >> nowadays. In fact prior to the introduction of INVLPG and CR4 > >> there was no other way to flush TLBs. > > > > Yes, I meant it doesn't completely flush the TLB as we do right now when > > invalidating the whole VPID. > > But then what architectural behavior do you see broken? Flushing > more than is required is always permitted. (And again - I'm all for > improvements here, we just need to be careful to not remove > flushing that is architecturally required.) >
Global pages and PCID both are effectively disabled by this flush. And yes flushing more then the minimum necessary is permitted, but this seems rather excessive. It won't break (sane) applications but would slow things down for ones that optimize TLB usage. I'll do an experiment to check your hypothesis about no TLB flush being performed by the CPU if cpu-based load exiting is enabled. Should be rather easy to break applications that use the same virtual address if this is the case and we don't flush in Xen. Will report back on the results. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
