On Tue, 2016-09-06 at 14:44 +0900, AKASHI Takahiro wrote:

On Thu, Sep 01, 2016 at 09:51:10PM +0000, Geoff Levand wrote:

quoted

+int arm64_load_other_segments(struct kexec_info *info,
+	unsigned long image_base)
+{
+	int result;
+	unsigned long dtb_base;
+	unsigned long hole_min;
+	unsigned long hole_max;
+	char *initrd_buf = NULL;
+	struct dtb dtb;
+	char command_line[COMMAND_LINE_SIZE] = "";
+
+	if (arm64_opts.command_line) {
+		strncpy(command_line, arm64_opts.command_line,
+			sizeof(command_line));
+		command_line[sizeof(command_line) - 1] = 0;
+	}
+
+	if (arm64_opts.dtb) {
+		dtb.name = "dtb_2";

"dtb_1" and "dtb_2" are not very meaningful.

dtb_1 means from 1st stage, dtb_2 means a new 2nd stage.

Instead, I'm going to use:
????dtb_2 => "dtb_user" (if a command line option is specified)
????dtb_1 => "dtb_sys" (if from /sys/firmware/fdt), or
?????????????"dtb_unflatten" (if created from /proc/device-tree)
to distinguish the origins in my kdump patches.

Sure, that's OK.??I pushed ot a change to my master branch.

quoted

+static int get_memory_ranges_iomem_cb(void *data, int nr, char
*str,
+	unsigned long long base, unsigned long long length)
+{
+	struct memory_range *r;
+
+	if (nr >= KEXEC_SEGMENT_MAX)
+		return -1;
+
+	r = (struct memory_range *)data + nr;
+	r->type = RANGE_RAM;
+	r->start = base;
+	r->end = base + length - 1;
+
+	set_phys_offset(r->start);

This will no longer work correctly for identifying PHYS_OFFSET
once the following patch is applied:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450
433.html
and it is now queued in arm64/for-next.

I will include a fixup in my kdump patches as the current code of
kexec
doesn't rely on a result of virt_to_phys() seriously.

OK.

+int get_memory_ranges(struct memory_range **range, int *ranges,

quoted

+	unsigned long kexec_flags)
+{
+	static struct memory_range array[KEXEC_SEGMENT_MAX];
+	unsigned int count;
+	int result;
+
+	result = get_memory_ranges_iomem(array, &count);
+
+	if (result)
+		result = get_memory_ranges_dt(array, &count);

Do we really need to scan a DT blob here?
I think that all the (usable) memory regions are added to
/proc/iomem anyway.

I guess it is now expected that /proc/iomem has memory
in it.

quoted

+void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym
*UNUSED(sym),
+	unsigned long r_type, void *ptr, unsigned long address,
+	unsigned long value)
+{
+#if !defined(R_AARCH64_ABS64)
+# define R_AARCH64_ABS64 257
+#endif
+
+#if !defined(R_AARCH64_LD_PREL_LO19)
+# define R_AARCH64_LD_PREL_LO19 273
+#endif
+
+#if !defined(R_AARCH64_ADR_PREL_LO21)
+# define R_AARCH64_ADR_PREL_LO21 274
+#endif
+
+#if !defined(R_AARCH64_JUMP26)
+# define R_AARCH64_JUMP26 282
+#endif
+
+#if !defined(R_AARCH64_CALL26)
+# define R_AARCH64_CALL26 283
+#endif

Did you see my comment?
http://lists.infradead.org/pipermail/kexec/2016-August/016947.html

I'm still expecting?elf.h to have these.

-Geoff