Jeremy Fitzhardinge wrote: > Zachary Amsden wrote: >> Anything where you implicitly defer pagetable updates is far too >> vulnerable to bugs. We played with several such schemes before, and >> although they could be made to work for a shadow mode hypervisor, >> getting them to work for both shadow and direct mode, with >> performance opportunities for everyone was just too risky and a >> burden on the Linux mm code. > > Yep. > >> There is no architectural rule about tlb flush that I am aware of, >> however, most cores will allow you to do NP->P transitions without a >> flush. YMMV. I believe the Linux use is fine. > > Hm, I was under the impression there's an actual architectural > guarantee there, but I don't know chapter&verse. There isn't one explicitly stated in the book I'm looking at. Ps 19:12 NIV seems relevant, although a little cryptic. "Who can discern his errors? Forgive my hidden faults." > I'm working on linear pagetables, so that ptes can be allocated from > anywhere any be directly accessable. This eliminates the need for > CONFIG_HIGHPTE, and it also simplifies a lot of the pagetable > walking. Manipulating other processes's pagetables would still need > kmap (or a second window for cross-process pagetable manipulation), > but I should think that's pretty rare. Oh, wow. Unfortunately, the complexity isn't from how frequent or rare a kmapped PT access is, it is from it being there at all. Zach
