Messages in this thread | | | Date | Wed, 23 Jan 2008 18:47:54 +0100 | From | Gerd Hoffmann <> | Subject | Re: [kvm-devel] [PATCH] export notifier #1 |
| |
Andrea Arcangeli wrote: > Like Avi said, Xen is dealing with the linux pte only, so there's no > racy smp page fault to serialize against. Perhaps we can add another > notifier for Xen though. > > But I think it's still not enough for Xen to have a method called > before the ptep_clear_flush: rmap.c would get confused in > page_mkclean_one for example.
The current code sets a bunch of vma flags (VM_RESERVED, VM_DONTCOPY, VM_FOREIGN) so the VM doesn't try to handle those special mapping. IIRC one of them was needed to not make rmap unhappy.
> Nevertheless if you've any idea on how to use the notifiers for Xen > I'd be glad to help. Perhaps one workable way to change my patch to > work for you could be to pass the retval of ptep_clear_flush to the > notifiers themself. something like: > > #define ptep_clear_flush(__vma, __address, __ptep) \ > ({ \ > pte_t __pte; \ > __pte = ptep_get_and_clear((__vma)->vm_mm, __address, __ptep); \ > flush_tlb_page(__vma, __address); \ > __pte = mmu_notifier(invalidate_page, (__vma)->vm_mm, __address, __pte, __ptep); \ > __pte; \ > })
Would not work. Need to pass a pointer to the pte so the xen hypervisor can do unmap (aka pte_clear) and grant release as atomic operation. Thus passing the value of the pte entry isn't good enougth.
Another maybe workable approach for Xen is to go through pv_ops (although pte_clear doesn't go through pv_ops right now, so this would be an additional hook too ...).
cheers, Gerd
| |