Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 26 May 2020 17:09:58 -0700 | Subject | Re: Possibility of conflicting memory types in lazier TLB mode? |
| |
[cc Andrew Cooper and Dave Hansen]
On Fri, May 15, 2020 at 7:35 PM Nicholas Piggin <npiggin@gmail.com> wrote: > > Excerpts from Rik van Riel's message of May 16, 2020 5:24 am: > > On Fri, 2020-05-15 at 16:50 +1000, Nicholas Piggin wrote: > >> > >> 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? > > > > On x86, all stores become visible in-order globally. > > > > I suspect that > > means any pending stores in the queue > > would become visible to the rest of the system before > > the store to the "current" cpu-local variable, as > > well as other writes from the context switch code > > become visible to the rest of the system. > > > > Is that too naive a way of preventing the scenario you > > describe? > > > > What am I overlooking? > > I'm concerned if the physical address gets mapped with different > cacheability attributes where that ordering is not enforced by cache > coherency > > "The PAT allows any memory type to be specified in the page tables, and > therefore it is possible to have a single physical page mapped to two > or more different linear addresses, each with different memory types. > Intel does not support this practice because it may lead to undefined > operations that can result in a system failure. In particular, a WC > page must never be aliased to a cacheable page because WC writes may > not check the processor caches." -- Vol. 3A 11-35 > > Maybe I'm over thinking it, and this would never happen anyway because > if anyone were to map a RAM page WC, they might always have to ensure > all processor caches are flushed first anyway so perhaps this is just a > non-issue? >
After talking to Andrew Cooper (hi!), I think that, on reasonably modern Intel machines, WC memory is still *coherent* with the whole system -- it's just not ordered the usual way. So I'm not convinced there's an actual problem here. I don't know about AMD.
| |