On 11/20/13 at 05:27am, Atsushi Kumagai wrote:
> On 2013/11/19 18:56:21, kexec wrote:
> > (2013/11/18 9:51), Atsushi Kumagai wrote:
> > > (2013/11/15 23:26), Vivek Goyal wrote:
> > >> On Fri, Nov 15, 2013 at 06:41:52PM +0900, HATAYAMA Daisuke wrote:
> > >>
> > >> [..]
> > Given the fact that
kexec-tools patches see below:
http://lists.infradead.org/pipermail/kexec/2013-November/010229.html
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 11/21/13 at 02:40pm, Dave Young wrote:
> Hi,
>
> This is the v3 patchset for adding efi runtime support on kexec kernel
> kernel patches was sent a while ago, not yet updated in archive.
Here it is:
https://lkml.org/lkml/2013/11/21/22
>
> in kexec-tools, this patchset will do below:
> 1. re
For supporting efi runtime, several efi physical addresses
fw_vendor, runtime, config tables, smbios and the whole runtime
mapping info need to be used in kexec kernel. Thus introduce
setup_data struct for passing these data.
collect the varialbes from /sys/firmware/efi/systab and
/sys/firmware/ef
There's build warnings about using struct x86_linux_param_header *
in x86-linux-setup.h, it is declared in x86-linux.h
Fix it by include x86-linux.h in x86-linux-setup.h
Signed-off-by: Dave Young
---
kexec/arch/i386/x86-linux-setup.h |1 +
1 file changed, 1 insertion(+)
--- kexec-tools.ori
For supporting efi runtime on kexec kernel we need to
fill the efi_info struct in setup_header. I just get
the info in kernel exported boot_params data in debugfs.
v1->v2:
update comment for offset of reserved4_1[] in x87_linux_param_header
Address comment from mjg59: do not break old kernel when
Not only setup_subarch will get data from debugfs file
boot_params/data, later code for adding efi_info will
also need do same thing. Thus add a common function here
for later use.
v1->v2: make get_bootparam() static
v2->v3: return error code when get_bootparam fails because
later patch to
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing
Old kexec-tools can not load new kernel. The reason is previously kexec-tools
do not fill efi_info in x86 setup header thus efi init fail and switch
to noefi boot. In new kexec-tools it will by default fill efi_info and
pass other efi required infomation to 2nd kernel so kexec kernel efi
initializa
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.
>From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.
changelog:
Greg:
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
v1->v2:
refresh; coding style fixes.
v2->v3:
Toshi Kani:
remove unused variable
Matt: check return value of krealloc.
Signed-off-by: Dave Young
---
arch/x86
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_map_region_fixed for directly mapping a md
to md->virt.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Matt: coding style
reuse __map_region
Signed-off-by: Dave Young
---
arch
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the step to call SetVirtualAddressMap.
Specially for HP z42
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such infomation. Per HPA, we should avoid of "sploit debugfs".
In this patch
Hi,
Here is the V3 for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config table, smbios
physical address in setup_data. EFI spec mentione
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi_64.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- efi.orig/arch/x86/platform/efi/efi_64.c
+++ efi/arch/x86/platform/efi/efi
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
I see this problem in ovmf + Fedora 19 grub boot:
text start: 100 md start: 80 md size: 80
Signed-off-by: Dave Young
Ac
Hi Bill,
I have tested this prototype patch on hp z420, it works very well.
Looking forward to your formal patch set. I can help test and review.
Baoquan
Thanks
On 11/18/13 at 11:30pm, Sumner, William wrote:
> Thank you for testing this RFC patch. It is great to have confirmation that
> the co
Hello Vivek,
On 2013/11/21 0:00:01, kexec wrote:
> > > > > Is there any chance that you could look into fixing this. I
> > > > > have no experience writing code for makedumpfile.
> > > >
> > > > I'll send a patch to fix this soon.
> > >
> > > Thanks Atsushi.
> > >
> > > Vivek
> >
> > Vivek,
Add bios_bsp_physical_apicid variable. This variable is initialized
with the value reported by BIOS tables such as ACPI MADT or MP table.
Without this variable, boot_cpu_physical_apicid temporarilly has the
value around MP table related codes such as kernel/mpparse.c,
mm/amdtopology.c and platform
This patch set is to allow kdump 2nd kernel to wake up multiple CPUs,
a continueing work from:
[PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP
https://lkml.org/lkml/2013/10/16/300.
At v4, basic design has changed. Now users need to figure out initial
APIC ID of BSP in the 1st k
Add disable_cpu_apicid kernel parameter to disable the CPU with the
specified number of initial APIC ID, mostly used for the kdump 2nd
kernel to disable BSP to wake up multiple CPUs without causing system
reset or hang due to sending INIT from AP to BSP.
Signed-off-by: HATAYAMA Daisuke
---
Docum
Add disable_cpu_apicid kernel parameter. To use this kernel parameter,
specify an initial APIC ID of the corresponding CPU you want to
disable.
This is mostly used for the kdump 2nd kernel to disable BSP to wake up
multiple CPUs without causing system reset or hang due to sending INIT
from AP to B
Previously do_kimage_alloc() will allocate a kimage structure, copy
segment list from user space and then do the segment list sanity verification.
Break down this function in 3 parts. do_kimage_alloc_init() to do actual
allocation and basic initialization of kimage structure.
copy_user_segment_lis
I have added two more functions to walk through resources.
Current walk_system_ram_range() deals with pfn and /proc/iomem can contain
partial pages. By dealing in pfn, callback function loses the info that
last page of a memory range is a partial page and not the full page. So
I implemented walk_sy
This patch adds support for loading a kexec on panic (kdump) kernel usning
new system call.
Signed-off-by: Vivek Goyal
---
arch/x86/include/asm/crash.h |9 +
arch/x86/include/asm/kexec.h | 17 +
arch/x86/kernel/crash.c| 585
arc
This patch implements the in kernel kexec functionality. It implements a
new system call kexec_file_load. I think parameter list of this system
call will change as I have not done the kernel image signature handling
yet. I have been told that I might have to pass the detached signature
and size as
This is loader specific code which can load bzImage and set it up for
64bit entry. This does not take care of 32bit entry or real mode entry
yet.
Signed-off-by: Vivek Goyal
---
arch/x86/include/asm/kexec-bzimage.h | 12 +
arch/x86/include/asm/kexec.h | 26 +++
arch/x86/kernel/Makefil
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to sign /sbin/kexec binary and let that binary do the kernel
signature verification. I had posted RFC patches for this apparoach
here.
https://lkml.
Right now we seem to be exporting the max data size contained inside
vmcoreinfo note. But this does not include the size of meta data around
vmcore info data. Like name of the note and starting and ending elf_note.
I think user space expects total size and that size is put in PT_NOTE
elf header.
On Wed, Nov 20, 2013 at 05:29:16AM +, Atsushi Kumagai wrote:
> On 2013/11/18 22:56:10, kexec wrote:
> > On Mon, Nov 18, 2013 at 12:51:39AM +, Atsushi Kumagai wrote:
> >
> > [..]
> > > > Is there any chance that you could look into fixing this. I have no
> > > > experience writing code fo
On 19/11/2013 02:01, Simon Horman wrote:
> On Fri, Nov 15, 2013 at 04:01:51PM +0100, Laurent Dufour wrote:
>> This patch provides support for the new Power PC litte endian (LE) mode. The
>> LE mode only differs in the way the instructions and data are stored in
>> memory
>> thus there is no real n
32 matches
Mail list logo
