similar to: [PATCH 13/14] i386 / Introduce hypervisor ldt hooks

* zach@vmware.com (zach@vmware.com) wrote: > Make the LDT a desc_struct pointer, since this is what it actually is. I like that plan. > There is code which relies on the fact that LDTs are allocated in page > chunks, and it is both cleaner and more convenient to keep the rather > poorly named "size" variable from the LDT in terms of LDT pages. I noticed it's replaced

* zach@vmware.com (zach@vmware.com) wrote: > Make the LDT a desc_struct pointer, since this is what it actually is. I like that plan. > There is code which relies on the fact that LDTs are allocated in page > chunks, and it is both cleaner and more convenient to keep the rather > poorly named "size" variable from the LDT in terms of LDT pages. I noticed it's replaced

Big cleanup of LDT code. This code has very little type checking and is not frequently used, so I audited the code, added type checking and size optimizations to generate smaller assembly code. I changed the ldt count to be in pages, and converted the char * ldt into a desc_struct. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.14-zach-work/arch/i386/kernel/ldt.c

Big cleanup of LDT code. This code has very little type checking and is not frequently used, so I audited the code, added type checking and size optimizations to generate smaller assembly code. I changed the ldt count to be in pages, and converted the char * ldt into a desc_struct. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.14-zach-work/arch/i386/kernel/ldt.c

Index: linux-2.6.13/arch/i386/kernel/ldt.c =================================================================== --- linux-2.6.13.orig/arch/i386/kernel/ldt.c 2005-08-08 15:27:26.000000000 -0700 +++ linux-2.6.13/arch/i386/kernel/ldt.c 2005-08-08 21:13:19.000000000 -0700 @@ -18,6 +18,7 @@ #include <asm/system.h> #include <asm/ldt.h> #include <asm/desc.h> +#include

Index: linux-2.6.13/arch/i386/kernel/ldt.c =================================================================== --- linux-2.6.13.orig/arch/i386/kernel/ldt.c 2005-08-08 15:27:26.000000000 -0700 +++ linux-2.6.13/arch/i386/kernel/ldt.c 2005-08-08 21:13:19.000000000 -0700 @@ -18,6 +18,7 @@ #include <asm/system.h> #include <asm/ldt.h> #include <asm/desc.h> +#include

Add Xen accessors for LDT updates. Todo: Bring back return values from write_ldt_entry. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/arch/i386/kernel/ldt.c =================================================================== --- linux-2.6.13.orig/arch/i386/kernel/ldt.c 2005-08-08 21:13:56.000000000 -0700 +++ linux-2.6.13/arch/i386/kernel/ldt.c 2005-08-08

Add Xen accessors for LDT updates. Todo: Bring back return values from write_ldt_entry. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/arch/i386/kernel/ldt.c =================================================================== --- linux-2.6.13.orig/arch/i386/kernel/ldt.c 2005-08-08 21:13:56.000000000 -0700 +++ linux-2.6.13/arch/i386/kernel/ldt.c 2005-08-08

By moving init_new_context and destroy_context inline into mmu_context.h, we can avoid extra functions calls, which are only needed for the unlikely case that the process context has an LDT to deal with. Now the code in ldt.c is called only when actually dealing with LDT creation or destruction. Careful analysis of alloc_ldt function showed that by using two const parameters, huge amounts of

By moving init_new_context and destroy_context inline into mmu_context.h, we can avoid extra functions calls, which are only needed for the unlikely case that the process context has an LDT to deal with. Now the code in ldt.c is called only when actually dealing with LDT creation or destruction. Careful analysis of alloc_ldt function showed that by using two const parameters, huge amounts of

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

Big cleanup of LDT code. This code has very little type checking and is not frequently used, so I audited the code, added type checking and size optimizations to generate smaller assembly code. First, just introduce some small definitions that will be used later. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.14-zach-work/arch/i386/kernel/entry.S

Big cleanup of LDT code. This code has very little type checking and is not frequently used, so I audited the code, added type checking and size optimizations to generate smaller assembly code. First, just introduce some small definitions that will be used later. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.14-zach-work/arch/i386/kernel/entry.S

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

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

Introduce a write acessor for updating the current LDT. This is required for hypervisors like Xen that do not allow LDT pages to be directly written. Testing - here's a fun little LDT test that can be trivially modified to test limits as well. /* * Copyright (c) 2005, Zachary Amsden (zach@vmware.com) * This is licensed under the GPL. */ #include <stdio.h> #include <signal.h>

Introduce a write acessor for updating the current LDT. This is required for hypervisors like Xen that do not allow LDT pages to be directly written. Testing - here's a fun little LDT test that can be trivially modified to test limits as well. /* * Copyright (c) 2005, Zachary Amsden (zach@vmware.com) * This is licensed under the GPL. */ #include <stdio.h> #include <signal.h>

Xen requires error returns from the hypercall to update LDT entries, and this generates completely equivalent code on native. Patch-base: 2.6.13-rc5-mm1 Patch-keys: i386 desc ldt paravirt xen Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/mach-default/mach_desc.h =================================================================== ---

Xen requires error returns from the hypercall to update LDT entries, and this generates completely equivalent code on native. Patch-base: 2.6.13-rc5-mm1 Patch-keys: i386 desc ldt paravirt xen Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/mach-default/mach_desc.h =================================================================== ---