similar to: [PATCH 1/6] Page allocation hooks for VMI backend

Displaying 20 results from an estimated 1000 matches similar to: "[PATCH 1/6] Page allocation hooks for VMI backend"

2007 Apr 18
0
[PATCH 1/5] Paravirt page alloc.patch
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 +++
2007 Apr 18
0
[PATCH 1/5] Paravirt page alloc.patch
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 +++
2007 Apr 18
1
[PATCH 1/5] Add pagetable allocation notifiers
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
2007 Apr 18
1
[PATCH 1/5] Add pagetable allocation notifiers
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
2007 Apr 18
0
[RFC/PATCH PV_OPS X86_64 01/17] paravirt_ops - core changes
plain text document attachment (xx-paravirt-core.patch) Paravirt Ops core files. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/paravirt.c =================================================================== --- /dev/null +++ clean-start/arch/x86_64/kernel/paravirt.c @@ -0,0 +1,504 @@ +/*
2007 Apr 18
0
[RFC/PATCH PV_OPS X86_64 01/17] paravirt_ops - core changes
plain text document attachment (xx-paravirt-core.patch) Paravirt Ops core files. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/paravirt.c =================================================================== --- /dev/null +++ clean-start/arch/x86_64/kernel/paravirt.c @@ -0,0 +1,504 @@ +/*
2007 Apr 18
1
[RFC, PATCH 19/24] i386 Vmi mmu changes
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
2007 Apr 18
1
[RFC, PATCH 19/24] i386 Vmi mmu changes
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
2007 Apr 18
0
[PATCH 2/2] Use page present for pae pdpes
Ok, the use of "1 + " and subtraction of one for PAE PDPEs has confused many people now. Make it explicit what is going on and why anding with PAGE_MASK is a better idea to strip these bits. Signed-off-by: Zachary Amsden <zach@vmware.com> Depends-on: add-pgtable-allocation-notifiers Index: linux-2.6.13/arch/i386/mm/pgtable.c
2007 Apr 18
0
[PATCH 2/2] Use page present for pae pdpes
Ok, the use of "1 + " and subtraction of one for PAE PDPEs has confused many people now. Make it explicit what is going on and why anding with PAGE_MASK is a better idea to strip these bits. Signed-off-by: Zachary Amsden <zach@vmware.com> Depends-on: add-pgtable-allocation-notifiers Index: linux-2.6.13/arch/i386/mm/pgtable.c
2007 Apr 18
2
[PATCH] x86_64 paravirt_ops port
Hi all, I've been working on a port of paravirt_ops for the x86_64 architectures for a couple of days. Here's the result so far. I'm posting it soon for early cooments. The more, the better. It's obviously based on the previous work for i386, with the needed modifications. By now, I'm able to boot a bare metal kernel, but there are still some known issues, that are in my TODO
2007 Apr 18
2
[PATCH] x86_64 paravirt_ops port
Hi all, I've been working on a port of paravirt_ops for the x86_64 architectures for a couple of days. Here's the result so far. I'm posting it soon for early cooments. The more, the better. It's obviously based on the previous work for i386, with the needed modifications. By now, I'm able to boot a bare metal kernel, but there are still some known issues, that are in my TODO
2007 Apr 18
1
[PATCH 4/9] Vmi fix highpte
Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch
2007 Apr 18
1
[PATCH 4/9] Vmi fix highpte
Provide a PT map hook for HIGHPTE kernels to designate where they are mapping page tables. This information is required so the physical address of PTE updates can be determined; otherwise, the mm layer would have to carry the physical address all the way to each PTE modification callsite, which is even more hideous that the macros required to provide the proper hooks. So lets not mess up arch
2007 Apr 18
1
[PATCH 4/10] I386 pgd clone under lock fix.patch
Copying of the pgd range must happen under the pgd_lock. This got broken by the paravirt changes in the -mm tree. Badness can result if you copy the pgd before being added to the list when splitting or rejoining large pages. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 2247ff2c3fdb arch/i386/mm/pgtable.c --- a/arch/i386/mm/pgtable.c Thu Apr 05 17:29:15 2007 -0700 +++
2007 Apr 18
1
[PATCH 4/10] I386 pgd clone under lock fix.patch
Copying of the pgd range must happen under the pgd_lock. This got broken by the paravirt changes in the -mm tree. Badness can result if you copy the pgd before being added to the list when splitting or rejoining large pages. Signed-off-by: Zachary Amsden <zach@vmware.com> diff -r 2247ff2c3fdb arch/i386/mm/pgtable.c --- a/arch/i386/mm/pgtable.c Thu Apr 05 17:29:15 2007 -0700 +++
2007 Apr 18
17
[patch 00/17] paravirt_ops updates
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
2007 Apr 18
17
[patch 00/17] paravirt_ops updates
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
2007 Apr 18
2
pgd_alloc and [cd]tors
Is there any real use in having a ctor/dtor for the pgd cache? Given that all pgd allocation happens via pgd_alloc/pgd_free, why not just fold the [cd]tor in? I'm asking because Xen wants pgd[3] to be unshared in the PAE case, and it looks to me like the easiest way to handle that is by making pgd_alloc/free pv-ops and doing the appropriate thing in the Xen code. Would need to sort out the
2007 Apr 18
2
pgd_alloc and [cd]tors
Is there any real use in having a ctor/dtor for the pgd cache? Given that all pgd allocation happens via pgd_alloc/pgd_free, why not just fold the [cd]tor in? I'm asking because Xen wants pgd[3] to be unshared in the PAE case, and it looks to me like the easiest way to handle that is by making pgd_alloc/free pv-ops and doing the appropriate thing in the Xen code. Would need to sort out the