Re: how set_pte_at()'s vaddr and ptep args relate

[Jeremy Fitzhardinge <jeremy@goop.org>]

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