[PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
The following series of patches implement support for a relocatable kernel by building it as a position-independent executable (PIE). When the linker is given the -pie flag, it creates an executable that contains dynamic relocations which can be used to relocate the image at boot time for any desired base address. This patch series adds a CONFIG_RELOCATABLE config option for 64-bit which links the kernel with -pie and arranges to process the relocations in early boot. With the first 4 patches applied, a relocatable kernel will still copy itself down to real address 0. The last patch changes things so that a relocatable kernel will run wherever it was loaded. This last patch is pretty much just a proof of concept since it doesn't do anything to ensure appropriate alignment of the base address (the base address needs to be 16kB aligned). We probably want to work out whether we are a kdump kernel and run in-place if so, or copy down to 0 if not. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Hi Paul,
I can't boot zImage with your patches. I'm getting the following error
message from prom_init.c
Error: You can't boot a kdump kernel from OF!
This is due to the check:
if (PHYSICAL_START > 0)
prom_panic("Error: You can't boot a kdump kernel from OF!\n");
where PHYSICAL_START is kernstart_addr, and this variable needs to be
referred through RELOC macro
But even after commenting the above check, I am not able to boot zImage.
Building dt structure...
Device tree strings 0x02ce4000 -> 0×02ce5034
Device tree struct 0×02ce6000 -> 0×02cf
Calling quiesce …
returning from prom_init
and the system hangs
It has CONFIG_RELOCATABLE set, (CONFIG_CRASH_DUMP is not set).
I even tried booting zImage through netboot, it also fails at the same
place.
If you need, I can give the .config I use.
Regards,
Mohan.
Paul Mackerras wrote:
The following series of patches implement support for a relocatable
kernel by building it as a position-independent executable (PIE).
When the linker is given the -pie flag, it creates an executable that
contains dynamic relocations which can be used to relocate the image
at boot time for any desired base address. This patch series adds a
CONFIG_RELOCATABLE config option for 64-bit which links the kernel
with -pie and arranges to process the relocations in early boot.
With the first 4 patches applied, a relocatable kernel will still copy
itself down to real address 0. The last patch changes things so that
a relocatable kernel will run wherever it was loaded. This last patch
is pretty much just a proof of concept since it doesn't do anything to
ensure appropriate alignment of the base address (the base address
needs to be 16kB aligned). We probably want to work out whether we
are a kdump kernel and run in-place if so, or copy down to 0 if not.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Mohan Kumar M writes: > If you need, I can give the .config I use. Yes please, send it over. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Hi Paul, Attaching the .config Paul Mackerras wrote: Mohan Kumar M writes: If you need, I can give the .config I use. Yes please, send it over. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27-rc1 # Mon Aug 18 14:24:37 2008 # CONFIG_PPC64=y # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=128 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_GET_USER_PAGES_FAST=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_GROUP_SCHED is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_PROC_PID_CPUSET=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_MARKERS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_CLK is not set CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" CONFIG_CLASSIC_RCU=y # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_SCANLOG=m CONFIG_LPARCFG=y CONFIG_PPC_PSERIES_DEBUG=y # CONFIG_PPC_SMLPAR is not set # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_XICS=y # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set CONFIG_PPC_I825
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Mohan Kumar M writes: > Attaching the .config Hmmm, your config works for me on a POWER6 partition here, whether I netboot the zImage.pseries or boot it with yaboot. I wonder if your toolchain is an older version. What is the output from ld --version and gcc --version? Also, could you send me off-list your compiled vmlinux? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Paul Mackerras wrote: Mohan Kumar M writes: Attaching the .config Hmmm, your config works for me on a POWER6 partition here, whether I netboot the zImage.pseries or boot it with yaboot. I wonder if your toolchain is an older version. What is the output from ld --version and gcc --version? # ld --version GNU ld version 2.16.91.0.5 20051219 (SUSE Linux) # gcc --version gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux) If the problem is related to toolchain version, which one you recommend to test? Also, could you send me off-list your compiled vmlinux? You can download the zipped vmlinux at http://mohankumar.m.googlepages.com/vmlinux.gz Regards, Mohan. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
On Wed, 2008-08-13 at 11:27 +1000, Paul Mackerras wrote: > The following series of patches implement support for a relocatable > kernel by building it as a position-independent executable (PIE). > When the linker is given the -pie flag, it creates an executable that > contains dynamic relocations which can be used to relocate the image > at boot time for any desired base address. This patch series adds a > CONFIG_RELOCATABLE config option for 64-bit which links the kernel > with -pie and arranges to process the relocations in early boot. > > With the first 4 patches applied, a relocatable kernel will still copy > itself down to real address 0. The last patch changes things so that > a relocatable kernel will run wherever it was loaded. This last patch > is pretty much just a proof of concept since it doesn't do anything to > ensure appropriate alignment of the base address (the base address > needs to be 16kB aligned). We probably want to work out whether we > are a kdump kernel and run in-place if so, or copy down to 0 if not. Is this mature enough for us to consider putting it in Fedora? We'd _love_ to stop building a separate kdump kernel for ppc64... -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
On Aug 28, 2008, at 7:12 AM, David Woodhouse wrote: On Wed, 2008-08-13 at 11:27 +1000, Paul Mackerras wrote: The following series of patches implement support for a relocatable kernel by building it as a position-independent executable (PIE). When the linker is given the -pie flag, it creates an executable that contains dynamic relocations which can be used to relocate the image at boot time for any desired base address. This patch series adds a CONFIG_RELOCATABLE config option for 64-bit which links the kernel with -pie and arranges to process the relocations in early boot. With the first 4 patches applied, a relocatable kernel will still copy itself down to real address 0. The last patch changes things so that a relocatable kernel will run wherever it was loaded. This last patch is pretty much just a proof of concept since it doesn't do anything to ensure appropriate alignment of the base address (the base address needs to be 16kB aligned). We probably want to work out whether we are a kdump kernel and run in-place if so, or copy down to 0 if not. Is this mature enough for us to consider putting it in Fedora? We'd _love_ to stop building a separate kdump kernel for ppc64... Also, can we get this on ppc32 (head_32.S)? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
On Thu, 28 Aug 2008, David Woodhouse wrote: > On Wed, 2008-08-13 at 11:27 +1000, Paul Mackerras wrote: > > The following series of patches implement support for a relocatable > > kernel by building it as a position-independent executable (PIE). > > When the linker is given the -pie flag, it creates an executable that > > contains dynamic relocations which can be used to relocate the image > > at boot time for any desired base address. This patch series adds a > > CONFIG_RELOCATABLE config option for 64-bit which links the kernel > > with -pie and arranges to process the relocations in early boot. > > > > With the first 4 patches applied, a relocatable kernel will still copy > > itself down to real address 0. The last patch changes things so that > > a relocatable kernel will run wherever it was loaded. This last patch > > is pretty much just a proof of concept since it doesn't do anything to > > ensure appropriate alignment of the base address (the base address > > needs to be 16kB aligned). We probably want to work out whether we > > are a kdump kernel and run in-place if so, or copy down to 0 if not. > > Is this mature enough for us to consider putting it in Fedora? We'd > _love_ to stop building a separate kdump kernel for ppc64... I tried CONFIG_RELOCATABLE=y on PS3 a while ago, and the resulting kernel locked up during early boot. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
David Woodhouse writes: > Is this mature enough for us to consider putting it in Fedora? We'd > _love_ to stop building a separate kdump kernel for ppc64... Almost, but not quite. We'll need some modifications to yaboot (it refuses to accept an ET_DYN image, for instance), plus I'm currently seeing a puzzling crash inside OF on POWER5 when the image is loaded from yaboot but not when it's been loaded by netbooting the wrapper (having hacked the ELF header of vmlinux to make it an ET_EXEC so yaboot would touch it). The main remaining substantial technical issue is how we detect very early on that we are a kdump kernel. I think the policy should be that the kernel copies itself down to 0 if it's not a kdump kernel and runs wherever it was loaded if it's a kdump kernel. The only way to tell whether we're a kdump kernel seems to be to look at the kernel command line, which is a little tricky to do in head_64.S when the command line is buried inside the DTB. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Kumar Gala writes: > Also, can we get this on ppc32 (head_32.S)? Probably. I'll give it a go. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
From: Paul Mackerras <[EMAIL PROTECTED]> Date: Fri, 29 Aug 2008 15:40:36 +1000 > The main remaining substantial technical issue is how we detect very > early on that we are a kdump kernel. I think the policy should be > that the kernel copies itself down to 0 if it's not a kdump kernel and > runs wherever it was loaded if it's a kdump kernel. The only way to > tell whether we're a kdump kernel seems to be to look at the kernel > command line, which is a little tricky to do in head_64.S when the > command line is buried inside the DTB. Why not put a key at a fixed location in the .text section or similar? Then you can access it using PC relative addressing, and whatever loads the kdump kernel can put an appropriate value there. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
