i386 Allow the fixmap to be relocated at boot time
PATCH 1/1 i386 Allow the fixmap to be relocated at boot time
This most curious patch allows the fixmap on i386 to be unfixed. The result is that we can create a dynamically sizable hole at the top of kernel linear address space. I know at least some virtualization developers are interested in being able to achieve this to achieve run-time sizing of a hole in which a hypervisor can live, or at least to test out the performance characteristics of different sized holes.
I have not run any performance numbers yet to see how much the cost of making this dynamic affects native performance, but again I would stress this is a highly experimental patch and I am looking for feedback and any performance data from other systems that people are kind enough to share. I'm not advocating that this get pushed into the mainline Linux tree at this point by any means!
I believe at least the Xen folks would be interested in playing around with this for experimenting with different MPT and frame table sizes for PAE support in a way that doesn't require recompiling the Linux guest each time - if the performance impact proves to be negligble, this gives a lot of flexibility to any virtual machine which runs a hypervisor aware kernel.
Although I did as much as possible to make the vsyscall relocation appear clean to userspace, I can't guarantee this patch won't set fire to your chair and electrocute your cat. Please move all pets to a safe location before attempting to use this.
Zachary Amsden <[email protected]>
Allow creation of an compile time hole at the top of linear address space.
Extended to allow a dynamic hole in linear address space, 7/2005. This required some serious hacking to get everything perfect, but the end result appears to function quite nicely. Everyone can now share the appreciation of pseudo-undocumented ELF OS fields, which means core dumps, debuggers and even broken or obsolete linkers may continue to work.
arch/i386/Kconfig +14 -0
@@ -127,6 +127,20 @@ endchoice +config RELOCATABLE_FIXMAP + bool "Allow the fixmap to be placed dynamically at runtime" + depends on EXPERIMENTAL + help + Crazy hackers only. + +config MEMORY_HOLE + int "Create hole at top of memory (0-512 MB)" + range 0 512 + default "0" + help + Useful for creating a hole in the top of memory when running + inside of a virtual machine monitor. + config ACPI_SRAT bool default y
arch/i386/kernel/sysenter.c +76 -8
98 lines not on this page · raw message
arch/i386/kernel/asm-offsets.c +4 -0
@@ -68,5 +68,9 @@ sizeof(struct tss_struct));DEFINE (PAGE_SIZE_asm,PAGE_SIZE ); +#ifdef CONFIG_RELOCATABLE_FIXMAP +DEFINE (VSYSCALL_BASE ,0 ); +#else DEFINE (VSYSCALL_BASE ,__fix_to_virt (FIX_VSYSCALL )); +#endif }
arch/i386/kernel/signal.c +4 -2
@@ -345,6 +345,8 @@See vsyscall-sigreturn.S. */ extern void __user __kernel_sigreturn;extern void __user __kernel_rt_sigreturn; +#define kernel_sigreturn (VSYSCALL_RELOCATION + (void __user *)&__kernel_sigreturn) +#define kernel_rt_sigreturn (VSYSCALL_RELOCATION + (void __user *)&__kernel_rt_sigreturn)static int setup_frame (int sig,struct k_sigaction *ka,sigset_t *set,struct pt_regs * regs)
@@ -380,7 +382,7 @@ goto give_sigsegv; } - restorer = &__kernel_sigreturn; + restorer = kernel_sigreturn;if (ka->sa.sa_flags &SA_RESTORER ) restorer = ka->sa.sa_restorer;
@@ -476,7 +478,7 @@ goto give_sigsegv;/* Set up to return from userspace. */ - restorer = &__kernel_rt_sigreturn; + restorer = kernel_rt_sigreturn;if (ka->sa.sa_flags &SA_RESTORER ) restorer = ka->sa.sa_restorer; err |=__put_user (restorer, &frame->pretcode);
arch/i386/kernel/entry.S +4 -0
@@ -200,7 +200,11 @@ pushl %ebp pushfl pushl $(__USER_CS) +#ifdef CONFIG_RELOCATABLE_FIXMAP + pushl %ss:SYSENTER_RETURN_ADDR +#else pushl $SYSENTER_RETURN +#endif /* * Load the potential sixth argument from user stack.
arch/i386/mm/init.c +10 -0
@@ -42,6 +42,10 @@unsigned int __VMALLOC_RESERVE =128 <<20 ; +#ifdef CONFIG_RELOCATABLE_FIXMAP +unsigned long __FIXADDR_TOP =0 ; +#endif + DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);unsigned long highstart_pfn, highend_pfn;
@@ -478,6 +482,12 @@printk ("NX (Execute Disable) protection: active\n" );#endif +#ifdef CONFIG_RELOCATABLE_FIXMAP +if (!__FIXADDR_TOP) + __FIXADDR_TOP =0xfffff000UL -(CONFIG_MEMORY_HOLE <<20 ); +printk (KERN_INFO "Fixmap top relocated to %lxh\n" , __FIXADDR_TOP); +#endif +pagetable_init ();load_cr3 (swapper_pg_dir);
include/asm-i386/fixmap.h +7 -1
@@ -20,7 +20,13 @@* Leave one empty page between vmalloc'ed areas and * the start of the fixmap. */ -#define __FIXADDR_TOP 0xfffff000 +#ifdef CONFIG_RELOCATABLE_FIXMAP +extern unsigned long __FIXADDR_TOP; +#define VSYSCALL_RELOCATION __fix_to_virt(FIX_VSYSCALL) +#else +#define __FIXADDR_TOP (0xfffff000-(CONFIG_MEMORY_HOLE << 20)) +#define VSYSCALL_RELOCATION 0 +#endif #ifndef __ASSEMBLY__#include <linux/kernel.h>
include/asm-i386/elf.h +1 -1
@@ -129,7 +129,7 @@#define VSYSCALL_BASE (__fix_to_virt(FIX_VSYSCALL))#define VSYSCALL_EHDR ((const struct elfhdr *) VSYSCALL_BASE) -#define VSYSCALL_ENTRY ((unsigned long) &__kernel_vsyscall) +#define VSYSCALL_ENTRY ((unsigned long) (VSYSCALL_RELOCATION+&__kernel_vsyscall))extern void __kernel_vsyscall;#define ARCH_DLINFO \
include/linux/elf.h +3 -0
@@ -138,6 +138,9 @@#define DT_DEBUG 21#define DT_TEXTREL 22#define DT_JMPREL 23 +#define DT_VERSYM 0x6ffffff0 +#define DT_VERDEF 0x6ffffffc +#define DT_VERNEED 0x6ffffffe#define DT_LOPROC 0x70000000#define DT_HIPROC 0x7fffffff
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 6 lines · * Zachary Amsden ([email protected]) wrote:
This most curious patch allows the fixmap on i386 to be unfixed. The result is that we can create a dynamically sizable hole at the top of kernel linear address space. I know at least some virtualization developers are interested in being able to achieve this to achieve run-time sizing of a hole in which a hypervisor can live, or at least to test out the performance characteristics of different sized holes.
I've done it simpler with keeping it fixed but defined by the subarch. Patch is stupid simple (and untested). Do you think there's a huge gain for dynamically sizing?
include/asm-i386/fixmap.h +1 -74
@@ -15,82 +15,9 @@#include <linux/config.h> -/* used by vmalloc.c, vsyscall.lds.S. -* -* Leave one empty page between vmalloc'ed areas and -* the start of the fixmap. -*/ -#define __FIXADDR_TOP 0xfffff000 +#include <mach_fixmap.h> #ifndef __ASSEMBLY__ -#include <linux/kernel.h> -#include <asm/acpi.h> -#include <asm/apicdef.h> -#include <asm/page.h> -#ifdef CONFIG_HIGHMEM -#include <linux/threads.h> -#include <asm/kmap_types.h> -#endif - -/* -* Here we define all the compile-time 'special' virtual -* addresses. The point is to have a constant address at -* compile time, but to set the physical address only -* in the boot process. We allocate these special addresses -* from the end of virtual memory (0xfffff000) backwards. -* Also this lets us do fail-safe vmalloc(), we -* can guarantee that these special addresses and -* vmalloc()-ed addresses never overlap. -* -* these 'compile-time allocated' memory buffers are -* fixed-size 4k pages. (or larger if used with an increment -* highger than 1) use fixmap_set(idx,phys) to associate -* physical memory with fixmap indices. -* -* TLB entries of such buffers will not be flushed across -* task switches. -*/ -enum fixed_addresses { -FIX_HOLE , -FIX_VSYSCALL , -#ifdef CONFIG_X86_LOCAL_APIC -FIX_APIC_BASE ,/* local (CPU) APIC) -- required for SMP or not */ -#endif -#ifdef CONFIG_X86_IO_APIC -FIX_IO_APIC_BASE_0 , -FIX_IO_APIC_BASE_END =FIX_IO_APIC_BASE_0 +MAX_IO_APICS -1 , -#endif -#ifdef CONFIG_X86_VISWS_APIC -FIX_CO_CPU ,/* Cobalt timer */ -FIX_CO_APIC ,/* Cobalt APIC Redirection Table */ -FIX_LI_PCIA ,/* Lithium PCI Bridge A */ -FIX_LI_PCIB ,/* Lithium PCI Bridge B */ -#endif -#ifdef CONFIG_X86_F00F_BUG -FIX_F00F_IDT ,/* Virtual mapping for IDT */ -#endif -#ifdef CONFIG_X86_CYCLONE_TIMER -FIX_CYCLONE_TIMER ,/*cyclone timer register*/ -#endif -#ifdef CONFIG_HIGHMEM -FIX_KMAP_BEGIN ,/* reserved pte's for temporary kernel mappings */ -FIX_KMAP_END =FIX_KMAP_BEGIN +(KM_TYPE_NR *NR_CPUS )-1 , -#endif -#ifdef CONFIG_ACPI_BOOT -FIX_ACPI_BEGIN , -FIX_ACPI_END =FIX_ACPI_BEGIN +FIX_ACPI_PAGES -1 , -#endif -#ifdef CONFIG_PCI_MMCONFIG -FIX_PCIE_MCFG , -#endif - __end_of_permanent_fixed_addresses, -/* temporary boot-time mappings, used before ioremap() is functional */ -#define NR_FIX_BTMAPS 16 - FIX_BTMAP_END = __end_of_permanent_fixed_addresses, -FIX_BTMAP_BEGIN =FIX_BTMAP_END +NR_FIX_BTMAPS -1 , -FIX_WP_TEST , - __end_of_fixed_addresses -};extern void __set_fixmap (enum fixed_addresses idx,unsigned long phys,pgprot_t flags);
include/asm-i386/mach-default/mach_fixmap.h +93 -0
93 lines not on this page · raw message
Quoted 11 lines · Chris Wright
Quoted 3 lines · * Zachary Amsden ([email protected]) wrote:
This most curious patch allows the fixmap on i386 to be unfixed. The result is that we can create a dynamically sizable hole at the top of kernel linear address space. I know at least some virtualization developers are interested in being able to achieve this to achieve run-time sizing of a hole in which a hypervisor can live, or at least to test out the performance characteristics of different sized holes.
I've done it simpler with keeping it fixed but defined by the subarch. Patch is stupid simple (and untested). Do you think there's a huge gain for dynamically sizing?
Your patch looks good, although the minimal change to subarch is to merely have __FIXADDR_TOP defined by the sub-architecture. Is there any additional benefit to moving the fixmaps into the subarch - i.e. moving subarch-specific pieces out of mach-default?
I guess there is. For example include/asm-i386/mach-visws/mach_fixmap.h could do this:
#define SUBARCH_FIXMAPS \
FIX_CO_CPU, /* Cobalt timer */ \
FIX_CO_APIC, /* Cobalt APIC Redirection Table */ \
FIX_LI_PCIA, /* Lithium PCI Bridge A */ \
FIX_LI_PCIB, /* Lithium PCI Bridge B */Then include/asm-i386/fixmap.h includes <mach_fixmap.h>, for which the default is an empty define for SUBARCH_FIXMAPS.
And then you don't have to maintain the list of common fixmaps across the sub-architecture layer or uglify the top level fixmaps with SGI Visual Workstation support.
Also, it seems reasonable that people may want to poke holes in high linear space for other hypervisor projects, research, or performance reasons without having to build a custom sub-architecture just for that. So I think there is some benefit to making the hole size a general configurable option (with defaults depending on the sub-arch you select).
I have no idea if the dynamic sizing has any performance impact yet, but it may be a big win in terms of flexibility. I would be curious to hear more from the Xen core team (I know Ian mentioned he would like to try this out at one point in time).
Zach
Quoted 4 lines · * Zachary Amsden ([email protected]) wrote:
Your patch looks good, although the minimal change to subarch is to merely have
__FIXADDR_TOPdefined by the sub-architecture. Is there any additional benefit to moving the fixmaps into the subarch - i.e. moving subarch-specific pieces out of mach-default?
As you've identified, so subarch can put whatever wonky junk it needs in there.
Quoted 11 lines
I guess there is. For example
include/asm-i386/mach-visws/mach_fixmap.hcould do this:#define SUBARCH_FIXMAPS \ FIX_CO_CPU, /* Cobalt timer */ \ FIX_CO_APIC, /* Cobalt APIC Redirection Table */ \ FIX_LI_PCIA, /* Lithium PCI Bridge A */ \ FIX_LI_PCIB, /* Lithium PCI Bridge B */Then
include/asm-i386/fixmap.hincludes <mach_fixmap.h>, for which the default is an empty define forSUBARCH_FIXMAPS.
nice.
Quoted 6 lines
Also, it seems reasonable that people may want to poke holes in high linear space for other hypervisor projects, research, or performance reasons without having to build a custom sub-architecture just for that. So I think there is some benefit to making the hole size a general configurable option (with defaults depending on the sub-arch you select).
It needs to have tangible value for in-tree code. Seems worthwhile to play with it a bit though.
thanks,
-chris
Quoted 6 lines · Zachary Amsden
Also, it seems reasonable that people may want to poke holes in high linear space for other hypervisor projects, research, or performance reasons without having to build a custom sub-architecture just for that. So I think there is some benefit to making the hole size a general configurable option (with defaults depending on the sub-arch you select).
qemu-fast needs a kernel with __FIXADDR_TOP 0xa7fff000, and PAGE_OFFSET 0x90000000. I used to continually patch my kernels, but these days I just run full qemu and take the speed hit. If this was easier, it would be really nice to have that speed back.
Rusty.
Signature · 1 line
A bad analogy is like a leaky screwdriver -- Richard Braakman