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
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/virtualization
