On Thu, 2024-12-12 at 10:42 -0700, Nathan Chancellor wrote: > > > What CPU is this? Shouldn't loading %cr3 have caused the existing TLB > > entry to be flushed? > > The machine I have mainly been reproducing and testing this issue on is > an Intel Xeon Gold 6314U but I initially noticed this problem on a few > consumer AMD and Intel chips that I have locally. > Not on my Haswell Xeon box though, it seems. Dave Hansen points out that it's probably the _PAGE_GLOBAL bit; that TLB entry *won't* get flushed. > > Can you tell me what happens if we don't write through *that* virtual > > mapping of the page, but instead do it a few instructions later through > > the identity mapping of the same page (which surely *won't* have an > > older, non-writeable TLB entry already...)? > > Applying that diff on top of 5a82223e0743 makes the issue go away for > me. Thanks. It actually seems to break the preserve_context mode for me, so I'll give it a bit more thought and probably come back to you with another version to test.
<<attachment: smime.p7s>>
