On 16/04/2021 14:20, Jan Beulich wrote: > For Intel CPUs we record L3 cache size, hence we should also do so for > AMD and alike. > > While making these additions, also make sure (throughout the function) > that we don't needlessly overwrite prior values when the new value to be > stored is zero. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > I have to admit though that I'm not convinced the sole real use of the > field (in flush_area_local()) is a good one - flushing an entire L3's > worth of lines via CLFLUSH may not be more efficient than using WBINVD. > But I didn't measure it (yet).
WBINVD always needs a broadcast IPI to work correctly. CLFLUSH and friends let you do this from a single CPU, using cache coherency to DTRT with the line, wherever it is. Looking at that logic in flush_area_local(), I don't see how it can be correct. The WBINVD path is a decomposition inside the IPI, but in the higher level helpers, I don't see how the "area too big, convert to WBINVD" can be safe. All users of FLUSH_CACHE are flush_all(), except two PCI Passthrough-restricted cases. MMUEXT_FLUSH_CACHE_GLOBAL looks to be safe, while vmx_do_resume() has very dubious reasoning, and is dead code I think, because I'm not aware of a VT-x capable CPU without WBINVD-exiting. ~Andrew
