| Age | Commit message (Collapse) | Author |
|---|
|
The generated code is byte-for-byte identical.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The entry16 and entry16_debug functions need to compute appropriate 16-bit
segments before dropping to real mode. Each is intended to use its own
entry address as the segment base. However, both were using the entry
address of entry16_debug, causing the code-segment reload to branch to the
wrong place in the non-debug case.
This bug was only visible when running kexec with --real-mode and without
--debug.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The undefined symbols naturally weren't relocated by kexec's linker, so
each compiled `call` instruction branched into the middle of itself. The
CPU proceeded to interpret the un-relocated address as instructions,
resulting in an undefined opcode fault. Since at this point no IDT is
loaded, that turned into a triple-fault and reboot.
The bug was only visible when running kexec with --console-vga.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
From: Simon Horman <horms@verge.net.au>
Fix a typo and distribute $(mips_PURGATORY_SRCS) instead of
$(mips_PURGATORY_C_SRCS) as the latter is empty.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Sometimes I write nonsensical notes. When I wrote the comment
in purgatory/arch/x86_64/Makefile it was one of those times.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes kexec-tools on x86_64. The build had two problems:
1. The distribution missed the files
purgatory/arch/x86_64/entry64-32.S,
purgatory/arch/x86_64/entry64.S,
purgatory/arch/x86_64/setup-x86_64.S,
purgatory/arch/x86_64/stack.S,
purgatory/arch/x86_64/purgatory-x86_64.c
The problem was that variable expansion in a Makefile is a bit different
from the expectation, i.e. the final value is used even if the variable is
used in the middle.
2. The build didn't include the files mentioned above. This was because of
using '=' instead of '+=' in the 2nd part of the Makefile.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mips/include/limits.h from distribution
as it no longer exists.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
[ Reposted with correct linux-mips address ]
Hi,
this patch switches the mips support in kexec-tools around a little bit.
All the files and directories containing "mipsel" have been renamed
to contain "mips" instead.
This is kind of consistent with the way that ARCH=mips in the kernel
works for both big and little endian.
After a small amount of tweaking, which is also included in this patch, the
code compiles and works fine for big endian mips as well as small endian
mips. All you need to do is compile using an appropriate compiler.
That is to say, kexec-tools's build system doesn't need to
be told about which endienness the code is being compiled for.
I have added kept mipsel as a supported "architecture" via ./configure,
though its just an alias for mips now. This is consistent with how
other architectures such as sh are treated. But I'm happy to remove
mipsel from ./configure if the mips people want that.
I tested this patch using qemu and the 2.6.24.3 tag of the mips-2.6 git
tree compiled for the qemu machine type for both big and little endian.
The qemu machine type has subsequently been removed, and kexec-tools
needs some work in order to function with qemu - as far as I understand
the way the boot parameters are passed needs to be fixed, likely
in purgatory. However, this is not related to the changes
introduced in this patch.
I intend to merge this patch into kexec-tools-testing if
no alarm bells are sounded.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
While trying to test latest kexec tools git code on a x86_64
box i ran into following issue. Kexec refused to load both
kexec and kdump kernels.
# ./build/sbin/kexec -l /boot/vmlinuz-2.6.25-rc5 --initrd=/boot/initrd-2.6.25-rc5
Symbol: entry32_regs not found cannot get
#
# ./build/kexec -p /boot/vmlinux-kdump --initrd=/boot/initrd-kdump
--append="...."
Symbol: entry64_regs not found cannot get
#
It turns out that entry64.S file under purgatory/arch/x86_64 was not
compiled. The original x86_64_PURGATORY_SRCS were being overwritten
in the Makefile.
Signed-Off-By: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mipsel/include/limits.h as it is not needed.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mipsel/include/stdint.h as it just duplicates
things found in system header files.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hello,
We developed a patch to port kexec-tools to mips arch and included support for
command line passing through elf boot notes.
We did it for a customer of ours on a specific platform derived from toshiba
tx4938 (so we think it should work at least for tx4938 evaluation board also).
We would like to contribute it in case somebody else needs it or wants to
improve it.
This patch works for us but the assembler part in particular, should be
considered as a starting point because my assembly knowledge is not too deep.
As this is the first time I submit a patch I tried to guess reading tpp.txt if
this is the right way to submit. Please let me know about any mistakes I may
have made.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
From my observations the way that the EFI_LOAD_DATA is provided
on the inital boot works like this:
There is a large EFI_CONVENTIONAL_MEMORY region.
The portion begining at the first load segment of
the image to be loading and ending with the last segment,
aligned to 64K, is turned into a separate region
of type EFI_LOAD_DATA.
A truncated example of this:
...
mem04: type= 7, attr=0x0000000000000008, range=[0x0000000000100000-0x0000000004000000) ( 63MB)
mem05: type= 2, attr=0x0000000000000008, range=[0x0000000004000000-0x000000000481f000) ( 8MB)
mem06: type= 7, attr=0x0000000000000008, range=[0x000000000481f000-0x000000003e876000) ( 928MB)
...
Where type 7 is EFI_CONVENTIONAL_MEMORY and
type 3 is EFI_LOAD_DATA.
There is a patch to the user-space portion of kexec-tools that merges the
segments supplied to this code if they are adjacent. This seems to always
result in a single segment being passed to this code, that should start
at the same address as the existing EFI_LOAD_DATA segment.
So all that should be left to do is to merge the existing
EFI_LOAD_DATA region with the following EFI_CONVENTIONAL_MEMORY region,
and then split it up to accommodate the segment passed from user-space.
The new EFI_LOAD_DATA region created with this code will always
start at the same address as the old EFI_LOAD_DATA region. If
this proves to be overly simplistic it should be easy to update.
This code also allows merging of multiple regions to accommodate
the new EFI_LOAD_DATA region. I strongly doubt this will ever
be used, but it is in line with the way the existing code works.
If the same image is used after kexec, then the
EFI regions in question will turn out the same as the original regions.
This is important, otherwise kernel / hypervisor regions will not be able
to be inserted into /proc/iomem / /proc/iomem_machine.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With the recent build changes a number of unneded files
crept into tarballs, including .o and .d files.
This patch is farily verbose, but hopefully in the long
run this system will be obvious enough to be maintainable.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add ARM support to kexec including commandline support through ATAGs.
The kernel syscall support has already been merged and kernel ATAG
exporting is queued for 2.6.25 (its optional for kexec).
Based on work by various people, notably Uli Luckas <u.luckas@road.de>
for adding ATAG support.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since we use the implicit ruls for .c and .S, just colelct all sources
in the one variable.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Purgatory seems to partially duplicate system headers.
It seems a log cleaner not to do so.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This change makes kexec-tools work more like a standard configure-make-
make-install-type project:
* Remove $(OBJDIR) stuff. To do an out-of-tree build, just configure
from a different directory.
* Use the implicit Makefile rules more, and just edit the compiler
flags for specific targets.
* Simplify compiler/linker flags - no need for EXTRA_*
* Add TARGET_CC, and improve checks for BUILD_CC too.
* Set arch-specific flags in arch-specific makefiles, not conditional
on $(ARCH).
* Generate dependency files in the main compile, rather than as a
separate step.
* Don't #include sha256.c, but re-build it into the purgatory.
Still a work-in-progress.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Based on
http://cvs.fedora.redhat.com/viewcvs/rpms/kexec-tools/devel/kexec-tools-1.101-ppc-boots-ppc64.patch?rev=1.2&view=auto
64 bit: OK
32 bit: purgatory build fails
Work-in-progress-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Purgatory doesn't really care about the SMP cpus. But if we leave them
behind, they end up getting lost when the kernel overwrites purgatory or
the previous kernel. The current slave handling in purgatory doesn't
have any handshaking to make sure the cpus have moved on before leaving.
Instead of moving the slave cpus up to purgatory and then back down to
the kernel, just copy bytes 4-255 from the kernel and use it as the
purgatory start / slave hold block.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The address where the ELF core header is stored is passed to the secondary
kernel as a kernel command line option. The memory area for this header is
also marked as a separate EFI memory descriptor on ia64.
The separate EFI memory descriptor is at the moment of the type
EFI_UNUSABLE_MEMORY. With such a type the secondary kernel skips over the
entire memory granule (config option, 16M or 64M) when detecting memory.
If we are lucky we will just lose some memory, but if we happen to have data
in the same granule (such as an initramfs image), then this data will never
get mapped and the kernel bombs out when trying to access it.
So this is an attempt to fix this by changing the EFI memory descriptor
type into EFI_LOADER_DATA. This type is the same type used for the kernel
data and for initramfs. In the secondary kernel we then handle the ELF core
header data the same way as we handle the initramfs image.
This strategy requires changes in the secondary kernel as well, I'll
post the kernel patches in a little while.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Patch found on
http://eggplant.ddo.jp/www/download/debian26/source/kexec-tools/kexec-tools_1.101-2sh.diff.gz
According to Paul Mundt <lethal@linux-sh.org> it was originally by
kogiidena <kogiidena@eggplant.ddo.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Magnus Damm <magnus.damm@gmail.com>
|
|
Hi,
I've run into problems testing kexec/kdump on a Montecito revision C
processor. In purgatory, __dummy_efi_function is copied onto the end of
the command line boot parameter (command_line + command_line_len) and this
address is used to replace the EFI call to set_virtual_address_map(). The
copied range is then icache flushed.
The destination address is aligned to 16-bytes (in kexec-elf-ia64.c), but
the fc.i instruction flushes a 32-byte range "associated" with that
address. When my command line length is 16-byte aligned but not 32-byte
aligned, this results in the first 16-bytes of __dummy_efi_function getting
flushed (and the 16 bytes prior to that), but the second half of the
function (the part with the br.ret) does not get flushed. kdump then hangs
in purgatory. By adding a few spaces to my command line, it becomes both
16 and 32-byte aligned, and kdump works.
This patch makes icache_flush_range() align the start address to 32-bytes
and account for the difference. The patch is against Horms
kexec-tools-testing tree. As a side note, you could also fix this by just
adding 32 to the length passed to flush_icache_range() but that hides the
dependent behavior.
Thanks,
-T
It seems I was always testing with command line more than 16 bytes
length.....
Thanks.
Acked-by: Zou Nan hai <nanhai.zou@intel.com>
Manually applied - not sure why that was neccessary.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This adds vmm support to kexec-tool for ia64. This is annalogous
to the same feature that is present in the latest version of elilo.
It is a method of booting a vmm (hypervisor) such as Xen.
Essentially it works as follows.
* If the --vmm argument is not provided, then the kernel is booted as normal,
no changes
* Else, the image specified by --vmm is placed loaded into the elf
segments, where the Linux kernel image would otherwise have gone.
And the Linux kernel image, allong with its length is loaded into a
seprate segment, and passed as new entry at the end of the boot parameters.
This is somewhat similar to how initramfs/initramd images are passed
to a booting kernel, and can work in conjunction with that feature.
On boot (or in this case on kexec) the vmm (hypervisor) will be
loaded instead of a Linux kernel, and the hypervisor will then load up
the Linux kernel as it sees fit.
This is needed in order for kexec from Xen to Xen, using the
port of kexec to Xen that I am working on, to work.
I am not entirely fond of this design, and i think that developing
an ia64 variant of multiboot would be much nicer. However it is
an existing method that is currently in widespread use through
its incarntation in elilo. And if multiboot is added in future,
it can be done as a separate boot method, and thus orthogonal to this
patch.
In order to use this code a number of other changes are needed,
in particular:
1. Xen and the corresponding Linux Kernel needs to be patched with
the port of kexec to ia64-xen that I have been working on.
I will post the latest version of these patches to xen-devel
shortly.
2. The currently hardcoded PAGE_OFFSET value in purgatory needs
to be changed from the Linux value to the Xen value. I will
post a very hackish, definately not to be released, patch
after this patch which includes a comment that explains this problem
more clearly.
Also, xen->linux and linux->xen is still very much work in progress due
to the problem described at the following link
http://permalink.gmane.org/gmane.linux.ports.ia64/14995
However, from an infastructure point of view I think it would be good to
apply this code, so that kexec-tool is one step closer to being able to
support vmms (hypervisors). The patch does not alter any existing
behaviour, it just adds a new feature. Bugs asside, the only real danger
seems to be confusion for end-users, perhaps we could comment out the help
text to hide the feature from the lay user, or attach a big fat warning to it.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Add a more verbose comment to explain why set_virtual_address_map is
replaced why a dummy function
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This unifies the comments in purgatory-ia64.c to always use C style
comments. Previously some comments where C style, while others were
C++ style.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This makes the tail of patch_efi_memmap() slightly less nested,
and thus a little easier to read.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Just use boot_param->efi_memdesc_size directly instead, it seems
at least as clean, and possibly easier to follow.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
len is assigned once and used once, just use boot_param->efi_memmap_size
directly instead.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
* Rename md1 and md2 to md_src and md_dest respectively to make things
a little easier to follow.
* Remove p1 and p2, use src and dest instead
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
There is a farily complex if, for construct in patch_efi_memmap(),
that seems to be simplifyable to a somewhat simpler while statement.
Note that this does change the logic statement. In particular
the original code has if (seg->end < mend) towards the end,
and the new code effectively replaces this with if (seg->end <= mend).
However, in the original code this is copled with a separate
if (seg->end > mend) check at the begining, so I believe that
this is actually a minor (possibly never seen) logic error in
the original code. The node code just always checks (seg->end > mend).
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This patch removes a duplicated assignment of *md2.
It also replaces a switch statement with an if statement
which is much more compact in this instance.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This patch reduces the nesting in patch_efi_memmap() by
jumping to the next interation of the inner for loop
if the following condition is true.
if (seg->start < mstart || seg->start >= mend)
This is instead of a reasonably large ammount of code inside the if
conditional if the converse is true.
This makes things somewhat easier to read as the nesting is already
quite deep, and many lines do not fit easily within 80 columns.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Make purgatory code 80 columns wide
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Remove kexec/arch/ia64/kexec-ia64.h.orig and purgatory/arch/ia64/Makefile.orig
which were (presumably accidently) introduced in changest
9241000f28eb6b86a06c0be2d6cf31498373bc1c, "kdump ia64".
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
SN platform support PIO in a different way to generic IA64 platform. It
does not support most of the legacy I/O ports.
Give an --noio option to kexec-tools to disable I/O in purgatory code.
This patch also removed an unused io.h in kexec-tools.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Edited to consistently use tabs instead of spaces for intentation,
remove one instance of trailing whitespace, and fix indentation
of noio line in options[].
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Currently DEBUG macro is being used at some places by purgatory code. We
need this DEBUG macro to be defined by user at compile time for including
or excluding the debug code. -DDEBUG is more common practice to use for
this purpose. Hence, changing DEBUG() to DEBUG_CHAR() and make space
for DEBUG to be defined by user.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
without this patch, crash tool will not able to analyze efi memmap of
first kernel from vmcore file.
This patch is against kexec-tools-1.101 with kdump10 patch.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Removed bogus fragments caused by whitespace addition
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The purgatory code in kexec-tools does not currently setup CS when booting a
64-bit ELF file such as a vmlinux file. This together with the fact that the
Linux kernel doesn't reload CS properly if booted from the 64-bit entry point
means that booting a vmlinux may fail under certain conditions.
The only known combination that triggers this problem is when kexec-tools and
kexec are used to load a x86_64 vmlinux under a dom0 Linux running under the
Xen hypervisor.
This patch is needed for sure to reload kernels with version <= 2.6.17. There
are fixes for this problem in the URL below, but if a fix will be included in
2.6.18 or not is unknown at this time.
http://permalink.gmane.org/gmane.linux.kernel/438998
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Removed some trailing whitespace
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Get rid of multiple definitions of backup region.
o Give more relevant name to backup source region.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
On Thu, Jul 27, 2006 at 12:32:56PM -0600, Eric W. Biederman wrote:
>
> I have found a couple of moments and have been able to
> catch up with most of the backlog of patches for kexec-tools.
> There are several details I need to follow up on, and there is
> some testing I want to do to make certain everything is working.
>
> The primary kexec-tools archive is:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools.git
>
> An archive to hold versions before 1.101 is at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools-historic.git
>
> So far I have all version in there since 1.0 except 1.9, 1.92, and 1.93
> if someone happens to have a copy point me at it and I will update the
> history.
>
> Patches that hang out in quilt for a while can be annoying to import
> into git because their authorship information is not stored in an
> unambiguous way. git is general is much stricter about the format
> it's meta-data information is stored in.
>
> Maneesh in kdump10 there were two patches in particular that I have
> not sorted out their who wrote them. If you could help me sort that
> out I would appreciate it.
>
> ppc64-initrd-option.patch
> ppc64-kdump-device_tree-sort.patch
>
> Before I make a release here is my list of things I intend to look at:
> - Why we have defined the location of the crash backup region twice.
Hi Eric,
Are you referring to BACKUP_REGION_START and BACKUP_START declarations?
I am not sure why did I do that, may be somehow I thought that purgatory
code is not sharing the header files with main kexec code base.
Please have a look at the patch attached for i386. If this looks
fine, I shall generate the patches for x86_64 and ppc64 too.
Thanks & Regards
Vivek
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
On Fri, 2006-06-09 at 19:50, Welterlen Benoit wrote:
> Zou Nan hai wrote:
> > The ia64 kdump patch is in 2 parts.
> >
> > the kexec-kdump-ia64-2.6.16.patch should apply on top of the previous
> > kexec patch by Khalid in Tony's test tree.
> >
> > the kexec-tools-kdump-ia64.patch should apply to kexec-tools-1.101
> > with kexec-tools-1.101-kdump.patch
> >
> >
> > To test it.
> > Build first SMP kernel with KEXEC and KDUMP enabled.
> >
> > Boot it with kernel parameter "crashkernel=XXX@YYY"
> > means reserver XXX from YYY for crashdumping.
> > Build an UP kernel with KEXEC KDUMP VMCORE enabled.
> > load this kernel as a crashdumping kernel
> > kexec -p vmlinux.gz --initrd=initrd --append="...."
> >
> > trigger a crash,
> > maybe "echo c > /proc/sysrq-trigger"
> > after the crash kernel boots,
> > cp /proc/vmcore core
> >
> > gdb first_kernel_vmlinux core
> >
> > please test and review.
> >
> > Signed-off-by: Khalid Aziz <khalid_aziz@hp.com>
> > Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
> >
> >
> > https://lists.osdl.org/mailman/listinfo/fastboot
> >
>
> Hello Nan hai,
>
> I tried your patches. It seems that the kexec-tools-kdump-ia64.patch
> file can not be applied after the latest release of kexec-tools
> http://lse.sourceforge.net/kdump/patches/1.101-kdump9/kexec-tools-1.101-kdump9.patch
>
> I modified it for that. (attached file).
>
> I have a question about kdump :
>
> When the second kernel is loaded, kexec checks if the segments of the
> new kernel are in the reserved memory
>
> valid_memory_range in kexec/kexec.c :
> if ((send > mem_max) || (sstart < mem_min)) return 0;
>
> but mem_min and mem_max are defined by the XXX@YYY argument of the
> first kernel.
> For me, with 512@512 :
> more /proc/iomem
> ...
> 049cc000-77ffffff : System RAM
> 20000000-3fffffff : Crash kernel
> ...
> So, I can not load the second kernel : Invalid memory segment
> 0x4000000 - 0x469ffff
>
> When I set 64@64 argument for the first kernel, the checking is ok,
> but I have another issue :
> kexec_load failed: Cannot assign requested address
> entry = 0x80020 flags = 320001
> nr_segments = 6
> segment[0].buf = 0x6000000000021b90
> segment[0].bufsz = 20
> segment[0].mem = (nil)
> segment[0].memsz = 10000
> segment[1].buf = 0x60000000000222d0
> segment[1].bufsz = 10638
> segment[1].mem = 0x80000
> segment[1].memsz = 20000
> segment[2].buf = 0x2000000003b50010
> segment[2].bufsz = 23473c
> segment[2].mem = 0x100000
> segment[2].memsz = 240000
> segment[3].buf = 0x20000000002f0010
> segment[3].bufsz = 692dd8
> segment[3].mem = 0x4000000
> segment[3].memsz = 6a0000
> segment[4].buf = 0x2000000000990010
> segment[4].bufsz = 42c8
> segment[4].mem = 0x46a0000
> segment[4].memsz = 10000
> segment[5].buf = 0x20000000009a0010
> segment[5].bufsz = 17c3ec
> segment[5].mem = 0x46b0000
> segment[5].memsz = 2d0000
>
>
> Segments of the second kernel are the same than the first one
> (0x0000000004000000, 0x00000000046a0000 ...)
> We can not change the PHYSICAL_START as in other architectures (x86,
> x86_64, powerpc).
>
> So, I don't understand how it should work. Can you please have some
> explanation on this ?
>
> Thank you very much !
>
> Best regards,
>
> Benoit Welterlen
>
>
> ______________________________________________________________________
I modify the patch based on this one, fixed some bugs in it.
please test.
Thanks
Zou Nan hai
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch adds support for kexec-tools on ia64. This patch applies on
top of -kdump7 patch from <http://lse.sourceforge.net/kdump/>.
Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch implements the purgatory support to take backup
of the first 32KB of the first kernel
- Modified the v2wrap code to make the secondary cpus spin
directly in the v2wrap after pulling them out of kexec_wait
- Use the elf_rel function support to set the various
symbols used in purgatory
- load device-tree as a separate segment
- other miscellaneous compiler warnings cleanup
- add purgatory code support for backup
- build purgatory as relocatable for ppc64
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This patch adds the support for saving first 640k to the backup
region for x86_64.
Signed-off-by: Murali <muralim@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch builds v2wrap from within purgatory
Signed-off-by: Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This patch adds support for reserving space for backup region. Also adds code
in purgatory to copy the first 640K to backup region.
o Moved kexec_flags inside kexec_info structure.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
--===============39718348520004598==
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Milton,
first of all thanks for looking at the patches.
> 1) When patching the command line, you read the string from the
> optarg. While you clear the area in the kernel looking at
> COMMAND_LINE_SIZE, you do not limit the length that you copy into
> the kernel by this amount. This would seem like a buffer-overflow
> situation that could easily be trapped.
Yes, you're right. The kernel image could be damaged. Fixed.
> 2) I noticed your ramdisk code is quite similar in function to
> slurp_file in kexec/kexec.c. I realize this is probably a new
> function.
Fixed as well :)
> 3) Your elf-rel loading seem to not be implemented, but your probe
> returns 0 just like the image loader.
I think you're talking about the function machine_verify_elf_rel().
Unlike the probe functions this one should return 0 on error,
shouldn't it?
> 4) You seem to have several addresses hard-coded into the kexec-s390.h
> file. This would seem to limit the image you are loading, including
> any panic crash kernel options using the current scheme. I don't
> know your abi to know what other issues you might have with a more
> generic kexec to image interface. (It appears you setup your image
> to load as if it were from 0 but skipping IMAGE_READ_OFFSET bytes.
The hard coded addresses are part of the kernel abi. Nothing needs to
be changed here. Skipping the first 64k of the kernel image is ok too,
since you usually would only find a loader routine there which would
load the rest of the kernel image into ram and then start it.
If you are really interested you might have a look at
arch/s390/kernel/head.S in the kernel sources :)
Also we do not plan to use the kdump feature. It doesn't make too
much sense for the s390 architecture since we have already other
mechanisms which allow to reliably dump complete memory and register
contents at any given state of the system.
The patch below should be better (still against 1.101). Guess I will
come up with an improved kernel patch too.
Thanks,
Heiko
diffstat:
configure | 5 -
kexec/arch/s390/Makefile | 6 +
kexec/arch/s390/include/arch/options.h | 11 ++
kexec/arch/s390/kexec-elf-rel-s390.c | 23 +++++
kexec/arch/s390/kexec-image.c | 137 +++++++++++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.c | 104 +++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.h | 25 ++++++
kexec/kexec-syscall.h | 7 +
purgatory/arch/s390/Makefile | 7 +
purgatory/arch/s390/include/limits.h | 54 +++++++++++++
purgatory/arch/s390/include/stdint.h | 24 +++++
11 files changed, 402 insertions(+), 1 deletion(-)
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
