The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being
crashkernel=range:size syntax allows to reserve specified size for system
with total memory fall into the specified range. For example:
crashkernel=2G-3G:128M,3G-:256M reserves 128M for system with memory >=2G
and memory <3G, and reserves 256M for system with memory >= 3G
In the above case 256M
crashkernel=range:size syntax allows to reserve specified size for system
with total memory fall into the specified range. For example:
crashkernel=2G-3G:128M,3G-:256M reserves 128M for system with memory >=2G
and memory <3G, and reserves 256M for system with memory >= 3G
In the above case 256M
Hi,
Here is a try to improve current crashkernel kernel parameter
Patch 1/3 adds an extra functionality so that one can use like
crashkernel=2G-:128M^12 to reserve 128M for 2G+ machine but also scale the
size based on system memory, that means 128M + (total_mem - 128M) >> 12
Patch 2/3 is a
Hi,
Here is a try to improve current crashkernel kernel parameter
Patch 1/3 adds an extra functionality so that one can use like
crashkernel=2G-:128M^12 to reserve 128M for 2G+ machine but also scale the
size based on system memory, that means 128M + (total_mem - 128M) >> 12
Patch 2/3 is a
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
A useful use case for min_t and max_t is comparing two values with larger
type. For example comparing an u64 and an u32, usually we do not want to
truncate the u64, so we need use min_t or max_t with u64.
To simplify the usage introducing two more macros min_lt and max_lt,
'lt' means larger type.
Hi,
We found a min_t type casting issue in fs/proc/vmcore.c, it uses smaller
type in min_t so that during i386 PAE testing 64bit value was trucated
and then cause saving vmcore failure and BUG() for mmap case.
I introduced new macros min_lt and max_lt to select the larger data type
in x and y.
On i686 PAE enabled machine the contiguous physical area could be large
and it can cause triming down variables in below calculation in
read_vmcore() and mmap_vmcore():
tsz = min_t(size_t, m->offset + m->size - *fpos, buflen);
Then the real size passed down is not correct any more.
A useful use case for min_t and max_t is comparing two values with larger
type. For example comparing an u64 and an u32, usually we do not want to
truncate the u64, so we need use min_t or max_t with u64.
To simplify the usage introducing two more macros min_lt and max_lt,
'lt' means larger type.
Hi,
We found a min_t type casting issue in fs/proc/vmcore.c, it uses smaller
type in min_t so that during i386 PAE testing 64bit value was trucated
and then cause saving vmcore failure and BUG() for mmap case.
I introduced new macros min_lt and max_lt to select the larger data type
in x and y.
On i686 PAE enabled machine the contiguous physical area could be large
and it can cause triming down variables in below calculation in
read_vmcore() and mmap_vmcore():
tsz = min_t(size_t, m->offset + m->size - *fpos, buflen);
Then the real size passed down is not correct any more.
Now there's two kexec load syscall, one is kexec_load another is
kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c.
In this patch I split kexec_load syscall code to kernel/kexec.c.
And add a new kconfig option KEXEC_CORE, so we can disable kexec_load
and use kexec_file_load
Previously Theodore Ts'o brought up an issue about kexec_load syscall bypassing
signature verification:
https://lkml.org/lkml/2015/6/14/280
Because we have two kexec load syscall, one kexec_load, another kexec_file_load,
the latter one was introduced by Vivek Goyal, it is mainly for supporting
Split kexec_file syscall related code to another file kernel/kexec_file.c
so that the #ifdef CONFIG_KEXEC_FILE in kexec.c can be dropped.
Sharing variables and functions are moved to kernel/kexec_internal.h per
suggestion from Vivek and Petr.
Signed-off-by: Dave Young
---
kernel/Makefile
Now there's two kexec load syscall, one is kexec_load another is
kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c.
In this patch I split kexec_load syscall code to kernel/kexec.c.
And add a new kconfig option KEXEC_CORE, so we can disable kexec_load
and use kexec_file_load
Previously Theodore Ts'o brought up an issue about kexec_load syscall bypassing
signature verification:
https://lkml.org/lkml/2015/6/14/280
Because we have two kexec load syscall, one kexec_load, another kexec_file_load,
the latter one was introduced by Vivek Goyal, it is mainly for supporting
Split kexec_file syscall related code to another file kernel/kexec_file.c
so that the #ifdef CONFIG_KEXEC_FILE in kexec.c can be dropped.
Sharing variables and functions are moved to kernel/kexec_internal.h per
suggestion from Vivek and Petr.
Signed-off-by: Dave Young dyo...@redhat.com
---
Now there's two kexec load syscall, one is kexec_load another is
kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c.
In this patch I split kexec_load syscall code to kernel/kexec.c.
And add a new kconfig option KEXEC_CORE, so we can disable kexec_load
and use kexec_file_load
Split kexec_file syscall related code to another file kernel/kexec_file.c
so that the #ifdef CONFIG_KEXEC_FILE in kexec.c can be dropped.
Sharing variables and functions are moved to kernel/kexec_internal.h per
suggestion from Vivek and Petr.
Signed-off-by: Dave Young
---
kernel/Makefile
in_crash_kexec is only useful for kdump, it will not be used without
CONFIG_KEXEC_CORE, thus remove the #else section
Signed-off-by: Dave Young
---
arch/x86/include/asm/kdebug.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/kdebug.h b/arch/x86/include/asm/kdebug.h
Previously Theodore Ts'o brought up an issue about kexec_load syscall bypassing
signature verification:
https://lkml.org/lkml/2015/6/14/280
Because we have two kexec load syscall, one kexec_load, another kexec_file_load,
the latter one was introduced by Vivek Goyal, it is mainly for supporting
Previously Theodore Ts'o brought up an issue about kexec_load syscall bypassing
signature verification:
https://lkml.org/lkml/2015/6/14/280
Because we have two kexec load syscall, one kexec_load, another kexec_file_load,
the latter one was introduced by Vivek Goyal, it is mainly for supporting
Now there's two kexec load syscall, one is kexec_load another is
kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c.
In this patch I split kexec_load syscall code to kernel/kexec.c.
And add a new kconfig option KEXEC_CORE, so we can disable kexec_load
and use kexec_file_load
Split kexec_file syscall related code to another file kernel/kexec_file.c
so that the #ifdef CONFIG_KEXEC_FILE in kexec.c can be dropped.
Sharing variables and functions are moved to kernel/kexec_internal.h per
suggestion from Vivek and Petr.
Signed-off-by: Dave Young dyo...@redhat.com
---
in_crash_kexec is only useful for kdump, it will not be used without
CONFIG_KEXEC_CORE, thus remove the #else section
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/include/asm/kdebug.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/kdebug.h
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=03-boot-service-fix.patch
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
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=06-export-efi-runtime-mapping.patch
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will
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.
v3->v4:
Boris: Stretch comment to 80
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=05-export-more-efi-sysfs-vars.patch
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
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=02-efi-map-fixed-addr.patch
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
Hi,
Sorry for the spam, the patch subject is not correct in previous
sending a while ago, send them again..
Here is the V4 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
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=04-efi-enter-virtual-mode-cleanup.patch
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:
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=12-x86-kdebugfs-use-ioremap.patch
__va does not work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young
---
arch/x86/kernel/kdebugfs.c | 35
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline;
filename=08-add-xloadflags-for-kexec-efi-runtime-feature.patch
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
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=09-add-sysfs-boot-param.patch
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.
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=11-reserve-setup-data-late.patch
Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=01-remove-unused-var-in-map-region.patch
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani
Signed-off-by: Dave Young
Acked-by: Borislav Petkov
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=07-use-efi-setup-data.patch
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,
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=10-print-efi-runtime-memmap.patch
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to
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
Boris: Strenthen comment lines to 80
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 23
Hi,
Here is the V4 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
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
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
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:
Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn about ioremap a normal ram range.
Signed-off-by: Dave Young
---
arch/x86/kernel/setup.c |4 ++--
1 file changed, 2 insertions(+), 2
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
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.
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
__va does not work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young
---
arch/x86/kernel/kdebugfs.c | 35 +++
1 file changed, 11 insertions(+), 24 deletions(-)
--- efi.orig/arch/x86/kernel/kdebugfs.c
+++
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani
Signed-off-by: Dave Young
Acked-by: Borislav Petkov
---
arch/x86/platform/efi/efi_64.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- efi.orig/arch/x86/platform/efi/efi_64.c
+++
__va does not work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/kernel/kdebugfs.c | 35 +++
1 file changed, 11 insertions(+), 24 deletions(-)
--- efi.orig/arch/x86/kernel/kdebugfs.c
+++
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani toshi.k...@hp.com
Signed-off-by: Dave Young dyo...@redhat.com
Acked-by: Borislav Petkov b...@suse.de
---
arch/x86/platform/efi/efi_64.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
---
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
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.
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:
Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn about ioremap a normal ram range.
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/kernel/setup.c |4 ++--
1 file changed, 2
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
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
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
Hi,
Here is the V4 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
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/platform/efi/efi.c | 23
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
Boris: Strenthen comment lines to 80
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=07-use-efi-setup-data.patch
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,
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=10-print-efi-runtime-memmap.patch
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=11-reserve-setup-data-late.patch
Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=01-remove-unused-var-in-map-region.patch
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani toshi.k...@hp.com
Signed-off-by: Dave Young
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=09-add-sysfs-boot-param.patch
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.
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline;
filename=08-add-xloadflags-for-kexec-efi-runtime-feature.patch
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
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=12-x86-kdebugfs-use-ioremap.patch
__va does not work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/kernel/kdebugfs.c |
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=04-efi-enter-virtual-mode-cleanup.patch
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:
Hi,
Sorry for the spam, the patch subject is not correct in previous
sending a while ago, send them again..
Here is the V4 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
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=05-export-more-efi-sysfs-vars.patch
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
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=02-efi-map-fixed-addr.patch
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
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.
v3-v4:
Boris: Stretch comment to 80 cols
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=06-export-efi-runtime-mapping.patch
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
Hi,
References: 20131125085630.417850...@dhcp-16-126.nay.redhat.com
Content-Disposition: inline; filename=03-boot-service-fix.patch
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.
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
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
Hi,
Here is the V2 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
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.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 107 +---
1 file
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.
Signed-off-by:
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/efi-runtime-map
Just like /sys/firmware/memmap.
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
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_remap_region to remapping it directly without
calculate the virt addr from efi_va.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Signed-off-by: Dave Young
---
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_remap_region to remapping it directly without
calculate the virt addr from efi_va.
The md is passed in from 1st kernel, the virtual addr is
saved in md-virt_addr.
Signed-off-by: Dave Young dyo...@redhat.com
---
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/efi-runtime-map
Just like /sys/firmware/memmap.
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
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.
Signed-off-by:
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
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
Hi,
Here is the V2 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
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.
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/platform/efi/efi.c | 107
1 - 100 of 136 matches
Mail list logo
