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

[Zachary Amsden <zach@vmware.com>]

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