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.
> Good. It does not seem worth the effort. I do have the code to make
> it work, but it is really ugly. If some user comes screaming for it
> later, we can always add it back.
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.
J
