Re: pte_offset_map + lazy mmu

[Zachary Amsden <zach@vmware.com>]

Jeremy Fitzhardinge wrote:
> Is pte_offset_map allowed to happen within lazy mmu?  I presume not,
> because you definitely don't want the mapping pte update to be deferred.
>
> Or, more specifically, is kunmap_atomic ever allowed within lazy mmu? 
> I'm looking at kpte_clear_flush; I've already got a patch which turns
> this into a pv_op, along with a Xen implementation.  But I think its
> probably an excess pv_op for a relatively minor corner case.  It seems
> to me that it would be better to define kpte_clear_flush as:
>
>     #define kpte_clear_flush(ptep, vaddr)					\
>     do {									\
>     	arch_enter_lazy_mmu_mode();					\
>     	pte_clear(&init_mm, vaddr, ptep);				\
>     	__flush_tlb_one(vaddr);						\
>     	arch_leave_lazy_mmu_mode();					\
>     } while (0)
>       
>
> and take advantage of mmu batching to make this operation efficient. 
> But I'm not sure if this is safe.
>
> (Also, kmap_atomic could use set_pte_at rather than set_pte.)
>
> What do you think?
>   

I'm sorry, I was broken.  This does work for us, as the batching is not 
nested (as you point out, that would be a bug).  I already took care to 
make sure that all the arch_enter_lazy_mmu_mode() hooks in mm code 
happen after the pagetables are mapped.

Still, I think the hint based solution allows for expansion of the 
capabilities without requiring new paravirt-ops.  What do you think 
about my proposal?

Zach