Hi Rik,
Commit 145f573b89a62 ("Make lazy TLB mode lazier").
A couple of questions here (and I don't know the x86 architecture too
well let alone the ASID stuff, so bear with me). I'm assuming, and it
appears to be in the x86 manual that you can't map the same physical
page with conflicting memory types on different processors in general
(or in different ASIDs on the same processor?)
Firstly, the freed_tables check, that's to prevent CPUs in the lazy mode
with this mm loaded in their ASID from bringing in new translations
based on random "stuff" if they happen to speculatively load userspace
addresses (but in lazy mode they would never explicitly load such
addresses), right?
I'm guessing that's a problem but the changed pte case is not, is
because the table walker is going to barf if it sees garbage, but a
valid pte is okay.
Now the intel manual says conflicting attributes are bad because you'll
lose cache coherency on stores. But the speculative accesses from the
lazy thread will never push stores to cache coherency and result of the
loads doesn't matter, so maybe that's how this special case avoids the
problem.
But what about if there are (real, not speculative) stores in the store
queue still on the lazy thread from when it was switched, that have not
yet become coherent? The page is freed by another CPU and reallocated
for something that maps it as nocache. Do you have a coherency problem
there?
Ensuring the store queue is drained when switching to lazy seems like it
would fix it, maybe context switch code does that already or you have
some other trick or reason it's not a problem. Am I way off base here?
Thanks,
Nick
