search for: pte_offset_map

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, al...

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, al...

...#define pte_update(mm, addr, ptep) do { } while (0) #define pte_update_defer(mm, addr, ptep) do { } while (0) +#define paravirt_map_pt_hook(slot, va, pfn) do { } while (0) #endif /* @@ -469,10 +470,24 @@ extern pte_t *lookup_address(unsigned lo #endif #if defined(CONFIG_HIGHPTE) -#define pte_offset_map(dir, address) \ - ((pte_t *)kmap_atomic(pmd_page(*(dir)),KM_PTE0) + pte_index(address)) -#define pte_offset_map_nested(dir, address) \ - ((pte_t *)kmap_atomic(pmd_page(*(dir)),KM_PTE1) + pte_index(address)) +#define pte_offset_map(dir, address) \ +({ \ + pte_t *__ptep; \ + unsigned p...

...#define pte_update(mm, addr, ptep) do { } while (0) #define pte_update_defer(mm, addr, ptep) do { } while (0) +#define paravirt_map_pt_hook(slot, va, pfn) do { } while (0) #endif /* @@ -469,10 +470,24 @@ extern pte_t *lookup_address(unsigned lo #endif #if defined(CONFIG_HIGHPTE) -#define pte_offset_map(dir, address) \ - ((pte_t *)kmap_atomic(pmd_page(*(dir)),KM_PTE0) + pte_index(address)) -#define pte_offset_map_nested(dir, address) \ - ((pte_t *)kmap_atomic(pmd_page(*(dir)),KM_PTE1) + pte_index(address)) +#define pte_offset_map(dir, address) \ +({ \ + pte_t *__ptep; \ + unsigned p...

...pmd_trans_huge(*pmd) && is_huge_zero_pmd(*pmd)) { /* * FIXME: Do we want to invalidate secondary mmu by calling * mmu_notifier_invalidate_range() see comments below inside @@ -2117,30 +2117,34 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, pte = pte_offset_map(&_pmd, addr); BUG_ON(!pte_none(*pte)); set_pte_at(mm, addr, pte, entry); - atomic_inc(&page[i]._mapcount); - pte_unmap(pte); - } - - /* - * Set PG_double_map before dropping compound_mapcount to avoid - * false-negative page_mapped(). - */ - if (compound_mapcount(page) > 1 &am...

...;& is_huge_zero_pmd(*pmd)) { > /* > * FIXME: Do we want to invalidate secondary mmu by calling > * mmu_notifier_invalidate_range() see comments below inside > @@ -2117,30 +2117,34 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, > pte = pte_offset_map(&_pmd, addr); > BUG_ON(!pte_none(*pte)); > set_pte_at(mm, addr, pte, entry); > - atomic_inc(&page[i]._mapcount); > - pte_unmap(pte); > - } > - > - /* > - * Set PG_double_map before dropping compound_mapcount to avoid > - * false-negative page_mapped(). &...

...t, end, range, HMM_PFN_ERROR); if (pmd_devmap(pmd) || pmd_trans_huge(pmd)) { /* @@ -612,7 +611,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp, * recover. */ if (pmd_bad(pmd)) - return hmm_pfns_bad(start, end, walk); + return hmm_pfns_fill(start, end, range, HMM_PFN_ERROR); ptep = pte_offset_map(pmdp, addr); i = (addr - range->start) >> PAGE_SHIFT; @@ -770,13 +769,36 @@ static int hmm_vma_walk_hugetlb_entry(pte_t *pte, unsigned long hmask, #define hmm_vma_walk_hugetlb_entry NULL #endif /* CONFIG_HUGETLB_PAGE */ -static void hmm_pfns_clear(struct hmm_range *range, - uint...

I''m sure everyone has seen the drop of VMI patches for Linux at this point, but just in case, the link is included below. I''ve read this version of the VMI spec and have made my way through most of the patches. While I wasn''t really that impressed with the first spec wrt Xen, the second version seems to be much more palatable. Specifically, the code inlining and

...n during MMU calls in most cases. It is not sufficient if the kernel is compiled with page tables in high memory, since the page tables may then be mapped in at will. In this case, the kernel must notify the hypervisor of these mappings when they change. This is the purpose of the changes to the pte_offset_map functions. This need more comments. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/arch/i386/kernel/efi_stub.S =================================================================== --- linux-2.6.16-rc5.orig/arch/i386/kernel/efi_stub.S 2006-03-10 12:55:05.000000000 -0...

...n during MMU calls in most cases. It is not sufficient if the kernel is compiled with page tables in high memory, since the page tables may then be mapped in at will. In this case, the kernel must notify the hypervisor of these mappings when they change. This is the purpose of the changes to the pte_offset_map functions. This need more comments. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.16-rc5/arch/i386/kernel/efi_stub.S =================================================================== --- linux-2.6.16-rc5.orig/arch/i386/kernel/efi_stub.S 2006-03-10 12:55:05.000000000 -0...

...pmd_trans_huge(*pmd) && is_huge_zero_pmd(*pmd)) { /* * FIXME: Do we want to invalidate secondary mmu by calling * mmu_notifier_invalidate_range() see comments below inside @@ -2117,30 +2117,34 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, pte = pte_offset_map(&_pmd, addr); BUG_ON(!pte_none(*pte)); set_pte_at(mm, addr, pte, entry); - atomic_inc(&page[i]._mapcount); - pte_unmap(pte); - } - - /* - * Set PG_double_map before dropping compound_mapcount to avoid - * false-negative page_mapped(). - */ - if (compound_mapcount(page) > 1 &am...

This series adds support for transparent huge page migration to migrate_vma_*() and adds nouveau SVM and HMM selftests as consumers. An earlier version was posted previously [1]. This version now supports splitting a THP midway in the migration process which led to a number of changes. The patches apply cleanly to the current linux-mm tree. Since there are a couple of patches in linux-mm from Dan

...tatic int hmm_vma_walk_pmd(pmd_t *pmdp, * recover. */ if (pmd_bad(pmd)) { - if (hmm_range_need_fault(hmm_vma_walk, pfns, npages, 0)) + if (hmm_range_need_fault(hmm_vma_walk, hmm_pfns, npages, 0)) return -EFAULT; return hmm_pfns_fill(start, end, range, HMM_PFN_ERROR); } ptep = pte_offset_map(pmdp, addr); - for (; addr < end; addr += PAGE_SIZE, ptep++, pfns++) { + for (; addr < end; addr += PAGE_SIZE, ptep++, hmm_pfns++) { int r; - r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, pfns); + r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, hmm_pfns); if (r) { /* h...

...tatic int hmm_vma_walk_pmd(pmd_t *pmdp, * recover. */ if (pmd_bad(pmd)) { - if (hmm_range_need_fault(hmm_vma_walk, pfns, npages, 0)) + if (hmm_range_need_fault(hmm_vma_walk, hmm_pfns, npages, 0)) return -EFAULT; return hmm_pfns_fill(start, end, range, HMM_PFN_ERROR); } ptep = pte_offset_map(pmdp, addr); - for (; addr < end; addr += PAGE_SIZE, ptep++, pfns++) { + for (; addr < end; addr += PAGE_SIZE, ptep++, hmm_pfns++) { int r; - r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, pfns); + r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, hmm_pfns); if (r) { /* h...

...recover. > */ > if (pmd_bad(pmd)) { > - if (hmm_range_need_fault(hmm_vma_walk, pfns, npages, 0)) > + if (hmm_range_need_fault(hmm_vma_walk, hmm_pfns, npages, 0)) > return -EFAULT; > return hmm_pfns_fill(start, end, range, HMM_PFN_ERROR); > } > > ptep = pte_offset_map(pmdp, addr); > - for (; addr < end; addr += PAGE_SIZE, ptep++, pfns++) { > + for (; addr < end; addr += PAGE_SIZE, ptep++, hmm_pfns++) { > int r; > > - r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, pfns); > + r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, h...

Hi Andi, This series of patches updates paravirt_ops in various ways. Some of the changes are plain cleanups and improvements, and some add some interfaces necessary for Xen. The brief overview: add-MAINTAINERS.patch - obvious remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed paravirt-nop.patch - mark nop operations consistently paravirt-pte-accessors.patch - operations to pack/unpack

Hi Andi, This series of patches updates paravirt_ops in various ways. Some of the changes are plain cleanups and improvements, and some add some interfaces necessary for Xen. The brief overview: add-MAINTAINERS.patch - obvious remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed paravirt-nop.patch - mark nop operations consistently paravirt-pte-accessors.patch - operations to pack/unpack

From: Jason Gunthorpe <jgg at mellanox.com> The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in the simplified format. I would appreciated tested-by's for the two

Hi Andi, Here's a repost of the paravirt_ops update series I posted the other day. Since then, I found a few potential bugs with patching clobbering, cleaned up and documented paravirt.h and the patching machinery. Overview: add-MAINTAINERS.patch obvious remove-CONFIG_DEBUG_PARAVIRT.patch No longer meaningful or needed. paravirt-nop.patch Clean up nop paravirt_ops functions, mainly to

Hi Andi, Here's a repost of the paravirt_ops update series I posted the other day. Since then, I found a few potential bugs with patching clobbering, cleaned up and documented paravirt.h and the patching machinery. Overview: add-MAINTAINERS.patch obvious remove-CONFIG_DEBUG_PARAVIRT.patch No longer meaningful or needed. paravirt-nop.patch Clean up nop paravirt_ops functions, mainly to