[patch 0/4 v3] kexec-tools: efi runtime support

[patch 0/4 v3] kexec-tools: efi runtime support

[dyoung-H+wXaHxf7aLQT0dZR+AlfA]

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. 

in kexec-tools, this patchset will do below:
1. retrieve efi_info from sysfs boot_params, and fill the
x86 setup header. If kernel does not export sysfs boot_params,
still try to find them in debugfs.

2. collect data efi runtime needed:
/sys/firmware/efi/systab: smbios
/sys/firmware/efi/fw_vendor
/sys/firmware/efi/runtime
/sys/firmware/efi/config_table

/sys/firmware/efi/runtime-map/*, the phys-virt mappings in 1st kernel

3. assemble setup_data based on data get in 2) then pass it to 2nd kernel

Tested on OVMF, dell laptop, lenovo laptop and HP workstation

TODO: add functions for easily adding setup_data, arrange them as link list
because we probably will add e820 memory ranges as setup_data as well.
I do not prefer to bloat this patchset anymore, so I'd likt to address this
issue after the efi runtime issue finished unless people request.

V2 changelog:
Address comments from
Simon:
  coding style, fixed a mem leak
HPA:
  use type uint64_t instead of __uint64_t
mjg:
  do not cause regression for loading old kernel
  use xloadflags to check the bzImage support for efi.
  in case old kernel, do not pass efi_info and setup_data
  for new kernel, do not pass acpi_rsdp
Vivek:
  suggest to export a value in bzImage probe for efi support
  so it can be used to check if we should pass acpi_rsdp.

V3 changelog:
01/04: new patch of a building fix
try sysfs firstly for boot params
add checking of efi memory range description version, bail out if it's not 1
error handling improvement and some cleanups

--
Thanks
Dave

[patch 1/4 v3] build fix: include x86-linux.h in x86-linux-setup.h

[dyoung-H+wXaHxf7aLQT0dZR+AlfA]

[-- Attachment #1: build-warning-fix.patch --]
[-- Type: text/plain, Size: 650 bytes --]

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 <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 kexec/arch/i386/x86-linux-setup.h |    1 +
 1 file changed, 1 insertion(+)

--- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.h
+++ kexec-tools/kexec/arch/i386/x86-linux-setup.h
@@ -1,5 +1,6 @@
 #ifndef X86_LINUX_SETUP_H
 #define X86_LINUX_SETUP_H
+#include <x86/x86-linux.h>
 
 void init_linux_parameters(struct x86_linux_param_header *real_mode);
 void setup_linux_bootloader_parameters_high(

[patch 2/4 v3] Add function get_bootparam

[dyoung-H+wXaHxf7aLQT0dZR+AlfA]

[-- Attachment #1: 01-kexec-add-function-get-boot-param.patch --]
[-- Type: text/plain, Size: 2437 bytes --]

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 collect efi runtime maps will not
        necessary if get_bootparam fails.
	switch to use /sys/kernel/boot_params if possible. 
	return error code for later use in setup_efi_info.

Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 kexec/arch/i386/x86-linux-setup.c |   42 ++++++++++++++++++++++++++++----------
 1 file changed, 31 insertions(+), 11 deletions(-)

--- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.c
+++ kexec-tools/kexec/arch/i386/x86-linux-setup.c
@@ -436,28 +436,48 @@ char *find_mnt_by_fsname(char *fsname)
 	return mntdir;
 }
 
-void setup_subarch(struct x86_linux_param_header *real_mode)
+static int get_bootparam(void *buf, off_t offset, size_t size)
 {
 	int data_file;
-	const off_t offset = offsetof(typeof(*real_mode), hardware_subarch);
-	char *debugfs_mnt;
+	char *debugfs_mnt, *sysfs_mnt;
 	char filename[PATH_MAX];
+	int err, has_sysfs_params = 0;
+
+	sysfs_mnt = find_mnt_by_fsname("sysfs");
+	if (sysfs_mnt) {
+		snprintf(filename, PATH_MAX, "%s/%s", sysfs_mnt,
+			"kernel/boot_params/data");
+		free(sysfs_mnt);
+		err = access(filename, F_OK);
+		if (!err)
+			has_sysfs_params = 1;
+	}
 
-	debugfs_mnt = find_mnt_by_fsname("debugfs");
-	if (!debugfs_mnt)
-		return;
-	snprintf(filename, PATH_MAX, "%s/%s", debugfs_mnt, "boot_params/data");
-	filename[PATH_MAX-1] = 0;
-	free(debugfs_mnt);
+	if (!has_sysfs_params) {
+		debugfs_mnt = find_mnt_by_fsname("debugfs");
+		if (!debugfs_mnt)
+			return 1;
+		snprintf(filename, PATH_MAX, "%s/%s", debugfs_mnt,
+				"boot_params/data");
+		free(debugfs_mnt);
+	}
 
 	data_file = open(filename, O_RDONLY);
 	if (data_file < 0)
-		return;
+		return 1;
 	if (lseek(data_file, offset, SEEK_SET) < 0)
 		goto close;
-	read(data_file, &real_mode->hardware_subarch, sizeof(uint32_t));
+	read(data_file, buf, size);
 close:
 	close(data_file);
+	return 0;
+}
+
+void setup_subarch(struct x86_linux_param_header *real_mode)
+{
+	off_t offset = offsetof(typeof(*real_mode), hardware_subarch);
+
+	get_bootparam(&real_mode->hardware_subarch, offset, sizeof(uint32_t));
 }
 
 void setup_linux_system_parameters(struct kexec_info *info,

[patch 3/4 v3] Add efi_info in x86 setup header

[dyoung-H+wXaHxf7aLQT0dZR+AlfA]

[-- Attachment #1: 02-kexec-padd-efi_info.patch --]
[-- Type: text/plain, Size: 3866 bytes --]

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 use newer kexec-tools.
  add checking for xloadflags bit 4 XLF_EFI_KEXEC. Only fill
  efi_info and pass acpi_rsdp when the kexec kernel support efi boot.
coding style fix, change internal function to be static

Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 include/x86/x86-linux.h             |    3 ++-
 kexec/arch/i386/crashdump-x86.c     |    4 +++-
 kexec/arch/i386/x86-linux-setup.c   |    9 +++++++++
 kexec/arch/i386/x86-linux-setup.h   |    1 +
 kexec/arch/x86_64/kexec-bzImage64.c |    6 ++++++
 5 files changed, 21 insertions(+), 2 deletions(-)

--- kexec-tools.orig/include/x86/x86-linux.h
+++ kexec-tools/include/x86/x86-linux.h
@@ -113,7 +113,8 @@ struct x86_linux_param_header {
 	uint32_t ext_ramdisk_image;		/* 0xc0 */
 	uint32_t ext_ramdisk_size;		/* 0xc4 */
 	uint32_t ext_cmd_line_ptr;		/* 0xc8 */
-	uint8_t reserved4_1[0x1e0 - 0xcc];	/* 0xcc */
+	uint8_t reserved4_1[0x1c0 - 0xcc];	/* 0xe4 */
+	uint8_t efi_info[32];			/* 0x1c0 */
 	uint32_t alt_mem_k;			/* 0x1e0 */
 	uint8_t  reserved5[4];			/* 0x1e4 */
 	uint8_t  e820_map_nr;			/* 0x1e8 */
--- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.c
+++ kexec-tools/kexec/arch/i386/x86-linux-setup.c
@@ -480,6 +480,13 @@ void setup_subarch(struct x86_linux_para
 	get_bootparam(&real_mode->hardware_subarch, offset, sizeof(uint32_t));
 }
 
+static void setup_efi_info(struct x86_linux_param_header *real_mode)
+{
+	off_t offset = offsetof(typeof(*real_mode), efi_info);
+
+	get_bootparam(&real_mode->efi_info, offset, 32);
+}
+
 void setup_linux_system_parameters(struct kexec_info *info,
 				   struct x86_linux_param_header *real_mode)
 {
@@ -489,6 +496,8 @@ void setup_linux_system_parameters(struc
 
 	/* get subarch from running kernel */
 	setup_subarch(real_mode);
+	if (bzImage_support_efi_boot)
+		setup_efi_info(real_mode);
 	
 	/* Default screen size */
 	real_mode->orig_x = 0;
--- kexec-tools.orig/kexec/arch/i386/crashdump-x86.c
+++ kexec-tools/kexec/arch/i386/crashdump-x86.c
@@ -41,6 +41,7 @@
 #include "../../crashdump.h"
 #include "kexec-x86.h"
 #include "crashdump-x86.h"
+#include "x86-linux-setup.h"
 
 #ifdef HAVE_LIBXENCTRL
 #ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
@@ -1046,7 +1047,8 @@ int load_crashdump_segments(struct kexec
 	if (delete_memmap(memmap_p, elfcorehdr, memsz) < 0)
 		return -1;
 	cmdline_add_memmap(mod_cmdline, memmap_p);
-	cmdline_add_efi(mod_cmdline);
+	if (!bzImage_support_efi_boot)
+		cmdline_add_efi(mod_cmdline);
 	cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
 
 	/* Inform second kernel about the presence of ACPI tables. */
--- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.h
+++ kexec-tools/kexec/arch/i386/x86-linux-setup.h
@@ -29,5 +29,6 @@ void setup_linux_system_parameters(struc
 
 /* command line parameter may be appended by purgatory */
 #define PURGATORY_CMDLINE_SIZE 64
+extern int bzImage_support_efi_boot;
 
 #endif /* X86_LINUX_SETUP_H */
--- kexec-tools.orig/kexec/arch/x86_64/kexec-bzImage64.c
+++ kexec-tools/kexec/arch/x86_64/kexec-bzImage64.c
@@ -42,6 +42,7 @@
 #include <arch/options.h>
 
 static const int probe_debug = 0;
+int bzImage_support_efi_boot;
 
 int bzImage64_probe(const char *buf, off_t len)
 {
@@ -82,6 +83,11 @@ int bzImage64_probe(const char *buf, off
 		/* Must be KERNEL_64 and CAN_BE_LOADED_ABOVE_4G */
 		return -1;
 	}
+
+#define XLF_EFI_KEXEC   (1 << 4)
+	if ((header->xloadflags & XLF_EFI_KEXEC) == XLF_EFI_KEXEC)
+		bzImage_support_efi_boot = 1;
+
 	/* I've got a relocatable bzImage64 */
 	if (probe_debug)
 		fprintf(stderr, "It's a relocatable bzImage64\n");

[patch 4/4 v3] Passing efi related data via setup_data

[dyoung-H+wXaHxf7aLQT0dZR+AlfA]

[-- Attachment #1: 03-kexec-add-efi-setup-data.patch --]
[-- Type: text/plain, Size: 6504 bytes --]

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/efi/runtime-map

Tested on qemu+ovmf, dell laptop, lenovo laptop and HP workstation.

v1->v2:
HPA: use uint*_t instead of __uint*_t
Simon: indention fix; fix a memory leak
move offset change update to previous patch in setup header
only passing setup_data when the bzImage support efi boot
Vivek: export a value in bzImage probe so it can be used
      to check if we should pass acpi_rsdp.
coding style

v2->v3:
code cleanup
bail out if efi mm desc_version != 1
bhe: define macro for SETUP_EFI
     break loop if find matched string in systab.

Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 kexec/arch/i386/x86-linux-setup.c |  189 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 186 insertions(+), 3 deletions(-)

--- kexec-tools.orig/kexec/arch/i386/x86-linux-setup.c
+++ kexec-tools/kexec/arch/i386/x86-linux-setup.c
@@ -36,6 +36,8 @@
 #include "x86-linux-setup.h"
 #include "../../kexec/kexec-syscall.h"
 
+#define SETUP_EFI	4
+
 void init_linux_parameters(struct x86_linux_param_header *real_mode)
 {
 	/* Fill in the values that are usually provided by the kernel. */
@@ -480,11 +482,192 @@ void setup_subarch(struct x86_linux_para
 	get_bootparam(&real_mode->hardware_subarch, offset, sizeof(uint32_t));
 }
 
-static void setup_efi_info(struct x86_linux_param_header *real_mode)
+struct efi_mem_descriptor {
+	uint32_t type;
+	uint32_t pad;
+	uint64_t phys_addr;
+	uint64_t virt_addr;
+	uint64_t num_pages;
+	uint64_t attribute;
+};
+
+struct efi_setup_data {
+	uint64_t fw_vendor;
+	uint64_t runtime;
+	uint64_t tables;
+	uint64_t smbios;
+	uint64_t reserved[8];
+	struct efi_mem_descriptor map[0];
+};
+
+struct setup_data {
+	uint64_t next;
+	uint32_t type;
+	uint32_t len;
+	uint8_t data[0];
+} __attribute__((packed));
+
+static int __get_efi_value(char *line, const char *pattern, uint64_t *val)
+{
+	char *s, *end;
+	s = strstr(line, pattern);
+	if (s)
+		*val = strtoull(s + strlen(pattern), &end, 16);
+
+	if (!s || *val == ULONG_MAX)
+		return 1;
+	return 0;
+}
+
+static void _get_efi_value(const char *filename,
+			const char *pattern, uint64_t *val)
+{
+	FILE *fp;
+	char line[1024];
+	int ret;
+
+	fp = fopen(filename, "r");
+	if (!fp)
+		return;
+
+	while (fgets(line, sizeof(line), fp) != 0) {
+		ret = __get_efi_value(line, pattern, val);
+		if (!ret)
+			break;
+	}
+
+	fclose(fp);
+}
+
+static void get_efi_values(struct efi_setup_data *esd)
 {
+	_get_efi_value("/sys/firmware/efi/systab", "SMBIOS=0x",
+			&esd->smbios);
+	_get_efi_value("/sys/firmware/efi/fw_vendor", "0x",
+			&esd->fw_vendor);
+	_get_efi_value("/sys/firmware/efi/runtime", "0x",
+			&esd->runtime);
+	_get_efi_value("/sys/firmware/efi/config_table", "0x",
+			&esd->tables);
+}
+
+static int get_efi_runtime_map(struct efi_setup_data **esd)
+{
+	DIR *dirp;
+	struct dirent *entry;
+	char filename[1024];
+	struct efi_mem_descriptor md;
+	int nr_maps = 0;
+
+	dirp = opendir("/sys/firmware/efi/runtime-map");
+	if (!dirp)
+		return 0;
+	while ((entry = readdir(dirp)) != NULL) {
+		sprintf(filename,
+			"/sys/firmware/efi/runtime-map/%s",
+			(char *)entry->d_name);
+		if (*entry->d_name == '.')
+			continue;
+		file_scanf(filename, "type", "0x%x", (unsigned int *)&md.type);
+		file_scanf(filename, "phys_addr", "0x%llx",
+			   (unsigned long long *)&md.phys_addr);
+		file_scanf(filename, "virt_addr", "0x%llx",
+			   (unsigned long long *)&md.virt_addr);
+		file_scanf(filename, "num_pages", "0x%llx",
+			   (unsigned long long *)&md.num_pages);
+		file_scanf(filename, "attribute", "0x%llx",
+			   (unsigned long long *)&md.attribute);
+		*esd = realloc(*esd, sizeof(struct efi_setup_data) +
+			   (nr_maps + 1) * sizeof(struct efi_mem_descriptor));
+		*((*esd)->map + nr_maps) = md;
+		nr_maps++;
+	}
+
+	closedir(dirp);
+	return nr_maps;
+}
+
+static int setup_efi_setup_data(struct kexec_info *info,
+			struct x86_linux_param_header *real_mode)
+{
+	int nr_maps;
+	int64_t setup_data_paddr;
+	struct setup_data *sd;
+	struct efi_setup_data *esd;
+	int size, sdsize;
+	int has_efi = 0;
+
+	has_efi = access("/sys/firmware/efi/systab", F_OK);
+	if (has_efi < 0)
+		return 1;
+
+	esd = malloc(sizeof(struct efi_setup_data));
+	if (!esd)
+		return 1;
+	memset(esd, 0, sizeof(struct efi_setup_data));
+	get_efi_values(esd);
+	nr_maps = get_efi_runtime_map(&esd);
+	if (!nr_maps) {
+		free(esd);
+		return 1;
+	}
+	size = nr_maps * sizeof(struct efi_mem_descriptor) +
+		sizeof(struct efi_setup_data);
+	sd = malloc(sizeof(struct setup_data) + size);
+	if (!sd) {
+		free(esd);
+		return 1;
+	}
+
+	memset(sd, 0, sizeof(struct setup_data) + size);
+	sd->next = 0;
+	sd->type = SETUP_EFI;
+	sd->len = size;
+	memcpy(sd->data, esd, size);
+	free(esd);
+	sdsize = sd->len + sizeof(struct setup_data);
+	setup_data_paddr = add_buffer(info, sd, sdsize, sdsize, getpagesize(),
+					0x100000, ULONG_MAX, INT_MAX);
+
+	real_mode->setup_data = setup_data_paddr;
+
+	return 0;
+}
+
+struct efi_info {
+	uint32_t pad[3];
+	uint32_t efi_memdesc_version;
+	uint32_t pad1[4];
+};
+
+static int
+get_efi_mem_desc_version(struct x86_linux_param_header *real_mode)
+{
+	struct efi_info *ei = (struct efi_info *)real_mode->efi_info;
+
+	return ei->efi_memdesc_version;
+}
+
+static void setup_efi_info(struct kexec_info *info,
+			   struct x86_linux_param_header *real_mode)
+{
+	int ret, desc_version;
 	off_t offset = offsetof(typeof(*real_mode), efi_info);
 
-	get_bootparam(&real_mode->efi_info, offset, 32);
+	ret = get_bootparam(&real_mode->efi_info, offset, 32);
+	if (ret)
+		return;
+	desc_version = get_efi_mem_desc_version(real_mode);
+	if (desc_version != 1) {
+		fprintf(stderr,
+			"efi memory descriptor version %d is not supported!\n",
+			desc_version);
+		memset(&real_mode->efi_info, 0, 32);
+		return;
+	}
+	ret = setup_efi_setup_data(info, real_mode);
+	if (ret)
+		memset(&real_mode->efi_info, 0, 32);
 }
 
 void setup_linux_system_parameters(struct kexec_info *info,
@@ -497,7 +680,7 @@ void setup_linux_system_parameters(struc
 	/* get subarch from running kernel */
 	setup_subarch(real_mode);
 	if (bzImage_support_efi_boot)
-		setup_efi_info(real_mode);
+		setup_efi_info(info, real_mode);
 	
 	/* Default screen size */
 	real_mode->orig_x = 0;

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Dave Young]

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. retrieve efi_info from sysfs boot_params, and fill the
> x86 setup header. If kernel does not export sysfs boot_params,
> still try to find them in debugfs.
> 
> 2. collect data efi runtime needed:
> /sys/firmware/efi/systab: smbios
> /sys/firmware/efi/fw_vendor
> /sys/firmware/efi/runtime
> /sys/firmware/efi/config_table
> 
> /sys/firmware/efi/runtime-map/*, the phys-virt mappings in 1st kernel
> 
> 3. assemble setup_data based on data get in 2) then pass it to 2nd kernel
> 
> Tested on OVMF, dell laptop, lenovo laptop and HP workstation
> 
> TODO: add functions for easily adding setup_data, arrange them as link list
> because we probably will add e820 memory ranges as setup_data as well.
> I do not prefer to bloat this patchset anymore, so I'd likt to address this
> issue after the efi runtime issue finished unless people request.
> 
> V2 changelog:
> Address comments from
> Simon:
>   coding style, fixed a mem leak
> HPA:
>   use type uint64_t instead of __uint64_t
> mjg:
>   do not cause regression for loading old kernel
>   use xloadflags to check the bzImage support for efi.
>   in case old kernel, do not pass efi_info and setup_data
>   for new kernel, do not pass acpi_rsdp
> Vivek:
>   suggest to export a value in bzImage probe for efi support
>   so it can be used to check if we should pass acpi_rsdp.
> 
> V3 changelog:
> 01/04: new patch of a building fix
> try sysfs firstly for boot params
> add checking of efi memory range description version, bail out if it's not 1
> error handling improvement and some cleanups
> 
> --
> Thanks
> Dave
> 
> _______________________________________________
> kexec mailing list
> kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Toshi Kani]

On Thu, 2013-11-21 at 14:40 +0800, dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org 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. 
> 
> in kexec-tools, this patchset will do below:
> 1. retrieve efi_info from sysfs boot_params, and fill the
> x86 setup header. If kernel does not export sysfs boot_params,
> still try to find them in debugfs.
> 
> 2. collect data efi runtime needed:
> /sys/firmware/efi/systab: smbios
> /sys/firmware/efi/fw_vendor
> /sys/firmware/efi/runtime
> /sys/firmware/efi/config_table
> 
> /sys/firmware/efi/runtime-map/*, the phys-virt mappings in 1st kernel
> 
> 3. assemble setup_data based on data get in 2) then pass it to 2nd kernel
> 
> Tested on OVMF, dell laptop, lenovo laptop and HP workstation

Tested on an HP EFI-based 60-way server (prototype).  For the series:

Tested-by: Toshi Kani <toshi.kani-VXdhtT5mjnY@public.gmane.org>

Thanks,
-Toshi

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Dave Young]

On 11/22/13 at 03:30pm, Toshi Kani wrote:
> On Thu, 2013-11-21 at 14:40 +0800, dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org 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. 
> > 
> > in kexec-tools, this patchset will do below:
> > 1. retrieve efi_info from sysfs boot_params, and fill the
> > x86 setup header. If kernel does not export sysfs boot_params,
> > still try to find them in debugfs.
> > 
> > 2. collect data efi runtime needed:
> > /sys/firmware/efi/systab: smbios
> > /sys/firmware/efi/fw_vendor
> > /sys/firmware/efi/runtime
> > /sys/firmware/efi/config_table
> > 
> > /sys/firmware/efi/runtime-map/*, the phys-virt mappings in 1st kernel
> > 
> > 3. assemble setup_data based on data get in 2) then pass it to 2nd kernel
> > 
> > Tested on OVMF, dell laptop, lenovo laptop and HP workstation
> 
> Tested on an HP EFI-based 60-way server (prototype).  For the series:

Hi, Toshi

Thanks for the testing, during my own testing this weekend I found two
issues I need to fix and improve:
1. print original memmap #ifdef EFI_DEBUG does not make sense, will add
   a patch to only print runtime maps we saved in case kexec.

2. move e820_reserve_setup_data late after parse early param and setup
   the runtime mapping, otherwise kdump kernel will complains about
   ioremap a normal ram region.

3. should change the phys_to_virt to ioremap in parse_efi_setup, also
   should fix the arch/x86/kernel/kdebugfs.c, move __va to ioremap as
   well, because kexec does not works for using memmap=exactmap in
   1st kernel, bug like below:

[    0.153726] BUG: unable to handle kernel paging request at ffff880000100008
[    0.156666] IP: [<ffffffff817beb54>] arch_kdebugfs_init+0x11a/0x201
[    0.156666] PGD 7e149067 PUD 7e14a067 PMD 7e14b067 PTE 0
[    0.156666] Oops: 0000 [#1] PREEMPT SMP 
[    0.156666] Modules linked in:
[    0.156666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0+ #103
[    0.156666] task: ffff880037032000 ti: ffff88003706a000 task.ti: ffff88003706a000
[    0.156666] RIP: 0010:[<ffffffff817beb54>]  [<ffffffff817beb54>] arch_kdebugfs_init+0x11a/0x201
[    0.156666] RSP: 0000:ffff88003706be30  EFLAGS: 00010286
[    0.156666] RAX: ffff880037002a00 RBX: ffff880037002a00 RCX: 0000000000000b90
[    0.156666] RDX: 0000000000000000 RSI: ffffffff81673a10 RDI: ffff88003706be50
[    0.156666] RBP: ffff88003706be90 R08: ffff880037002a00 R09: ffff880037002a10
[    0.156666] R10: 0000000000000000 R11: ffffffff817beb2a R12: ffff8800364033e0
[    0.156666] R13: 0000000000100000 R14: ffff880036403000 R15: ffff880000100000
[    0.156666] FS:  0000000000000000(0000) GS:ffff880037400000(0000) knlGS:0000000000000000
[    0.156666] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.156666] CR2: ffff880000100008 CR3: 000000007d6fb000 CR4: 00000000000006f0
[    0.156666] Stack:
[    0.156666]  ffffffff8176b0b0 ffff8800364030f8 ffff8800364031f0 0000000000000000
[    0.156666]  ffff88003706be60 ffffffff8148e41d 00000000733b54fc ffffffff817bea3a
[    0.156666]  ffffffff81868d90 0000000000000000 0000000000000000 0000000000000000
[    0.156666] Call Trace:
[    0.156666]  [<ffffffff8148e41d>] ? mutex_unlock+0x9/0xb
[    0.156666]  [<ffffffff817bea3a>] ? topology_init+0x36/0x36
[    0.156666]  [<ffffffff81000296>] do_one_initcall+0xae/0x158
[    0.156666]  [<ffffffff8107750a>] ? parameq+0x1d/0x1f
[    0.156666]  [<ffffffff81077768>] ? parse_args+0x25c/0x33a
[    0.156666]  [<ffffffff817b8e96>] kernel_init_freeable+0x115/0x19b
[    0.156666]  [<ffffffff817b873d>] ? do_early_param+0x88/0x88
[    0.156666]  [<ffffffff8147bfa9>] ? rest_init+0xbd/0xbd
[    0.156666]  [<ffffffff8147bfb2>] kernel_init+0x9/0xcc
[    0.156666]  [<ffffffff81491d8c>] ret_from_fork+0x7c/0xb0
[    0.156666]  [<ffffffff8147bfa9>] ? rest_init+0xbd/0xbd
[    0.156666] Code: ff 48 85 c0 48 89 c3 0f 84 b9 00 00 00 49 bf 00 00 00 00 00 88 ff ff 4c 89 28 8b 55 bc 48 8d 7d c0 4d 01 ef 48 c7 c6 10 3a 67 81 <41> 8b 47 08 89 43 08 41 8b 47 0c 89 43 0c 31 c0 e8 2c 50 a7 ff 
[    0.156666] RIP  [<ffffffff817beb54>] arch_kdebugfs_init+0x11a/0x201
[    0.156666]  RSP <ffff88003706be30>
[    0.156666] CR2: ffff880000100008
[    0.156666] ---[ end trace 2c6f39ce0b3f50b3 ]---
[    0.156738] swapper/0 (1) used greatest stack depth: 5240 bytes left
[    0.160061] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    0.160061] 
	

I think these should be all the remain issue, I will fix them in next version.
Appreciate your testing.

Thanks
Dave

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Toshi Kani]

On Sun, 2013-11-24 at 11:12 +0800, Dave Young wrote:
> Hi, Toshi
> 
> Thanks for the testing, during my own testing this weekend I found two
> issues I need to fix and improve:
> 1. print original memmap #ifdef EFI_DEBUG does not make sense, will add
>    a patch to only print runtime maps we saved in case kexec.
> 
> 2. move e820_reserve_setup_data late after parse early param and setup
>    the runtime mapping, otherwise kdump kernel will complains about
>    ioremap a normal ram region.
> 
> 3. should change the phys_to_virt to ioremap in parse_efi_setup, also
>    should fix the arch/x86/kernel/kdebugfs.c, move __va to ioremap as
>    well, because kexec does not works for using memmap=exactmap in
>    1st kernel, bug like below:
> 
> [    0.153726] BUG: unable to handle kernel paging request at ffff880000100008
> [    0.156666] IP: [<ffffffff817beb54>] arch_kdebugfs_init+0x11a/0x201
> [    0.156666] PGD 7e149067 PUD 7e14a067 PMD 7e14b067 PTE 0
> [    0.156666] Oops: 0000 [#1] PREEMPT SMP 
> [    0.156666] Modules linked in:
> [    0.156666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0+ #103
> [    0.156666] task: ffff880037032000 ti: ffff88003706a000 task.ti: ffff88003706a000
> [    0.156666] RIP: 0010:[<ffffffff817beb54>]  [<ffffffff817beb54>] arch_kdebugfs_init+0x11a/0x201
> [    0.156666] RSP: 0000:ffff88003706be30  EFLAGS: 00010286
> [    0.156666] RAX: ffff880037002a00 RBX: ffff880037002a00 RCX: 0000000000000b90
> [    0.156666] RDX: 0000000000000000 RSI: ffffffff81673a10 RDI: ffff88003706be50
> [    0.156666] RBP: ffff88003706be90 R08: ffff880037002a00 R09: ffff880037002a10
> [    0.156666] R10: 0000000000000000 R11: ffffffff817beb2a R12: ffff8800364033e0
> [    0.156666] R13: 0000000000100000 R14: ffff880036403000 R15: ffff880000100000
> [    0.156666] FS:  0000000000000000(0000) GS:ffff880037400000(0000) knlGS:0000000000000000
> [    0.156666] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [    0.156666] CR2: ffff880000100008 CR3: 000000007d6fb000 CR4: 00000000000006f0
> [    0.156666] Stack:
> [    0.156666]  ffffffff8176b0b0 ffff8800364030f8 ffff8800364031f0 0000000000000000
> [    0.156666]  ffff88003706be60 ffffffff8148e41d 00000000733b54fc ffffffff817bea3a
> [    0.156666]  ffffffff81868d90 0000000000000000 0000000000000000 0000000000000000
> [    0.156666] Call Trace:
> [    0.156666]  [<ffffffff8148e41d>] ? mutex_unlock+0x9/0xb
> [    0.156666]  [<ffffffff817bea3a>] ? topology_init+0x36/0x36
> [    0.156666]  [<ffffffff81000296>] do_one_initcall+0xae/0x158
> [    0.156666]  [<ffffffff8107750a>] ? parameq+0x1d/0x1f
> [    0.156666]  [<ffffffff81077768>] ? parse_args+0x25c/0x33a
> [    0.156666]  [<ffffffff817b8e96>] kernel_init_freeable+0x115/0x19b
> [    0.156666]  [<ffffffff817b873d>] ? do_early_param+0x88/0x88
> [    0.156666]  [<ffffffff8147bfa9>] ? rest_init+0xbd/0xbd
> [    0.156666]  [<ffffffff8147bfb2>] kernel_init+0x9/0xcc
> [    0.156666]  [<ffffffff81491d8c>] ret_from_fork+0x7c/0xb0
> [    0.156666]  [<ffffffff8147bfa9>] ? rest_init+0xbd/0xbd
> [    0.156666] Code: ff 48 85 c0 48 89 c3 0f 84 b9 00 00 00 49 bf 00 00 00 00 00 88 ff ff 4c 89 28 8b 55 bc 48 8d 7d c0 4d 01 ef 48 c7 c6 10 3a 67 81 <41> 8b 47 08 89 43 08 41 8b 47 0c 89 43 0c 31 c0 e8 2c 50 a7 ff 
> [    0.156666] RIP  [<ffffffff817beb54>] arch_kdebugfs_init+0x11a/0x201
> [    0.156666]  RSP <ffff88003706be30>
> [    0.156666] CR2: ffff880000100008
> [    0.156666] ---[ end trace 2c6f39ce0b3f50b3 ]---
> [    0.156738] swapper/0 (1) used greatest stack depth: 5240 bytes left
> [    0.160061] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [    0.160061] 
> 	
> 
> I think these should be all the remain issue, I will fix them in next version.
> Appreciate your testing.

HI Dave,

I will test v4 again.  This time, I will test "memmap=exactmap" option
as well.  I have tested the following cases before.  Are there any other
cases you'd like me to test?

 - kdump
 - multiple fast reboots and then kdump
 - old kexec and new kernel w/ noefi & acpi_rsdp option
 - new kexec and old kernel w/ noefi & acpi_rsdp option

Thanks,
-Toshi

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Dave Young]

Hi, Toshi
On 11/25/13 at 08:30am, Toshi Kani wrote:
> HI Dave,
> 
> I will test v4 again.  This time, I will test "memmap=exactmap" option
> as well.  I have tested the following cases before.  Are there any other
> cases you'd like me to test?
> 
>  - kdump
>  - multiple fast reboots and then kdump
>  - old kexec and new kernel w/ noefi & acpi_rsdp option
>  - new kexec and old kernel w/ noefi & acpi_rsdp option

There's one more test case is w/ debugfs mounted in 1st kernel due to the
new version exports setup_data to sysfs.

For the exactmap I think it's a corner case, I just tested it in virtual
machine I think setup a right cmdline is hard. But feel free to test it if
you can.

Thanks
Dave

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Toshi Kani]

On Tue, 2013-11-26 at 14:11 +0800, Dave Young wrote:
> On 11/25/13 at 08:30am, Toshi Kani wrote:
> > HI Dave,
> > 
> > I will test v4 again.  This time, I will test "memmap=exactmap" option
> > as well.  I have tested the following cases before.  Are there any other
> > cases you'd like me to test?
> > 
> >  - kdump
> >  - multiple fast reboots and then kdump
> >  - old kexec and new kernel w/ noefi & acpi_rsdp option
> >  - new kexec and old kernel w/ noefi & acpi_rsdp option

Retested the above cases with v4 patchset.

> There's one more test case is w/ debugfs mounted in 1st kernel due to the
> new version exports setup_data to sysfs.

Tested w/ debugfs mounted.

> For the exactmap I think it's a corner case, I just tested it in virtual
> machine I think setup a right cmdline is hard. But feel free to test it if
> you can.

Tested with exactmap for multiple fast reboots.  I was not able to setup
kdump properly with this case, but it's not related with your changes
since I was not able to do it without your changes, either.

Feel free to add my tested-by.

Thanks,
-Toshi

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Dave Young]

On 11/26/13 at 08:59am, Toshi Kani wrote:
> On Tue, 2013-11-26 at 14:11 +0800, Dave Young wrote:
> > On 11/25/13 at 08:30am, Toshi Kani wrote:
> > > HI Dave,
> > > 
> > > I will test v4 again.  This time, I will test "memmap=exactmap" option
> > > as well.  I have tested the following cases before.  Are there any other
> > > cases you'd like me to test?
> > > 
> > >  - kdump
> > >  - multiple fast reboots and then kdump
> > >  - old kexec and new kernel w/ noefi & acpi_rsdp option
> > >  - new kexec and old kernel w/ noefi & acpi_rsdp option
> 
> Retested the above cases with v4 patchset.
> 
> > There's one more test case is w/ debugfs mounted in 1st kernel due to the
> > new version exports setup_data to sysfs.
> 
> Tested w/ debugfs mounted.
> 
> > For the exactmap I think it's a corner case, I just tested it in virtual
> > machine I think setup a right cmdline is hard. But feel free to test it if
> > you can.
> 
> Tested with exactmap for multiple fast reboots.  I was not able to setup
> kdump properly with this case, but it's not related with your changes
> since I was not able to do it without your changes, either.
> 
> Feel free to add my tested-by.

Toshi, thanks a lot for your effort.

I would like to send a new version which addressing several issues
for code structure improvement and changelog etc.

If there's no further comments I will send them tommorrow. I have done the
rebase in the personal git tree (kexec-efi branch):
https://github.com/daveyoung/linux.git

They are not functional changes, I hope the test result will be same.

If you would like to do a quick test again I can add the tested-by when I resend
them, or for saving your time just test them after people are ok with the
patches themselves finally.

Thanks
Dave

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Borislav Petkov]

On Wed, Nov 27, 2013 at 05:29:46PM +0800, Dave Young wrote:
> I would like to send a new version which addressing several issues for
> code structure improvement and changelog etc.
>
> If there's no further comments I will send them tommorrow.

As a rule of thumb you should wait ~week and give chance to people to
review your stuff completely before spamming them again with the whole
patchset. :)

So please be patient until we've finished going through v4.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [patch 0/4 v3] kexec-tools: efi runtime support

[Dave Young]

On 11/27/13 at 12:56pm, Borislav Petkov wrote:
> On Wed, Nov 27, 2013 at 05:29:46PM +0800, Dave Young wrote:
> > I would like to send a new version which addressing several issues for
> > code structure improvement and changelog etc.
> >
> > If there's no further comments I will send them tommorrow.
> 
> As a rule of thumb you should wait ~week and give chance to people to
> review your stuff completely before spamming them again with the whole
> patchset. :)
> 
> So please be patient until we've finished going through v4.

Sure, thanks. 

I will be away from computer today so I will reply other emails tomorrow
and post fixes next week.

Dave