similar to: [PATCH 9/9] 00mme update pte hook.patch

Make parameter names match function argument names for the yet to be defined pte_update_defer accessor. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r c7f79c35c160 include/asm-i386/pgtable.h --- a/include/asm-i386/pgtable.h Thu Oct 19 03:03:24 2006 -0700 +++ b/include/asm-i386/pgtable.h Thu Oct 19 03:11:31 2006 -0700 @@ -275,7 +275,7 @@ do { \ do { \ if (dirty)

Make parameter names match function argument names for the yet to be defined pte_update_defer accessor. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r c7f79c35c160 include/asm-i386/pgtable.h --- a/include/asm-i386/pgtable.h Thu Oct 19 03:03:24 2006 -0700 +++ b/include/asm-i386/pgtable.h Thu Oct 19 03:11:31 2006 -0700 @@ -275,7 +275,7 @@ do { \ do { \ if (dirty)

Remove ptep_test_and_clear_{dirty|young} from i386, and instead use the dominating functions, ptep_clear_flush_{dirty|young}. This allows the TLB page flush to be contained in the same macro, and allows for an eager optimization - if reading the PTE initially returned dirty/accessed, we can assume the fact that no subsequent update to the PTE which cleared accessed / dirty has occurred, as the

MMU code movement. Unfortunately, this one is a little bit more complicated than the rest. We have to override the default accessors that directly write to page table entries. Because of the 2/3-level PAE split in Linux, this turned out to be really ugly at first, but by allowing the sub-arch layer to override the definitions and keeping the native definitions in place, the code becomes much

MMU code movement. Unfortunately, this one is a little bit more complicated than the rest. We have to override the default accessors that directly write to page table entries. Because of the 2/3-level PAE split in Linux, this turned out to be really ugly at first, but by allowing the sub-arch layer to override the definitions and keeping the native definitions in place, the code becomes much

Now that ptep_establish has a definition in PAE i386 3-level paging code, the only paging model which is insane enough to have multi-word hardware PTEs which are not efficient to set atomically, we can remove the ghost of set_pte_atomic from other architectures which falesly duplicated it, and remove all knowledge of it from the generic pgtable code. set_pte_atomic is now a private pte operator

The ptep_establish macro is only used on user-level PTEs, for P->P mapping changes. Since these always happen under protection of the pagetable lock, the strong synchronization of a 64-bit cmpxchg is not needed, in fact, not even a lock prefix needs to be used. We can simply instead clear the P-bit, followed by a normal set. The write ordering is still important to avoid the possibility of

diff -r f1dd818c2f06 include/asm-i386/pgtable-2level.h --- a/include/asm-i386/pgtable-2level.h Thu Oct 19 03:03:09 2006 -0700 +++ b/include/asm-i386/pgtable-2level.h Thu Oct 19 03:03:18 2006 -0700 @@ -22,8 +22,7 @@ #define pte_clear(mm,addr,xp) do { set_pte_at(mm, addr, xp, __pte(0)); } while (0) #define pmd_clear(xp) do { set_pmd(xp, __pmd(0)); } while (0) -#define

diff -r f1dd818c2f06 include/asm-i386/pgtable-2level.h --- a/include/asm-i386/pgtable-2level.h Thu Oct 19 03:03:09 2006 -0700 +++ b/include/asm-i386/pgtable-2level.h Thu Oct 19 03:03:18 2006 -0700 @@ -22,8 +22,7 @@ #define pte_clear(mm,addr,xp) do { set_pte_at(mm, addr, xp, __pte(0)); } while (0) #define pmd_clear(xp) do { set_pmd(xp, __pmd(0)); } while (0) -#define

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

[ I think this is a straight repost this patch, which addresses all the previous comments. I'd like to submit this for .24 as the basis for a unified paravirt_ops. Any objections? ] This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,

Here's a first attempt at splitting up paravirt_ops into more specific chunks. Its pretty clunky and chunky; mostly just a lot of replacement. The grouping of ops is very first cut; I'm open to suggestions about what groups should exist and what ops they each should contain. The only slightly subtle part is that I've kept the structures wrapped in a paravirt_ops structure,

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

This patch refactors the paravirt_ops structure into groups of functionally related ops: pv_info - random info, rather than function entrypoints pv_init_ops - functions used at boot time (some for module_init too) pv_misc_ops - lazy mode, which didn't fit well anywhere else pv_time_ops - time-related functions pv_cpu_ops - various privileged instruction ops pv_irq_ops - operations for

In shadow mode hypervisors, ptep_get_and_clear achieves the desired purpose of keeping the shadows in sync by issuing a native_get_and_clear, followed by a call to pte_update, which indicates the PTE has been modified. Direct mode hypervisors (Xen) have no need for this anyway, and will trap the update using writable pagetables. This means no hypervisor makes use of ptep_get_and_clear; there is

In shadow mode hypervisors, ptep_get_and_clear achieves the desired purpose of keeping the shadows in sync by issuing a native_get_and_clear, followed by a call to pte_update, which indicates the PTE has been modified. Direct mode hypervisors (Xen) have no need for this anyway, and will trap the update using writable pagetables. This means no hypervisor makes use of ptep_get_and_clear; there is

Impact: intermittent guest segv/crash fix I've been seeing random guest bad address crashes and segmentation faults: bisect led to 4f98a2fee8 (vmscan: split LRU lists into anon & file sets), but that's a red herring. It turns out that lguest never hooked up the pte_update/pte_update_defer calls, so our ptes were not always in sync. After the vmscan commit, the bug became

Impact: intermittent guest segv/crash fix I've been seeing random guest bad address crashes and segmentation faults: bisect led to 4f98a2fee8 (vmscan: split LRU lists into anon & file sets), but that's a red herring. It turns out that lguest never hooked up the pte_update/pte_update_defer calls, so our ptes were not always in sync. After the vmscan commit, the bug became

In situations where page table updates need only be made locally, and there is no cross-processor A/D bit races involved, we need not use the heavyweight xchg instruction to atomically fetch and clear page table entries. Instead, we can just read and clear them directly. This introduces a neat optimization for non-SMP kernels; drop the atomic xchg operations from page table updates. Thanks to