similar to: [PATCH 7/9] 00mma remove set pte atomic.patch

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

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

On x86 set_pte_at() is now always falling back to set_pte(). So instead of having this fallback after the paravirt maze just drop the set_pte_at paravirt operation and let set_pte_at() use the set_pte() function directly. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/include/asm/paravirt.h | 8 +------- arch/x86/include/asm/paravirt_types.h | 2 --

Change pte_clear_full to a more appropriately named pte_clear_not_present, allowing optimizations when not-present mapping changes need not be reflected in the hardware TLB for protected page table modes. There is also another case that can use it in the fremap code. Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> ---

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments

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,

Add a pte_update_hook which notifies about pte changes that have been made without using the set_pte / clear_pte interfaces. This allows shadow mode hypervisors which do not trap on page table access to maintain synchronized shadows. It also turns out, there was one pte update in PAE mode that wasn't using any accessor interface at all for setting NX protection. Considering it is PAE

[ 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

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

Hi, On Sun, Aug 24, 2003 at 07:14:29AM -0400, Brandon S. Allbery KF8NH wrote: > >Synopsis: vmware2 broken on -STABLE, presumably by PAE import >> (..) Your patch makes VmWare2 build, but it doesn't make it work: - VmWare fails to allocate memory (see http://anders.fix.no/test/vmware/1.png and http://anders.fix.no/test/vmware/2.png). - There seems to be something wrong with

Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() which flushes all device private page mappings whether or not a page is being migrated to/from device private memory. In order to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to the device driver and leave CPU page table unmapping handled by

Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() which flushes all device private page mappings whether or not a page is being migrated to/from device private memory. In order to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to the device driver and leave CPU page table unmapping handled by

On Mon, Jul 13, 2020 at 10:21:47AM -0700, Ralph Campbell wrote: > Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() > which flushes all device private page mappings whether or not a page > is being migrated to/from device private memory. In order to not disrupt > device mappings that are not being migrated, shift the responsibility > for clearing device

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 92 +++------------------ arch/x86/include/asm/paravirt_types.h | 21 ----- arch/x86/include/asm/pgtable-3level_types.h | 5 --

The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone. Remove 32-bit specific parts. Signed-off-by: Juergen Gross <jgross at suse.com> --- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/paravirt.h | 120 ++------------------ arch/x86/include/asm/paravirt_types.h | 21 ---- arch/x86/include/asm/pgtable-3level_types.h | 5 -