similar to: [PATCH] linux/i386: allow CONFIG_HIGHPTE on i386 (take 2)

As long as the pte page isn''t really located in highmem, there is no reason to not access it, in order to print the complete page table hierarchy. A functionally similar patch will go to lkml for native Linux. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: sle10-sp1-2007-01-12/arch/i386/mm/fault-xen.c =================================================================== ---

As usual, written and tested on 2.6.25.2 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-05-08/arch/x86_64/mm/pageattr-xen.c =================================================================== --- head-2008-05-08.orig/arch/x86_64/mm/pageattr-xen.c 2008-05-15 13:44:37.000000000 +0200 +++

Support transparent huge page migration to ZONE_DEVICE private memory. A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to indicate the huge page was fully mapped by the CPU. Export prep_compound_page() so that device drivers can create huge device private pages after calling memremap_pages(). Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> ---

Given that dom0 is itself doesn''t managed the memory directly that you only need to compile HIGHMEM4G into the dom0 or domU kernels if you intend to use more than 1G in one domX instances. ie. Even if you have more than 1Gb of total physical memory, if none of the domX use more than 1Gb of memory, there is no need to compile in HIGHMEM4G. Or, does dom0 need to be compiled with this in

Cannot use virt_to_machine() on a kmap()-ed address. As usual, written and tested on 2.6.24 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-01-28/arch/i386/mm/hypervisor.c =================================================================== --- head-2008-01-28.orig/arch/i386/mm/hypervisor.c 2007-10-19

Assumes hypervisor interface headers have been sync-ed after the hypervisor side patch was applied. As usual, written and tested on 2.6.27.3 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-10-24/arch/i386/mm/highmem-xen.c =================================================================== ---

On 19 Jun 2020, at 17:56, Ralph Campbell wrote: > Support transparent huge page migration to ZONE_DEVICE private memory. > A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to > indicate the huge page was fully mapped by the CPU. > Export prep_compound_page() so that device drivers can create huge > device private pages after calling memremap_pages(). > >

Support transparent huge page migration to ZONE_DEVICE private memory. A new selection flag (MIGRATE_VMA_SELECT_COMPOUND) is added to request THP migration. Otherwise, THPs are split when filling in the source PFN array. A new flag (MIGRATE_PFN_COMPOUND) is added to the source PFN array to indicate a huge page can be migrated. If the device driver can allocate a huge page, it sets the

Don't implement native_kmap_atomic_pte for !HIGHPTE case; it is never needed, never called, and leaving it in is just plain confusing. Making it isolated to the config where it is used may help find bugs. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 5c03805411a6 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Fri Apr 06 14:43:30 2007 -0700 +++

Don't implement native_kmap_atomic_pte for !HIGHPTE case; it is never needed, never called, and leaving it in is just plain confusing. Making it isolated to the config where it is used may help find bugs. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 5c03805411a6 arch/i386/kernel/paravirt.c --- a/arch/i386/kernel/paravirt.c Fri Apr 06 14:43:30 2007 -0700 +++

Does anyone know what I would have to modify in 6 if I wanted to run on an older Pentium M CPU without PAE? Is it just the kernel that needs to be rebuilt (maybe while installed in a system with a supported CPU)? Or are there other components that would cause problems and need to be rebuilt too? Thanks, Kevin

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

The VMI backend uses explicit page type notification to track shadow page tables. The allocation of page table roots is especially tricky. We want to clone the root for non-PAE mode while it is protected under the pgd lock. Signed-off-by: Zachary Amsden <zach@vmware.com> =================================================================== --- a/arch/i386/kernel/paravirt.c +++

The VMI backend uses explicit page type notification to track shadow page tables. The allocation of page table roots is especially tricky. We want to clone the root for non-PAE mode while it is protected under the pgd lock. Signed-off-by: Zachary Amsden <zach@vmware.com> =================================================================== --- a/arch/i386/kernel/paravirt.c +++

Hooks are provided for the mach-XXX subarchitecture at the time prior to a page being used as a page table at all levels, for PAE and non-PAE kernels. Note that in PAE mode, multiple PDP roots may exist on the same page with other data, so the root must be shadowed instead. This is not a performance issue, since PAE only uses 4 top level PDPEs. The hooks are: SetPagePTE(ppn) - indicates that a

Hooks are provided for the mach-XXX subarchitecture at the time prior to a page being used as a page table at all levels, for PAE and non-PAE kernels. Note that in PAE mode, multiple PDP roots may exist on the same page with other data, so the root must be shadowed instead. This is not a performance issue, since PAE only uses 4 top level PDPEs. The hooks are: SetPagePTE(ppn) - indicates that a

The VMI backend uses explicit page type notification to track shadow page tables. The allocation of page table roots is especially tricky. We need to clone the root for non-PAE mode while it is protected under the pgd lock to correctly copy the shadow. We don't need to allocate pgds in PAE mode, (PDPs in Intel terminology) as they only have 4 entries, and are cached entirely by the

The VMI backend uses explicit page type notification to track shadow page tables. The allocation of page table roots is especially tricky. We need to clone the root for non-PAE mode while it is protected under the pgd lock to correctly copy the shadow. We don't need to allocate pgds in PAE mode, (PDPs in Intel terminology) as they only have 4 entries, and are cached entirely by the

Greetings - Maybe I''m a bit slow, but I''ve been trying to understand how to use a module for the better part of a day and I''m not getting it. Here''s what I''ve done: Using puppet 0.23.2 1. Downloaded the shorewall module from David Schmitt''s git repo (Thanks David!!!!) and placed it in the directory /var/lib/puppet/modules (using the rpm