Jeremy Fitzhardinge wrote: > Hi Zach, > > I'm wondering what the interface requirements of set_pte_at()'s "addr" > and "ptep" args are. I presume that in general the ptep points to the > pte entry which corresponds to the vaddr, but is this necessarily the > case? Yes, it must pass a pointer to the PTE in ptep. The "addr" field must match the linear address of the mapping changed by the pte - the address you would invlpg if required. > For example, it is valid to pass a non-highmem page kmap_atomic(), > which will simply return a direct pointer to the page. > > kunmap_atomic() takes this address, as well as the kmap slot index, > and ends up calling: > > set_pte_at(&init_mm, lowmem_vaddr, kmap_ptep, 0); > > ie, the vaddr and the ptep bear no relationship to each other. Is > this a bug in kunmap_atomic (it shouldn't try to clear the pte for > lowmem addresses), or should set_pte_at's implementation be able to > cope with this. Ok, that is really strange, but it seems harmless. > > Certainly at the moment, having mismatched ptep and vaddr makes the > interface useless for Xen, since it will use one or the other > depending on whether we modifying the current pagetable or not, and it > assume they correspond to the same thing. > > For now I've changed kunmap_atomic() to only clear the kmap pte for > mapped high page addresses, but I'm wondering what other places might > use set_pte_at in this way. None that I'm aware of. The interface here is supposed to be passing the "addr" field as the linear address whose mapping in the current address space is changing, and the "ptep" field as a pointer to the PTE. > Also, it would be useful for Xen to have a set_pte_at_sync, which also > does a TLB flush if necessary, since we can do that in a single > operation. We could either add new operators or use a flags field which passes a "defer this update and piggyback on the next TLB flush" hint - which is how the Xen VMI interface worked. In any case, the address field and hints / operators here are supposed to be liberal enough to accommodate using LA hints to update currently mapped PTEs and piggyback the flush, and if they are not, it is a bug or an oversight. I haven't really dealt with the HIGHMEM_PTE case thoroughly yet - do we want to bother with that? Zach
