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