[PATCH 00/12] Fixing TI Keystone2 kexec

[PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

These changes are required for TI Keystone2 kexec to be functional.  TI
Keystone2 has the run-time view of physical memory above 4GiB, but with
a boot time alias below 4GiB which can only be used during the early
boot.

This means we need to translate run-time physical addresses (which the
kernel uses) to boot-time physical addresses, which, having discussed
with Eric, is what the kexec tools and kexec kernel API requires.

We publish a special set of boot time resources in /proc/iomem, which
the (modified) kexec tools look for in preference to the normal resources.
Hence, if these are found, the kexec tools make use of these resources,
and thus kexec tools use the boot-time view of physical memory.

The first three patches have been sitting in linux-next for a while.
I'm going to put the next ARM specific three into linux-next next week.

I've sent Eric over a month ago all the patches, including the kexec
tools patches, but I've heard nothing back.  I'm at a loss how to
make progress on these patches - and as I'm being hassled about this,
I'm going to be hassling the community about it, possibly with regular
re-posts until there is some progress.

 Documentation/kdump/kdump.txt     | 13 ++------
 arch/arm/boot/dts/keystone.dtsi   |  8 +++++
 arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
 arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
 arch/arm/kernel/machine_kexec.c   |  2 +-
 arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
 arch/arm/mach-keystone/keystone.c |  7 +----
 arch/arm/mm/idmap.c               |  2 +-
 arch/ia64/kernel/machine_kexec.c  |  2 +-
 include/linux/kexec.h             | 42 +++++++++++++++++++++++--
 kernel/kexec.c                    |  3 +-
 kernel/kexec_core.c               | 30 +++++++++---------
 kernel/ksysfs.c                   |  4 +--
 13 files changed, 193 insertions(+), 47 deletions(-)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

These changes are required for TI Keystone2 kexec to be functional.  TI
Keystone2 has the run-time view of physical memory above 4GiB, but with
a boot time alias below 4GiB which can only be used during the early
boot.

This means we need to translate run-time physical addresses (which the
kernel uses) to boot-time physical addresses, which, having discussed
with Eric, is what the kexec tools and kexec kernel API requires.

We publish a special set of boot time resources in /proc/iomem, which
the (modified) kexec tools look for in preference to the normal resources.
Hence, if these are found, the kexec tools make use of these resources,
and thus kexec tools use the boot-time view of physical memory.

The first three patches have been sitting in linux-next for a while.
I'm going to put the next ARM specific three into linux-next next week.

I've sent Eric over a month ago all the patches, including the kexec
tools patches, but I've heard nothing back.  I'm at a loss how to
make progress on these patches - and as I'm being hassled about this,
I'm going to be hassling the community about it, possibly with regular
re-posts until there is some progress.

 Documentation/kdump/kdump.txt     | 13 ++------
 arch/arm/boot/dts/keystone.dtsi   |  8 +++++
 arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
 arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
 arch/arm/kernel/machine_kexec.c   |  2 +-
 arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
 arch/arm/mach-keystone/keystone.c |  7 +----
 arch/arm/mm/idmap.c               |  2 +-
 arch/ia64/kernel/machine_kexec.c  |  2 +-
 include/linux/kexec.h             | 42 +++++++++++++++++++++++--
 kernel/kexec.c                    |  3 +-
 kernel/kexec_core.c               | 30 +++++++++---------
 kernel/ksysfs.c                   |  4 +--
 13 files changed, 193 insertions(+), 47 deletions(-)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

These changes are required for TI Keystone2 kexec to be functional.  TI
Keystone2 has the run-time view of physical memory above 4GiB, but with
a boot time alias below 4GiB which can only be used during the early
boot.

This means we need to translate run-time physical addresses (which the
kernel uses) to boot-time physical addresses, which, having discussed
with Eric, is what the kexec tools and kexec kernel API requires.

We publish a special set of boot time resources in /proc/iomem, which
the (modified) kexec tools look for in preference to the normal resources.
Hence, if these are found, the kexec tools make use of these resources,
and thus kexec tools use the boot-time view of physical memory.

The first three patches have been sitting in linux-next for a while.
I'm going to put the next ARM specific three into linux-next next week.

I've sent Eric over a month ago all the patches, including the kexec
tools patches, but I've heard nothing back.  I'm at a loss how to
make progress on these patches - and as I'm being hassled about this,
I'm going to be hassling the community about it, possibly with regular
re-posts until there is some progress.

 Documentation/kdump/kdump.txt     | 13 ++------
 arch/arm/boot/dts/keystone.dtsi   |  8 +++++
 arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
 arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
 arch/arm/kernel/machine_kexec.c   |  2 +-
 arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
 arch/arm/mach-keystone/keystone.c |  7 +----
 arch/arm/mm/idmap.c               |  2 +-
 arch/ia64/kernel/machine_kexec.c  |  2 +-
 include/linux/kexec.h             | 42 +++++++++++++++++++++++--
 kernel/kexec.c                    |  3 +-
 kernel/kexec_core.c               | 30 +++++++++---------
 kernel/ksysfs.c                   |  4 +--
 13 files changed, 193 insertions(+), 47 deletions(-)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

These changes are required for TI Keystone2 kexec to be functional.  TI
Keystone2 has the run-time view of physical memory above 4GiB, but with
a boot time alias below 4GiB which can only be used during the early
boot.

This means we need to translate run-time physical addresses (which the
kernel uses) to boot-time physical addresses, which, having discussed
with Eric, is what the kexec tools and kexec kernel API requires.

We publish a special set of boot time resources in /proc/iomem, which
the (modified) kexec tools look for in preference to the normal resources.
Hence, if these are found, the kexec tools make use of these resources,
and thus kexec tools use the boot-time view of physical memory.

The first three patches have been sitting in linux-next for a while.
I'm going to put the next ARM specific three into linux-next next week.

I've sent Eric over a month ago all the patches, including the kexec
tools patches, but I've heard nothing back.  I'm at a loss how to
make progress on these patches - and as I'm being hassled about this,
I'm going to be hassling the community about it, possibly with regular
re-posts until there is some progress.

 Documentation/kdump/kdump.txt     | 13 ++------
 arch/arm/boot/dts/keystone.dtsi   |  8 +++++
 arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
 arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
 arch/arm/kernel/machine_kexec.c   |  2 +-
 arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
 arch/arm/mach-keystone/keystone.c |  7 +----
 arch/arm/mm/idmap.c               |  2 +-
 arch/ia64/kernel/machine_kexec.c  |  2 +-
 include/linux/kexec.h             | 42 +++++++++++++++++++++++--
 kernel/kexec.c                    |  3 +-
 kernel/kexec_core.c               | 30 +++++++++---------
 kernel/ksysfs.c                   |  4 +--
 13 files changed, 193 insertions(+), 47 deletions(-)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Russell King]

When the kernel crashkernel parameter is specified with just a size, we
are supposed to allocate a region from RAM to store the crashkernel.
However, ARM merely reserves physical address zero with no checking that
there is even RAM there.

Fix this by lifting similar code from x86, importing it to ARM with the
ARM specific parameters added.  In the absence of any platform specific
information, we allocate the crashkernel region from the first 512MB of
physical memory.

Update the kdump documentation to reflect this change.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 Documentation/kdump/kdump.txt | 13 +++----------
 arch/arm/kernel/setup.c       | 29 +++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index bc4bd5a44b88..88ff63d5fde3 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -263,12 +263,6 @@ been removed from the machine.
     crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
     range=start-[end]
 
-Please note, on arm, the offset is required.
-    crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
-    range=start-[end]
-
-    'start' is inclusive and 'end' is exclusive.
-
 For example:
 
     crashkernel=512M-2G:64M,2G-:128M
@@ -307,10 +301,9 @@ Boot into System Kernel
    on the memory consumption of the kdump system. In general this is not
    dependent on the memory size of the production system.
 
-   On arm, use "crashkernel=Y@X". Note that the start address of the kernel
-   will be aligned to 128MiB (0x08000000), so if the start address is not then
-   any space below the alignment point may be overwritten by the dump-capture kernel,
-   which means it is possible that the vmcore is not that precise as expected.
+   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
+   kernel will automatically locate the crash kernel image within the
+   first 512MB of RAM if X is not given.
 
 
 Load the Dump-capture Kernel
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..77b54c461c52 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -938,6 +938,13 @@ static int __init init_machine_late(void)
 late_initcall(init_machine_late);
 
 #ifdef CONFIG_KEXEC
+/*
+ * The crash region must be aligned to 128MB to avoid
+ * zImage relocating below the reserved region.
+ */
+#define CRASH_ALIGN	(128 << 20)
+#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
+
 static inline unsigned long long get_total_mem(void)
 {
 	unsigned long total;
@@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
 	if (ret)
 		return;
 
+	if (crash_base <= 0) {
+		unsigned long long crash_max = CRASH_ADDR_MAX;
+		if (crash_max > (u32)~0)
+			crash_max = (u32)~0;
+		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
+						    crash_size, CRASH_ALIGN);
+		if (!crash_base) {
+			pr_err("crashkernel reservation failed - No suitable area found.\n");
+			return;
+		}
+	} else {
+		unsigned long long start;
+
+		start = memblock_find_in_range(crash_base,
+					       crash_base + crash_size,
+					       crash_size, SECTION_SIZE);
+		if (start != crash_base) {
+			pr_err("crashkernel reservation failed - memory is in use.\n");
+			return;
+		}
+	}
+
 	ret = memblock_reserve(crash_base, crash_size);
 	if (ret < 0) {
 		pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Russell King]

When the kernel crashkernel parameter is specified with just a size, we
are supposed to allocate a region from RAM to store the crashkernel.
However, ARM merely reserves physical address zero with no checking that
there is even RAM there.

Fix this by lifting similar code from x86, importing it to ARM with the
ARM specific parameters added.  In the absence of any platform specific
information, we allocate the crashkernel region from the first 512MB of
physical memory.

Update the kdump documentation to reflect this change.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 Documentation/kdump/kdump.txt | 13 +++----------
 arch/arm/kernel/setup.c       | 29 +++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index bc4bd5a44b88..88ff63d5fde3 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -263,12 +263,6 @@ been removed from the machine.
     crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
     range=start-[end]
 
-Please note, on arm, the offset is required.
-    crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
-    range=start-[end]
-
-    'start' is inclusive and 'end' is exclusive.
-
 For example:
 
     crashkernel=512M-2G:64M,2G-:128M
@@ -307,10 +301,9 @@ Boot into System Kernel
    on the memory consumption of the kdump system. In general this is not
    dependent on the memory size of the production system.
 
-   On arm, use "crashkernel=Y@X". Note that the start address of the kernel
-   will be aligned to 128MiB (0x08000000), so if the start address is not then
-   any space below the alignment point may be overwritten by the dump-capture kernel,
-   which means it is possible that the vmcore is not that precise as expected.
+   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
+   kernel will automatically locate the crash kernel image within the
+   first 512MB of RAM if X is not given.
 
 
 Load the Dump-capture Kernel
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..77b54c461c52 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -938,6 +938,13 @@ static int __init init_machine_late(void)
 late_initcall(init_machine_late);
 
 #ifdef CONFIG_KEXEC
+/*
+ * The crash region must be aligned to 128MB to avoid
+ * zImage relocating below the reserved region.
+ */
+#define CRASH_ALIGN	(128 << 20)
+#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
+
 static inline unsigned long long get_total_mem(void)
 {
 	unsigned long total;
@@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
 	if (ret)
 		return;
 
+	if (crash_base <= 0) {
+		unsigned long long crash_max = CRASH_ADDR_MAX;
+		if (crash_max > (u32)~0)
+			crash_max = (u32)~0;
+		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
+						    crash_size, CRASH_ALIGN);
+		if (!crash_base) {
+			pr_err("crashkernel reservation failed - No suitable area found.\n");
+			return;
+		}
+	} else {
+		unsigned long long start;
+
+		start = memblock_find_in_range(crash_base,
+					       crash_base + crash_size,
+					       crash_size, SECTION_SIZE);
+		if (start != crash_base) {
+			pr_err("crashkernel reservation failed - memory is in use.\n");
+			return;
+		}
+	}
+
 	ret = memblock_reserve(crash_base, crash_size);
 	if (ret < 0) {
 		pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
-- 
2.1.0

[PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Russell King]

When the kernel crashkernel parameter is specified with just a size, we
are supposed to allocate a region from RAM to store the crashkernel.
However, ARM merely reserves physical address zero with no checking that
there is even RAM there.

Fix this by lifting similar code from x86, importing it to ARM with the
ARM specific parameters added.  In the absence of any platform specific
information, we allocate the crashkernel region from the first 512MB of
physical memory.

Update the kdump documentation to reflect this change.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 Documentation/kdump/kdump.txt | 13 +++----------
 arch/arm/kernel/setup.c       | 29 +++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index bc4bd5a44b88..88ff63d5fde3 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -263,12 +263,6 @@ been removed from the machine.
     crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
     range=start-[end]
 
-Please note, on arm, the offset is required.
-    crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
-    range=start-[end]
-
-    'start' is inclusive and 'end' is exclusive.
-
 For example:
 
     crashkernel=512M-2G:64M,2G-:128M
@@ -307,10 +301,9 @@ Boot into System Kernel
    on the memory consumption of the kdump system. In general this is not
    dependent on the memory size of the production system.
 
-   On arm, use "crashkernel=Y at X". Note that the start address of the kernel
-   will be aligned to 128MiB (0x08000000), so if the start address is not then
-   any space below the alignment point may be overwritten by the dump-capture kernel,
-   which means it is possible that the vmcore is not that precise as expected.
+   On arm, the use of "crashkernel=Y at X" is no longer necessary; the
+   kernel will automatically locate the crash kernel image within the
+   first 512MB of RAM if X is not given.
 
 
 Load the Dump-capture Kernel
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..77b54c461c52 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -938,6 +938,13 @@ static int __init init_machine_late(void)
 late_initcall(init_machine_late);
 
 #ifdef CONFIG_KEXEC
+/*
+ * The crash region must be aligned to 128MB to avoid
+ * zImage relocating below the reserved region.
+ */
+#define CRASH_ALIGN	(128 << 20)
+#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
+
 static inline unsigned long long get_total_mem(void)
 {
 	unsigned long total;
@@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
 	if (ret)
 		return;
 
+	if (crash_base <= 0) {
+		unsigned long long crash_max = CRASH_ADDR_MAX;
+		if (crash_max > (u32)~0)
+			crash_max = (u32)~0;
+		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
+						    crash_size, CRASH_ALIGN);
+		if (!crash_base) {
+			pr_err("crashkernel reservation failed - No suitable area found.\n");
+			return;
+		}
+	} else {
+		unsigned long long start;
+
+		start = memblock_find_in_range(crash_base,
+					       crash_base + crash_size,
+					       crash_size, SECTION_SIZE);
+		if (start != crash_base) {
+			pr_err("crashkernel reservation failed - memory is in use.\n");
+			return;
+		}
+	}
+
 	ret = memblock_reserve(crash_base, crash_size);
 	if (ret < 0) {
 		pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
-- 
2.1.0

[PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Russell King]

When the kernel crashkernel parameter is specified with just a size, we
are supposed to allocate a region from RAM to store the crashkernel.
However, ARM merely reserves physical address zero with no checking that
there is even RAM there.

Fix this by lifting similar code from x86, importing it to ARM with the
ARM specific parameters added.  In the absence of any platform specific
information, we allocate the crashkernel region from the first 512MB of
physical memory.

Update the kdump documentation to reflect this change.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 Documentation/kdump/kdump.txt | 13 +++----------
 arch/arm/kernel/setup.c       | 29 +++++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index bc4bd5a44b88..88ff63d5fde3 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -263,12 +263,6 @@ been removed from the machine.
     crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
     range=start-[end]
 
-Please note, on arm, the offset is required.
-    crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
-    range=start-[end]
-
-    'start' is inclusive and 'end' is exclusive.
-
 For example:
 
     crashkernelQ2M-2G:64M,2G-:128M
@@ -307,10 +301,9 @@ Boot into System Kernel
    on the memory consumption of the kdump system. In general this is not
    dependent on the memory size of the production system.
 
-   On arm, use "crashkernel=Y@X". Note that the start address of the kernel
-   will be aligned to 128MiB (0x08000000), so if the start address is not then
-   any space below the alignment point may be overwritten by the dump-capture kernel,
-   which means it is possible that the vmcore is not that precise as expected.
+   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
+   kernel will automatically locate the crash kernel image within the
+   first 512MB of RAM if X is not given.
 
 
 Load the Dump-capture Kernel
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..77b54c461c52 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -938,6 +938,13 @@ static int __init init_machine_late(void)
 late_initcall(init_machine_late);
 
 #ifdef CONFIG_KEXEC
+/*
+ * The crash region must be aligned to 128MB to avoid
+ * zImage relocating below the reserved region.
+ */
+#define CRASH_ALIGN	(128 << 20)
+#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
+
 static inline unsigned long long get_total_mem(void)
 {
 	unsigned long total;
@@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
 	if (ret)
 		return;
 
+	if (crash_base <= 0) {
+		unsigned long long crash_max = CRASH_ADDR_MAX;
+		if (crash_max > (u32)~0)
+			crash_max = (u32)~0;
+		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
+						    crash_size, CRASH_ALIGN);
+		if (!crash_base) {
+			pr_err("crashkernel reservation failed - No suitable area found.\n");
+			return;
+		}
+	} else {
+		unsigned long long start;
+
+		start = memblock_find_in_range(crash_base,
+					       crash_base + crash_size,
+					       crash_size, SECTION_SIZE);
+		if (start != crash_base) {
+			pr_err("crashkernel reservation failed - memory is in use.\n");
+			return;
+		}
+	}
+
 	ret = memblock_reserve(crash_base, crash_size);
 	if (ret < 0) {
 		pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
-- 
2.1.0

Re: [PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:

[...]

> +   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
> +   kernel will automatically locate the crash kernel image within the
> +   first 512MB of RAM if X is not given.
>
>
>  Load the Dump-capture Kernel
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 139791ed473d..77b54c461c52 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
>  late_initcall(init_machine_late);
>
>  #ifdef CONFIG_KEXEC
> +/*
> + * The crash region must be aligned to 128MB to avoid
> + * zImage relocating below the reserved region.
> + */
> +#define CRASH_ALIGN    (128 << 20)
> +#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> +
>  static inline unsigned long long get_total_mem(void)
>  {
>         unsigned long total;
> @@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
>         if (ret)
>                 return;
>
> +       if (crash_base <= 0) {
> +               unsigned long long crash_max = CRASH_ADDR_MAX;
> +               if (crash_max > (u32)~0)
> +                       crash_max = (u32)~0;
> +               crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,

Although it does not matter, memblock_find_in_range would be able to
locate correct free area even when there is no valid RAM at address
CRASH_ALIGN. However passing PHYS_OFFSET as start argument may be more
readable probably.

> +                                                   crash_size, CRASH_ALIGN);
> +               if (!crash_base) {
> +                       pr_err("crashkernel reservation failed - No suitable area found.\n");
> +                       return;
> +               }
> +       } else {
> +               unsigned long long start;
> +
> +               start = memblock_find_in_range(crash_base,
> +                                              crash_base + crash_size,
> +                                              crash_size, SECTION_SIZE);
> +               if (start != crash_base) {
> +                       pr_err("crashkernel reservation failed - memory is in use.\n");
> +                       return;
> +               }
> +       }
> +
>         ret = memblock_reserve(crash_base, crash_size);
>         if (ret < 0) {
>                 pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
> --

Reviewed-by: Pratyush Anand <panand@redhat.com>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:

[...]

> +   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
> +   kernel will automatically locate the crash kernel image within the
> +   first 512MB of RAM if X is not given.
>
>
>  Load the Dump-capture Kernel
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 139791ed473d..77b54c461c52 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
>  late_initcall(init_machine_late);
>
>  #ifdef CONFIG_KEXEC
> +/*
> + * The crash region must be aligned to 128MB to avoid
> + * zImage relocating below the reserved region.
> + */
> +#define CRASH_ALIGN    (128 << 20)
> +#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> +
>  static inline unsigned long long get_total_mem(void)
>  {
>         unsigned long total;
> @@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
>         if (ret)
>                 return;
>
> +       if (crash_base <= 0) {
> +               unsigned long long crash_max = CRASH_ADDR_MAX;
> +               if (crash_max > (u32)~0)
> +                       crash_max = (u32)~0;
> +               crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,

Although it does not matter, memblock_find_in_range would be able to
locate correct free area even when there is no valid RAM at address
CRASH_ALIGN. However passing PHYS_OFFSET as start argument may be more
readable probably.

> +                                                   crash_size, CRASH_ALIGN);
> +               if (!crash_base) {
> +                       pr_err("crashkernel reservation failed - No suitable area found.\n");
> +                       return;
> +               }
> +       } else {
> +               unsigned long long start;
> +
> +               start = memblock_find_in_range(crash_base,
> +                                              crash_base + crash_size,
> +                                              crash_size, SECTION_SIZE);
> +               if (start != crash_base) {
> +                       pr_err("crashkernel reservation failed - memory is in use.\n");
> +                       return;
> +               }
> +       }
> +
>         ret = memblock_reserve(crash_base, crash_size);
>         if (ret < 0) {
>                 pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
> --

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:

[...]

> +   On arm, the use of "crashkernel=Y@X" is no longer necessary; the
> +   kernel will automatically locate the crash kernel image within the
> +   first 512MB of RAM if X is not given.
>
>
>  Load the Dump-capture Kernel
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 139791ed473d..77b54c461c52 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
>  late_initcall(init_machine_late);
>
>  #ifdef CONFIG_KEXEC
> +/*
> + * The crash region must be aligned to 128MB to avoid
> + * zImage relocating below the reserved region.
> + */
> +#define CRASH_ALIGN    (128 << 20)
> +#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> +
>  static inline unsigned long long get_total_mem(void)
>  {
>         unsigned long total;
> @@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
>         if (ret)
>                 return;
>
> +       if (crash_base <= 0) {
> +               unsigned long long crash_max = CRASH_ADDR_MAX;
> +               if (crash_max > (u32)~0)
> +                       crash_max = (u32)~0;
> +               crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,

Although it does not matter, memblock_find_in_range would be able to
locate correct free area even when there is no valid RAM at address
CRASH_ALIGN. However passing PHYS_OFFSET as start argument may be more
readable probably.

> +                                                   crash_size, CRASH_ALIGN);
> +               if (!crash_base) {
> +                       pr_err("crashkernel reservation failed - No suitable area found.\n");
> +                       return;
> +               }
> +       } else {
> +               unsigned long long start;
> +
> +               start = memblock_find_in_range(crash_base,
> +                                              crash_base + crash_size,
> +                                              crash_size, SECTION_SIZE);
> +               if (start != crash_base) {
> +                       pr_err("crashkernel reservation failed - memory is in use.\n");
> +                       return;
> +               }
> +       }
> +
>         ret = memblock_reserve(crash_base, crash_size);
>         if (ret < 0) {
>                 pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
> --

Reviewed-by: Pratyush Anand <panand-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/12] ARM: kexec: fix crashkernel= handling

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:

[...]

> +   On arm, the use of "crashkernel=Y at X" is no longer necessary; the
> +   kernel will automatically locate the crash kernel image within the
> +   first 512MB of RAM if X is not given.
>
>
>  Load the Dump-capture Kernel
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 139791ed473d..77b54c461c52 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -938,6 +938,13 @@ static int __init init_machine_late(void)
>  late_initcall(init_machine_late);
>
>  #ifdef CONFIG_KEXEC
> +/*
> + * The crash region must be aligned to 128MB to avoid
> + * zImage relocating below the reserved region.
> + */
> +#define CRASH_ALIGN    (128 << 20)
> +#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> +
>  static inline unsigned long long get_total_mem(void)
>  {
>         unsigned long total;
> @@ -965,6 +972,28 @@ static void __init reserve_crashkernel(void)
>         if (ret)
>                 return;
>
> +       if (crash_base <= 0) {
> +               unsigned long long crash_max = CRASH_ADDR_MAX;
> +               if (crash_max > (u32)~0)
> +                       crash_max = (u32)~0;
> +               crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,

Although it does not matter, memblock_find_in_range would be able to
locate correct free area even when there is no valid RAM at address
CRASH_ALIGN. However passing PHYS_OFFSET as start argument may be more
readable probably.

> +                                                   crash_size, CRASH_ALIGN);
> +               if (!crash_base) {
> +                       pr_err("crashkernel reservation failed - No suitable area found.\n");
> +                       return;
> +               }
> +       } else {
> +               unsigned long long start;
> +
> +               start = memblock_find_in_range(crash_base,
> +                                              crash_base + crash_size,
> +                                              crash_size, SECTION_SIZE);
> +               if (start != crash_base) {
> +                       pr_err("crashkernel reservation failed - memory is in use.\n");
> +                       return;
> +               }
> +       }
> +
>         ret = memblock_reserve(crash_base, crash_size);
>         if (ret < 0) {
>                 pr_warn("crashkernel reservation failed - memory is in use (0x%lx)\n",
> --

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 02/12] ARM: provide improved virt_to_idmap() functionality

[Russell King]

For kexec, we need more functionality from the IDMAP system.  We need to
be able to convert physical addresses to their identity mappped versions
as well as virtual addresses.

Convert the existing arch_virt_to_idmap() to deal with physical
addresses instead.

Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h     | 33 ++++++++++++++++++++++++++-------
 arch/arm/mach-keystone/keystone.c |  7 +------
 arch/arm/mm/idmap.c               |  2 +-
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 9427fd632552..ca208335fde6 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -288,19 +288,38 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define __va(x)			((void *)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)	__va((phys_addr_t)(pfn) << PAGE_SHIFT)
 
-extern unsigned long (*arch_virt_to_idmap)(unsigned long x);
+extern long long arch_phys_to_idmap_offset;
 
 /*
- * These are for systems that have a hardware interconnect supported alias of
- * physical memory for idmap purposes.  Most cases should leave these
+ * These are for systems that have a hardware interconnect supported alias
+ * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+#define IDMAP_INVALID_ADDR ((u32)~0)
+
+static inline unsigned long phys_to_idmap(phys_addr_t addr)
+{
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
+		addr += arch_phys_to_idmap_offset;
+		if (addr > (u32)~0)
+			addr = IDMAP_INVALID_ADDR;
+	}
+	return addr;
+}
+
+static inline phys_addr_t idmap_to_phys(unsigned long idmap)
+{
+	phys_addr_t addr = idmap;
+
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset)
+		addr -= arch_phys_to_idmap_offset;
+
+	return addr;
+}
+
 static inline unsigned long __virt_to_idmap(unsigned long x)
 {
-	if (IS_ENABLED(CONFIG_MMU) && arch_virt_to_idmap)
-		return arch_virt_to_idmap(x);
-	else
-		return __virt_to_phys(x);
+	return phys_to_idmap(__virt_to_phys(x));
 }
 
 #define virt_to_idmap(x)	__virt_to_idmap((unsigned long)(x))
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index e6b9cb1e6709..a33a296b00dc 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -63,11 +63,6 @@ static void __init keystone_init(void)
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static unsigned long keystone_virt_to_idmap(unsigned long x)
-{
-	return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET + KEYSTONE_LOW_PHYS_START;
-}
-
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
@@ -91,7 +86,7 @@ static long long __init keystone_pv_fixup(void)
 	offset = KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START;
 
 	/* Populate the arch idmap hook */
-	arch_virt_to_idmap = keystone_virt_to_idmap;
+	arch_phys_to_idmap_offset = -offset;
 
 	return offset;
 }
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index bd274a05b8ff..c1a48f88764e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -15,7 +15,7 @@
  * page tables.
  */
 pgd_t *idmap_pgd;
-unsigned long (*arch_virt_to_idmap)(unsigned long x);
+long long arch_phys_to_idmap_offset;
 
 #ifdef CONFIG_ARM_LPAE
 static void idmap_add_pmd(pud_t *pud, unsigned long addr, unsigned long end,
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 02/12] ARM: provide improved virt_to_idmap() functionality

[Russell King]

For kexec, we need more functionality from the IDMAP system.  We need to
be able to convert physical addresses to their identity mappped versions
as well as virtual addresses.

Convert the existing arch_virt_to_idmap() to deal with physical
addresses instead.

Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h     | 33 ++++++++++++++++++++++++++-------
 arch/arm/mach-keystone/keystone.c |  7 +------
 arch/arm/mm/idmap.c               |  2 +-
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 9427fd632552..ca208335fde6 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -288,19 +288,38 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define __va(x)			((void *)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)	__va((phys_addr_t)(pfn) << PAGE_SHIFT)
 
-extern unsigned long (*arch_virt_to_idmap)(unsigned long x);
+extern long long arch_phys_to_idmap_offset;
 
 /*
- * These are for systems that have a hardware interconnect supported alias of
- * physical memory for idmap purposes.  Most cases should leave these
+ * These are for systems that have a hardware interconnect supported alias
+ * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+#define IDMAP_INVALID_ADDR ((u32)~0)
+
+static inline unsigned long phys_to_idmap(phys_addr_t addr)
+{
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
+		addr += arch_phys_to_idmap_offset;
+		if (addr > (u32)~0)
+			addr = IDMAP_INVALID_ADDR;
+	}
+	return addr;
+}
+
+static inline phys_addr_t idmap_to_phys(unsigned long idmap)
+{
+	phys_addr_t addr = idmap;
+
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset)
+		addr -= arch_phys_to_idmap_offset;
+
+	return addr;
+}
+
 static inline unsigned long __virt_to_idmap(unsigned long x)
 {
-	if (IS_ENABLED(CONFIG_MMU) && arch_virt_to_idmap)
-		return arch_virt_to_idmap(x);
-	else
-		return __virt_to_phys(x);
+	return phys_to_idmap(__virt_to_phys(x));
 }
 
 #define virt_to_idmap(x)	__virt_to_idmap((unsigned long)(x))
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index e6b9cb1e6709..a33a296b00dc 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -63,11 +63,6 @@ static void __init keystone_init(void)
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static unsigned long keystone_virt_to_idmap(unsigned long x)
-{
-	return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET + KEYSTONE_LOW_PHYS_START;
-}
-
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
@@ -91,7 +86,7 @@ static long long __init keystone_pv_fixup(void)
 	offset = KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START;
 
 	/* Populate the arch idmap hook */
-	arch_virt_to_idmap = keystone_virt_to_idmap;
+	arch_phys_to_idmap_offset = -offset;
 
 	return offset;
 }
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index bd274a05b8ff..c1a48f88764e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -15,7 +15,7 @@
  * page tables.
  */
 pgd_t *idmap_pgd;
-unsigned long (*arch_virt_to_idmap)(unsigned long x);
+long long arch_phys_to_idmap_offset;
 
 #ifdef CONFIG_ARM_LPAE
 static void idmap_add_pmd(pud_t *pud, unsigned long addr, unsigned long end,
-- 
2.1.0

[PATCH 02/12] ARM: provide improved virt_to_idmap() functionality

[Russell King]

For kexec, we need more functionality from the IDMAP system.  We need to
be able to convert physical addresses to their identity mappped versions
as well as virtual addresses.

Convert the existing arch_virt_to_idmap() to deal with physical
addresses instead.

Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h     | 33 ++++++++++++++++++++++++++-------
 arch/arm/mach-keystone/keystone.c |  7 +------
 arch/arm/mm/idmap.c               |  2 +-
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 9427fd632552..ca208335fde6 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -288,19 +288,38 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define __va(x)			((void *)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)	__va((phys_addr_t)(pfn) << PAGE_SHIFT)
 
-extern unsigned long (*arch_virt_to_idmap)(unsigned long x);
+extern long long arch_phys_to_idmap_offset;
 
 /*
- * These are for systems that have a hardware interconnect supported alias of
- * physical memory for idmap purposes.  Most cases should leave these
+ * These are for systems that have a hardware interconnect supported alias
+ * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+#define IDMAP_INVALID_ADDR ((u32)~0)
+
+static inline unsigned long phys_to_idmap(phys_addr_t addr)
+{
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
+		addr += arch_phys_to_idmap_offset;
+		if (addr > (u32)~0)
+			addr = IDMAP_INVALID_ADDR;
+	}
+	return addr;
+}
+
+static inline phys_addr_t idmap_to_phys(unsigned long idmap)
+{
+	phys_addr_t addr = idmap;
+
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset)
+		addr -= arch_phys_to_idmap_offset;
+
+	return addr;
+}
+
 static inline unsigned long __virt_to_idmap(unsigned long x)
 {
-	if (IS_ENABLED(CONFIG_MMU) && arch_virt_to_idmap)
-		return arch_virt_to_idmap(x);
-	else
-		return __virt_to_phys(x);
+	return phys_to_idmap(__virt_to_phys(x));
 }
 
 #define virt_to_idmap(x)	__virt_to_idmap((unsigned long)(x))
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index e6b9cb1e6709..a33a296b00dc 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -63,11 +63,6 @@ static void __init keystone_init(void)
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static unsigned long keystone_virt_to_idmap(unsigned long x)
-{
-	return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET + KEYSTONE_LOW_PHYS_START;
-}
-
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
@@ -91,7 +86,7 @@ static long long __init keystone_pv_fixup(void)
 	offset = KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START;
 
 	/* Populate the arch idmap hook */
-	arch_virt_to_idmap = keystone_virt_to_idmap;
+	arch_phys_to_idmap_offset = -offset;
 
 	return offset;
 }
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index bd274a05b8ff..c1a48f88764e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -15,7 +15,7 @@
  * page tables.
  */
 pgd_t *idmap_pgd;
-unsigned long (*arch_virt_to_idmap)(unsigned long x);
+long long arch_phys_to_idmap_offset;
 
 #ifdef CONFIG_ARM_LPAE
 static void idmap_add_pmd(pud_t *pud, unsigned long addr, unsigned long end,
-- 
2.1.0

[PATCH 02/12] ARM: provide improved virt_to_idmap() functionality

[Russell King]

For kexec, we need more functionality from the IDMAP system.  We need to
be able to convert physical addresses to their identity mappped versions
as well as virtual addresses.

Convert the existing arch_virt_to_idmap() to deal with physical
addresses instead.

Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h     | 33 ++++++++++++++++++++++++++-------
 arch/arm/mach-keystone/keystone.c |  7 +------
 arch/arm/mm/idmap.c               |  2 +-
 3 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 9427fd632552..ca208335fde6 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -288,19 +288,38 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define __va(x)			((void *)__phys_to_virt((phys_addr_t)(x)))
 #define pfn_to_kaddr(pfn)	__va((phys_addr_t)(pfn) << PAGE_SHIFT)
 
-extern unsigned long (*arch_virt_to_idmap)(unsigned long x);
+extern long long arch_phys_to_idmap_offset;
 
 /*
- * These are for systems that have a hardware interconnect supported alias of
- * physical memory for idmap purposes.  Most cases should leave these
+ * These are for systems that have a hardware interconnect supported alias
+ * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+#define IDMAP_INVALID_ADDR ((u32)~0)
+
+static inline unsigned long phys_to_idmap(phys_addr_t addr)
+{
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset) {
+		addr += arch_phys_to_idmap_offset;
+		if (addr > (u32)~0)
+			addr = IDMAP_INVALID_ADDR;
+	}
+	return addr;
+}
+
+static inline phys_addr_t idmap_to_phys(unsigned long idmap)
+{
+	phys_addr_t addr = idmap;
+
+	if (IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset)
+		addr -= arch_phys_to_idmap_offset;
+
+	return addr;
+}
+
 static inline unsigned long __virt_to_idmap(unsigned long x)
 {
-	if (IS_ENABLED(CONFIG_MMU) && arch_virt_to_idmap)
-		return arch_virt_to_idmap(x);
-	else
-		return __virt_to_phys(x);
+	return phys_to_idmap(__virt_to_phys(x));
 }
 
 #define virt_to_idmap(x)	__virt_to_idmap((unsigned long)(x))
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index e6b9cb1e6709..a33a296b00dc 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -63,11 +63,6 @@ static void __init keystone_init(void)
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-static unsigned long keystone_virt_to_idmap(unsigned long x)
-{
-	return (phys_addr_t)(x) - CONFIG_PAGE_OFFSET + KEYSTONE_LOW_PHYS_START;
-}
-
 static long long __init keystone_pv_fixup(void)
 {
 	long long offset;
@@ -91,7 +86,7 @@ static long long __init keystone_pv_fixup(void)
 	offset = KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START;
 
 	/* Populate the arch idmap hook */
-	arch_virt_to_idmap = keystone_virt_to_idmap;
+	arch_phys_to_idmap_offset = -offset;
 
 	return offset;
 }
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index bd274a05b8ff..c1a48f88764e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -15,7 +15,7 @@
  * page tables.
  */
 pgd_t *idmap_pgd;
-unsigned long (*arch_virt_to_idmap)(unsigned long x);
+long long arch_phys_to_idmap_offset;
 
 #ifdef CONFIG_ARM_LPAE
 static void idmap_add_pmd(pud_t *pud, unsigned long addr, unsigned long end,
-- 
2.1.0

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King]

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 77b54c461c52..d9317eec1eba 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -943,7 +943,6 @@ late_initcall(init_machine_late);
  * zImage relocating below the reserved region.
  */
 #define CRASH_ALIGN	(128 << 20)
-#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
 
 static inline unsigned long long get_total_mem(void)
 {
@@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
 		return;
 
 	if (crash_base <= 0) {
-		unsigned long long crash_max = CRASH_ADDR_MAX;
-		if (crash_max > (u32)~0)
-			crash_max = (u32)~0;
+		unsigned long long crash_max = idmap_to_phys((u32)~0);
 		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
 						    crash_size, CRASH_ALIGN);
 		if (!crash_base) {
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King]

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 77b54c461c52..d9317eec1eba 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -943,7 +943,6 @@ late_initcall(init_machine_late);
  * zImage relocating below the reserved region.
  */
 #define CRASH_ALIGN	(128 << 20)
-#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
 
 static inline unsigned long long get_total_mem(void)
 {
@@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
 		return;
 
 	if (crash_base <= 0) {
-		unsigned long long crash_max = CRASH_ADDR_MAX;
-		if (crash_max > (u32)~0)
-			crash_max = (u32)~0;
+		unsigned long long crash_max = idmap_to_phys((u32)~0);
 		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
 						    crash_size, CRASH_ALIGN);
 		if (!crash_base) {
-- 
2.1.0

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King]

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 77b54c461c52..d9317eec1eba 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -943,7 +943,6 @@ late_initcall(init_machine_late);
  * zImage relocating below the reserved region.
  */
 #define CRASH_ALIGN	(128 << 20)
-#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
 
 static inline unsigned long long get_total_mem(void)
 {
@@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
 		return;
 
 	if (crash_base <= 0) {
-		unsigned long long crash_max = CRASH_ADDR_MAX;
-		if (crash_max > (u32)~0)
-			crash_max = (u32)~0;
+		unsigned long long crash_max = idmap_to_phys((u32)~0);
 		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
 						    crash_size, CRASH_ALIGN);
 		if (!crash_base) {
-- 
2.1.0

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King]

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 77b54c461c52..d9317eec1eba 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -943,7 +943,6 @@ late_initcall(init_machine_late);
  * zImage relocating below the reserved region.
  */
 #define CRASH_ALIGN	(128 << 20)
-#define CRASH_ADDR_MAX	(PHYS_OFFSET + (512 << 20))
 
 static inline unsigned long long get_total_mem(void)
 {
@@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
 		return;
 
 	if (crash_base <= 0) {
-		unsigned long long crash_max = CRASH_ADDR_MAX;
-		if (crash_max > (u32)~0)
-			crash_max = (u32)~0;
+		unsigned long long crash_max = idmap_to_phys((u32)~0);
 		crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
 						    crash_size, CRASH_ALIGN);
 		if (!crash_base) {
-- 
2.1.0

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/kernel/setup.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 77b54c461c52..d9317eec1eba 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>   * zImage relocating below the reserved region.
>   */
>  #define CRASH_ALIGN    (128 << 20)
> -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>
>  static inline unsigned long long get_total_mem(void)
>  {
> @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>                 return;
>
>         if (crash_base <= 0) {
> -               unsigned long long crash_max = CRASH_ADDR_MAX;
> -               if (crash_max > (u32)~0)
> -                       crash_max = (u32)~0;
> +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>                                                     crash_size, CRASH_ALIGN);
>                 if (!crash_base) {

Reviewed-by: Pratyush Anand <panand@redhat.com>

Unrelated to these modification:
In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
would be more appropriate?
memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/kernel/setup.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 77b54c461c52..d9317eec1eba 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>   * zImage relocating below the reserved region.
>   */
>  #define CRASH_ALIGN    (128 << 20)
> -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>
>  static inline unsigned long long get_total_mem(void)
>  {
> @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>                 return;
>
>         if (crash_base <= 0) {
> -               unsigned long long crash_max = CRASH_ADDR_MAX;
> -               if (crash_max > (u32)~0)
> -                       crash_max = (u32)~0;
> +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>                                                     crash_size, CRASH_ALIGN);
>                 if (!crash_base) {

Reviewed-by: Pratyush Anand <panand@redhat.com>

Unrelated to these modification:
In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
would be more appropriate?
memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/kernel/setup.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 77b54c461c52..d9317eec1eba 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>   * zImage relocating below the reserved region.
>   */
>  #define CRASH_ALIGN    (128 << 20)
> -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>
>  static inline unsigned long long get_total_mem(void)
>  {
> @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>                 return;
>
>         if (crash_base <= 0) {
> -               unsigned long long crash_max = CRASH_ADDR_MAX;
> -               if (crash_max > (u32)~0)
> -                       crash_max = (u32)~0;
> +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>                                                     crash_size, CRASH_ALIGN);
>                 if (!crash_base) {

Reviewed-by: Pratyush Anand <panand@redhat.com>

Unrelated to these modification:
In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
would be more appropriate?
memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:57 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/kernel/setup.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 77b54c461c52..d9317eec1eba 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>   * zImage relocating below the reserved region.
>   */
>  #define CRASH_ALIGN    (128 << 20)
> -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>
>  static inline unsigned long long get_total_mem(void)
>  {
> @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>                 return;
>
>         if (crash_base <= 0) {
> -               unsigned long long crash_max = CRASH_ADDR_MAX;
> -               if (crash_max > (u32)~0)
> -                       crash_max = (u32)~0;
> +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>                                                     crash_size, CRASH_ALIGN);
>                 if (!crash_base) {

Reviewed-by: Pratyush Anand <panand@redhat.com>

Unrelated to these modification:
In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
would be more appropriate?
memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> >  arch/arm/kernel/setup.c | 5 +----
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 77b54c461c52..d9317eec1eba 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >   * zImage relocating below the reserved region.
> >   */
> >  #define CRASH_ALIGN    (128 << 20)
> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >
> >  static inline unsigned long long get_total_mem(void)
> >  {
> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >                 return;
> >
> >         if (crash_base <= 0) {
> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> > -               if (crash_max > (u32)~0)
> > -                       crash_max = (u32)~0;
> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >                                                     crash_size, CRASH_ALIGN);
> >                 if (!crash_base) {
> 
> Reviewed-by: Pratyush Anand <panand@redhat.com>
> 
> Unrelated to these modification:
> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> would be more appropriate?
> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
*removes* the memory range from memblock, including removing the 
mapping of that memory.  It will make the memory range inaccessible to
the kernel.

Since kexec wants to write directly to this memory, using
arm_memblock_steal() will have the cause the kernel to OOPS when
it hits the resulting hole.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> > Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> > ---
> >  arch/arm/kernel/setup.c | 5 +----
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 77b54c461c52..d9317eec1eba 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >   * zImage relocating below the reserved region.
> >   */
> >  #define CRASH_ALIGN    (128 << 20)
> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >
> >  static inline unsigned long long get_total_mem(void)
> >  {
> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >                 return;
> >
> >         if (crash_base <= 0) {
> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> > -               if (crash_max > (u32)~0)
> > -                       crash_max = (u32)~0;
> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >                                                     crash_size, CRASH_ALIGN);
> >                 if (!crash_base) {
> 
> Reviewed-by: Pratyush Anand <panand-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> 
> Unrelated to these modification:
> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> would be more appropriate?
> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
*removes* the memory range from memblock, including removing the 
mapping of that memory.  It will make the memory range inaccessible to
the kernel.

Since kexec wants to write directly to this memory, using
arm_memblock_steal() will have the cause the kernel to OOPS when
it hits the resulting hole.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> >  arch/arm/kernel/setup.c | 5 +----
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 77b54c461c52..d9317eec1eba 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >   * zImage relocating below the reserved region.
> >   */
> >  #define CRASH_ALIGN    (128 << 20)
> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >
> >  static inline unsigned long long get_total_mem(void)
> >  {
> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >                 return;
> >
> >         if (crash_base <= 0) {
> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> > -               if (crash_max > (u32)~0)
> > -                       crash_max = (u32)~0;
> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >                                                     crash_size, CRASH_ALIGN);
> >                 if (!crash_base) {
> 
> Reviewed-by: Pratyush Anand <panand@redhat.com>
> 
> Unrelated to these modification:
> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> would be more appropriate?
> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
*removes* the memory range from memblock, including removing the 
mapping of that memory.  It will make the memory range inaccessible to
the kernel.

Since kexec wants to write directly to this memory, using
arm_memblock_steal() will have the cause the kernel to OOPS when
it hits the resulting hole.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> >  arch/arm/kernel/setup.c | 5 +----
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 77b54c461c52..d9317eec1eba 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >   * zImage relocating below the reserved region.
> >   */
> >  #define CRASH_ALIGN    (128 << 20)
> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >
> >  static inline unsigned long long get_total_mem(void)
> >  {
> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >                 return;
> >
> >         if (crash_base <= 0) {
> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> > -               if (crash_max > (u32)~0)
> > -                       crash_max = (u32)~0;
> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >                                                     crash_size, CRASH_ALIGN);
> >                 if (!crash_base) {
> 
> Reviewed-by: Pratyush Anand <panand@redhat.com>
> 
> Unrelated to these modification:
> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> would be more appropriate?
> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));

No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
*removes* the memory range from memblock, including removing the 
mapping of that memory.  It will make the memory range inaccessible to
the kernel.

Since kexec wants to write directly to this memory, using
arm_memblock_steal() will have the cause the kernel to OOPS when
it hits the resulting hole.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> > ---
>> >  arch/arm/kernel/setup.c | 5 +----
>> >  1 file changed, 1 insertion(+), 4 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> > index 77b54c461c52..d9317eec1eba 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>> >   * zImage relocating below the reserved region.
>> >   */
>> >  #define CRASH_ALIGN    (128 << 20)
>> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>> >
>> >  static inline unsigned long long get_total_mem(void)
>> >  {
>> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>> >                 return;
>> >
>> >         if (crash_base <= 0) {
>> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
>> > -               if (crash_max > (u32)~0)
>> > -                       crash_max = (u32)~0;
>> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>> >                                                     crash_size, CRASH_ALIGN);
>> >                 if (!crash_base) {
>>
>> Reviewed-by: Pratyush Anand <panand@redhat.com>
>>
>> Unrelated to these modification:
>> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
>> would be more appropriate?
>> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
>
> No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> *removes* the memory range from memblock, including removing the
> mapping of that memory.  It will make the memory range inaccessible to
> the kernel.
>
> Since kexec wants to write directly to this memory, using
> arm_memblock_steal() will have the cause the kernel to OOPS when
> it hits the resulting hole.
>

Sorry, I was not trying to say that we should use arm_memblock_steal()
here. As I said, this comment is totally unrelated to this patch
series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
max_addr. Probably,  it would be good to pass
idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> > ---
>> >  arch/arm/kernel/setup.c | 5 +----
>> >  1 file changed, 1 insertion(+), 4 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> > index 77b54c461c52..d9317eec1eba 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>> >   * zImage relocating below the reserved region.
>> >   */
>> >  #define CRASH_ALIGN    (128 << 20)
>> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>> >
>> >  static inline unsigned long long get_total_mem(void)
>> >  {
>> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>> >                 return;
>> >
>> >         if (crash_base <= 0) {
>> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
>> > -               if (crash_max > (u32)~0)
>> > -                       crash_max = (u32)~0;
>> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>> >                                                     crash_size, CRASH_ALIGN);
>> >                 if (!crash_base) {
>>
>> Reviewed-by: Pratyush Anand <panand@redhat.com>
>>
>> Unrelated to these modification:
>> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
>> would be more appropriate?
>> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
>
> No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> *removes* the memory range from memblock, including removing the
> mapping of that memory.  It will make the memory range inaccessible to
> the kernel.
>
> Since kexec wants to write directly to this memory, using
> arm_memblock_steal() will have the cause the kernel to OOPS when
> it hits the resulting hole.
>

Sorry, I was not trying to say that we should use arm_memblock_steal()
here. As I said, this comment is totally unrelated to this patch
series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
max_addr. Probably,  it would be good to pass
idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> > ---
>> >  arch/arm/kernel/setup.c | 5 +----
>> >  1 file changed, 1 insertion(+), 4 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> > index 77b54c461c52..d9317eec1eba 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>> >   * zImage relocating below the reserved region.
>> >   */
>> >  #define CRASH_ALIGN    (128 << 20)
>> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>> >
>> >  static inline unsigned long long get_total_mem(void)
>> >  {
>> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>> >                 return;
>> >
>> >         if (crash_base <= 0) {
>> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
>> > -               if (crash_max > (u32)~0)
>> > -                       crash_max = (u32)~0;
>> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>> >                                                     crash_size, CRASH_ALIGN);
>> >                 if (!crash_base) {
>>
>> Reviewed-by: Pratyush Anand <panand@redhat.com>
>>
>> Unrelated to these modification:
>> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
>> would be more appropriate?
>> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
>
> No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> *removes* the memory range from memblock, including removing the
> mapping of that memory.  It will make the memory range inaccessible to
> the kernel.
>
> Since kexec wants to write directly to this memory, using
> arm_memblock_steal() will have the cause the kernel to OOPS when
> it hits the resulting hole.
>

Sorry, I was not trying to say that we should use arm_memblock_steal()
here. As I said, this comment is totally unrelated to this patch
series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
max_addr. Probably,  it would be good to pass
idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> > ---
>> >  arch/arm/kernel/setup.c | 5 +----
>> >  1 file changed, 1 insertion(+), 4 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> > index 77b54c461c52..d9317eec1eba 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
>> >   * zImage relocating below the reserved region.
>> >   */
>> >  #define CRASH_ALIGN    (128 << 20)
>> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
>> >
>> >  static inline unsigned long long get_total_mem(void)
>> >  {
>> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
>> >                 return;
>> >
>> >         if (crash_base <= 0) {
>> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
>> > -               if (crash_max > (u32)~0)
>> > -                       crash_max = (u32)~0;
>> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
>> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
>> >                                                     crash_size, CRASH_ALIGN);
>> >                 if (!crash_base) {
>>
>> Reviewed-by: Pratyush Anand <panand@redhat.com>
>>
>> Unrelated to these modification:
>> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
>> would be more appropriate?
>> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
>
> No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> *removes* the memory range from memblock, including removing the
> mapping of that memory.  It will make the memory range inaccessible to
> the kernel.
>
> Since kexec wants to write directly to this memory, using
> arm_memblock_steal() will have the cause the kernel to OOPS when
> it hits the resulting hole.
>

Sorry, I was not trying to say that we should use arm_memblock_steal()
here. As I said, this comment is totally unrelated to this patch
series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
max_addr. Probably,  it would be good to pass
idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 09:06:19AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> >> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> > ---
> >> >  arch/arm/kernel/setup.c | 5 +----
> >> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >> >
> >> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> >> > index 77b54c461c52..d9317eec1eba 100644
> >> > --- a/arch/arm/kernel/setup.c
> >> > +++ b/arch/arm/kernel/setup.c
> >> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >> >   * zImage relocating below the reserved region.
> >> >   */
> >> >  #define CRASH_ALIGN    (128 << 20)
> >> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >> >
> >> >  static inline unsigned long long get_total_mem(void)
> >> >  {
> >> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >> >                 return;
> >> >
> >> >         if (crash_base <= 0) {
> >> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> >> > -               if (crash_max > (u32)~0)
> >> > -                       crash_max = (u32)~0;
> >> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >> >                                                     crash_size, CRASH_ALIGN);
> >> >                 if (!crash_base) {
> >>
> >> Reviewed-by: Pratyush Anand <panand@redhat.com>
> >>
> >> Unrelated to these modification:
> >> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> >> would be more appropriate?
> >> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
> >
> > No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> > *removes* the memory range from memblock, including removing the
> > mapping of that memory.  It will make the memory range inaccessible to
> > the kernel.
> >
> > Since kexec wants to write directly to this memory, using
> > arm_memblock_steal() will have the cause the kernel to OOPS when
> > it hits the resulting hole.
> >
> 
> Sorry, I was not trying to say that we should use arm_memblock_steal()
> here. As I said, this comment is totally unrelated to this patch
> series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
> max_addr. Probably,  it would be good to pass
> idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

No.

	idmap_to_phys((u32)~0)

This returns the maximum running-view physical address that corresponds
with the top of the boot-view physical address space.  That's exactly
what we want, not "any physical address".  In any case,
MEMBLOCK_ALLOC_ANYWHERE is a 64-bit physical address consisting of all-
ones.  The compiler will truncate it down to a 32-bit address due to
idmap_to_phys()'s prototype, but that's really not the point - it's the
wrong constant to be used here.  This isn't a memblock function, and
it shouldn't be passed a 64-bit address.

The difference is that arm_memblock_steal() is about stealing memory
from the system which can be allocated in the running-view.  It's got
nothing to do with boot-view stuff.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 09:06:19AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> >> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> > ---
> >> >  arch/arm/kernel/setup.c | 5 +----
> >> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >> >
> >> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> >> > index 77b54c461c52..d9317eec1eba 100644
> >> > --- a/arch/arm/kernel/setup.c
> >> > +++ b/arch/arm/kernel/setup.c
> >> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >> >   * zImage relocating below the reserved region.
> >> >   */
> >> >  #define CRASH_ALIGN    (128 << 20)
> >> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >> >
> >> >  static inline unsigned long long get_total_mem(void)
> >> >  {
> >> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >> >                 return;
> >> >
> >> >         if (crash_base <= 0) {
> >> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> >> > -               if (crash_max > (u32)~0)
> >> > -                       crash_max = (u32)~0;
> >> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >> >                                                     crash_size, CRASH_ALIGN);
> >> >                 if (!crash_base) {
> >>
> >> Reviewed-by: Pratyush Anand <panand@redhat.com>
> >>
> >> Unrelated to these modification:
> >> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> >> would be more appropriate?
> >> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
> >
> > No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> > *removes* the memory range from memblock, including removing the
> > mapping of that memory.  It will make the memory range inaccessible to
> > the kernel.
> >
> > Since kexec wants to write directly to this memory, using
> > arm_memblock_steal() will have the cause the kernel to OOPS when
> > it hits the resulting hole.
> >
> 
> Sorry, I was not trying to say that we should use arm_memblock_steal()
> here. As I said, this comment is totally unrelated to this patch
> series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
> max_addr. Probably,  it would be good to pass
> idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

No.

	idmap_to_phys((u32)~0)

This returns the maximum running-view physical address that corresponds
with the top of the boot-view physical address space.  That's exactly
what we want, not "any physical address".  In any case,
MEMBLOCK_ALLOC_ANYWHERE is a 64-bit physical address consisting of all-
ones.  The compiler will truncate it down to a 32-bit address due to
idmap_to_phys()'s prototype, but that's really not the point - it's the
wrong constant to be used here.  This isn't a memblock function, and
it shouldn't be passed a 64-bit address.

The difference is that arm_memblock_steal() is about stealing memory
from the system which can be allocated in the running-view.  It's got
nothing to do with boot-view stuff.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 09:06:19AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> >> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> > ---
> >> >  arch/arm/kernel/setup.c | 5 +----
> >> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >> >
> >> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> >> > index 77b54c461c52..d9317eec1eba 100644
> >> > --- a/arch/arm/kernel/setup.c
> >> > +++ b/arch/arm/kernel/setup.c
> >> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >> >   * zImage relocating below the reserved region.
> >> >   */
> >> >  #define CRASH_ALIGN    (128 << 20)
> >> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >> >
> >> >  static inline unsigned long long get_total_mem(void)
> >> >  {
> >> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >> >                 return;
> >> >
> >> >         if (crash_base <= 0) {
> >> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> >> > -               if (crash_max > (u32)~0)
> >> > -                       crash_max = (u32)~0;
> >> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >> >                                                     crash_size, CRASH_ALIGN);
> >> >                 if (!crash_base) {
> >>
> >> Reviewed-by: Pratyush Anand <panand@redhat.com>
> >>
> >> Unrelated to these modification:
> >> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> >> would be more appropriate?
> >> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
> >
> > No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> > *removes* the memory range from memblock, including removing the
> > mapping of that memory.  It will make the memory range inaccessible to
> > the kernel.
> >
> > Since kexec wants to write directly to this memory, using
> > arm_memblock_steal() will have the cause the kernel to OOPS when
> > it hits the resulting hole.
> >
> 
> Sorry, I was not trying to say that we should use arm_memblock_steal()
> here. As I said, this comment is totally unrelated to this patch
> series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
> max_addr. Probably,  it would be good to pass
> idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

No.

	idmap_to_phys((u32)~0)

This returns the maximum running-view physical address that corresponds
with the top of the boot-view physical address space.  That's exactly
what we want, not "any physical address".  In any case,
MEMBLOCK_ALLOC_ANYWHERE is a 64-bit physical address consisting of all-
ones.  The compiler will truncate it down to a 32-bit address due to
idmap_to_phys()'s prototype, but that's really not the point - it's the
wrong constant to be used here.  This isn't a memblock function, and
it shouldn't be passed a 64-bit address.

The difference is that arm_memblock_steal() is about stealing memory
from the system which can be allocated in the running-view.  It's got
nothing to do with boot-view stuff.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 03/12] ARM: kexec: remove 512MB restriction on kexec crashdump

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 09:06:19AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> >> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> > ---
> >> >  arch/arm/kernel/setup.c | 5 +----
> >> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >> >
> >> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> >> > index 77b54c461c52..d9317eec1eba 100644
> >> > --- a/arch/arm/kernel/setup.c
> >> > +++ b/arch/arm/kernel/setup.c
> >> > @@ -943,7 +943,6 @@ late_initcall(init_machine_late);
> >> >   * zImage relocating below the reserved region.
> >> >   */
> >> >  #define CRASH_ALIGN    (128 << 20)
> >> > -#define CRASH_ADDR_MAX (PHYS_OFFSET + (512 << 20))
> >> >
> >> >  static inline unsigned long long get_total_mem(void)
> >> >  {
> >> > @@ -973,9 +972,7 @@ static void __init reserve_crashkernel(void)
> >> >                 return;
> >> >
> >> >         if (crash_base <= 0) {
> >> > -               unsigned long long crash_max = CRASH_ADDR_MAX;
> >> > -               if (crash_max > (u32)~0)
> >> > -                       crash_max = (u32)~0;
> >> > +               unsigned long long crash_max = idmap_to_phys((u32)~0);
> >> >                 crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
> >> >                                                     crash_size, CRASH_ALIGN);
> >> >                 if (!crash_base) {
> >>
> >> Reviewed-by: Pratyush Anand <panand@redhat.com>
> >>
> >> Unrelated to these modification:
> >> In function arch/arm/mm/init.c: arm_memblock_steal() may be  following
> >> would be more appropriate?
> >> memblock_alloc_base(size, align, idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE));
> >
> > No, arm_memblock_steal() is totally unsuitable.  arm_memblock_steal()
> > *removes* the memory range from memblock, including removing the
> > mapping of that memory.  It will make the memory range inaccessible to
> > the kernel.
> >
> > Since kexec wants to write directly to this memory, using
> > arm_memblock_steal() will have the cause the kernel to OOPS when
> > it hits the resulting hole.
> >
> 
> Sorry, I was not trying to say that we should use arm_memblock_steal()
> here. As I said, this comment is totally unrelated to this patch
> series. In arm_memblock_steal() we pass MEMBLOCK_ALLOC_ANYWHERE as
> max_addr. Probably,  it would be good to pass
> idmap_to_phys(MEMBLOCK_ALLOC_ANYWHERE).

No.

	idmap_to_phys((u32)~0)

This returns the maximum running-view physical address that corresponds
with the top of the boot-view physical address space.  That's exactly
what we want, not "any physical address".  In any case,
MEMBLOCK_ALLOC_ANYWHERE is a 64-bit physical address consisting of all-
ones.  The compiler will truncate it down to a 32-bit address due to
idmap_to_phys()'s prototype, but that's really not the point - it's the
wrong constant to be used here.  This isn't a memblock function, and
it shouldn't be passed a 64-bit address.

The difference is that arm_memblock_steal() is about stealing memory
from the system which can be allocated in the running-view.  It's got
nothing to do with boot-view stuff.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Russell King]

Provide a helper to indicate whether we need to perform special handling
for boot identity mapping aliases or not.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ca208335fde6..31c07a2cc100 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
  * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+static inline bool arm_has_idmap_alias(void)
+{
+	return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
+}
+
 #define IDMAP_INVALID_ADDR ((u32)~0)
 
 static inline unsigned long phys_to_idmap(phys_addr_t addr)
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Russell King]

Provide a helper to indicate whether we need to perform special handling
for boot identity mapping aliases or not.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ca208335fde6..31c07a2cc100 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
  * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+static inline bool arm_has_idmap_alias(void)
+{
+	return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
+}
+
 #define IDMAP_INVALID_ADDR ((u32)~0)
 
 static inline unsigned long phys_to_idmap(phys_addr_t addr)
-- 
2.1.0

[PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Russell King]

Provide a helper to indicate whether we need to perform special handling
for boot identity mapping aliases or not.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ca208335fde6..31c07a2cc100 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
  * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+static inline bool arm_has_idmap_alias(void)
+{
+	return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
+}
+
 #define IDMAP_INVALID_ADDR ((u32)~0)
 
 static inline unsigned long phys_to_idmap(phys_addr_t addr)
-- 
2.1.0

[PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Russell King]

Provide a helper to indicate whether we need to perform special handling
for boot identity mapping aliases or not.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/memory.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ca208335fde6..31c07a2cc100 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
  * of physical memory for idmap purposes.  Most cases should leave these
  * untouched.  Note: this can only return addresses less than 4GiB.
  */
+static inline bool arm_has_idmap_alias(void)
+{
+	return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
+}
+
 #define IDMAP_INVALID_ADDR ((u32)~0)
 
 static inline unsigned long phys_to_idmap(phys_addr_t addr)
-- 
2.1.0

Re: [PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Provide a helper to indicate whether we need to perform special handling
> for boot identity mapping aliases or not.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/include/asm/memory.h | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ca208335fde6..31c07a2cc100 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
>   * of physical memory for idmap purposes.  Most cases should leave these
>   * untouched.  Note: this can only return addresses less than 4GiB.
>   */
> +static inline bool arm_has_idmap_alias(void)
> +{
> +       return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
> +}
> +
>  #define IDMAP_INVALID_ADDR ((u32)~0)
>
>  static inline unsigned long phys_to_idmap(phys_addr_t addr)

Reviewed-by: Pratyush Anand <panand@redhat.com>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Provide a helper to indicate whether we need to perform special handling
> for boot identity mapping aliases or not.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/include/asm/memory.h | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ca208335fde6..31c07a2cc100 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
>   * of physical memory for idmap purposes.  Most cases should leave these
>   * untouched.  Note: this can only return addresses less than 4GiB.
>   */
> +static inline bool arm_has_idmap_alias(void)
> +{
> +       return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
> +}
> +
>  #define IDMAP_INVALID_ADDR ((u32)~0)
>
>  static inline unsigned long phys_to_idmap(phys_addr_t addr)

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Provide a helper to indicate whether we need to perform special handling
> for boot identity mapping aliases or not.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/include/asm/memory.h | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ca208335fde6..31c07a2cc100 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
>   * of physical memory for idmap purposes.  Most cases should leave these
>   * untouched.  Note: this can only return addresses less than 4GiB.
>   */
> +static inline bool arm_has_idmap_alias(void)
> +{
> +       return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
> +}
> +
>  #define IDMAP_INVALID_ADDR ((u32)~0)
>
>  static inline unsigned long phys_to_idmap(phys_addr_t addr)

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 04/12] ARM: provide arm_has_idmap_alias() helper

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Provide a helper to indicate whether we need to perform special handling
> for boot identity mapping aliases or not.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/include/asm/memory.h | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ca208335fde6..31c07a2cc100 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -295,6 +295,11 @@ extern long long arch_phys_to_idmap_offset;
>   * of physical memory for idmap purposes.  Most cases should leave these
>   * untouched.  Note: this can only return addresses less than 4GiB.
>   */
> +static inline bool arm_has_idmap_alias(void)
> +{
> +       return IS_ENABLED(CONFIG_MMU) && arch_phys_to_idmap_offset != 0;
> +}
> +
>  #define IDMAP_INVALID_ADDR ((u32)~0)
>
>  static inline unsigned long phys_to_idmap(phys_addr_t addr)

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 05/12] ARM: kdump: advertise boot aliased crash kernel resource

[Russell King]

Advertise a resource which describes where the crash kernel is located
in the boot view of RAM.  This allows kexec-tools to have this vital
information.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d9317eec1eba..19b25ad61385 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1003,9 +1003,25 @@ static void __init reserve_crashkernel(void)
 		(unsigned long)(crash_base >> 20),
 		(unsigned long)(total_mem >> 20));
 
+	/* The crashk resource must always be located in normal mem */
 	crashk_res.start = crash_base;
 	crashk_res.end = crash_base + crash_size - 1;
 	insert_resource(&iomem_resource, &crashk_res);
+
+	if (arm_has_idmap_alias()) {
+		/*
+		 * If we have a special RAM alias for use at boot, we
+		 * need to advertise to kexec tools where the alias is.
+		 */
+		static struct resource crashk_boot_res = {
+			.name = "Crash kernel (boot alias)",
+			.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+		};
+
+		crashk_boot_res.start = phys_to_idmap(crash_base);
+		crashk_boot_res.end = crashk_boot_res.start + crash_size - 1;
+		insert_resource(&iomem_resource, &crashk_boot_res);
+	}
 }
 #else
 static inline void reserve_crashkernel(void) {}
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 05/12] ARM: kdump: advertise boot aliased crash kernel resource

[Russell King]

Advertise a resource which describes where the crash kernel is located
in the boot view of RAM.  This allows kexec-tools to have this vital
information.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d9317eec1eba..19b25ad61385 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1003,9 +1003,25 @@ static void __init reserve_crashkernel(void)
 		(unsigned long)(crash_base >> 20),
 		(unsigned long)(total_mem >> 20));
 
+	/* The crashk resource must always be located in normal mem */
 	crashk_res.start = crash_base;
 	crashk_res.end = crash_base + crash_size - 1;
 	insert_resource(&iomem_resource, &crashk_res);
+
+	if (arm_has_idmap_alias()) {
+		/*
+		 * If we have a special RAM alias for use at boot, we
+		 * need to advertise to kexec tools where the alias is.
+		 */
+		static struct resource crashk_boot_res = {
+			.name = "Crash kernel (boot alias)",
+			.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+		};
+
+		crashk_boot_res.start = phys_to_idmap(crash_base);
+		crashk_boot_res.end = crashk_boot_res.start + crash_size - 1;
+		insert_resource(&iomem_resource, &crashk_boot_res);
+	}
 }
 #else
 static inline void reserve_crashkernel(void) {}
-- 
2.1.0

[PATCH 05/12] ARM: kdump: advertise boot aliased crash kernel resource

[Russell King]

Advertise a resource which describes where the crash kernel is located
in the boot view of RAM.  This allows kexec-tools to have this vital
information.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d9317eec1eba..19b25ad61385 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1003,9 +1003,25 @@ static void __init reserve_crashkernel(void)
 		(unsigned long)(crash_base >> 20),
 		(unsigned long)(total_mem >> 20));
 
+	/* The crashk resource must always be located in normal mem */
 	crashk_res.start = crash_base;
 	crashk_res.end = crash_base + crash_size - 1;
 	insert_resource(&iomem_resource, &crashk_res);
+
+	if (arm_has_idmap_alias()) {
+		/*
+		 * If we have a special RAM alias for use at boot, we
+		 * need to advertise to kexec tools where the alias is.
+		 */
+		static struct resource crashk_boot_res = {
+			.name = "Crash kernel (boot alias)",
+			.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+		};
+
+		crashk_boot_res.start = phys_to_idmap(crash_base);
+		crashk_boot_res.end = crashk_boot_res.start + crash_size - 1;
+		insert_resource(&iomem_resource, &crashk_boot_res);
+	}
 }
 #else
 static inline void reserve_crashkernel(void) {}
-- 
2.1.0

[PATCH 05/12] ARM: kdump: advertise boot aliased crash kernel resource

[Russell King]

Advertise a resource which describes where the crash kernel is located
in the boot view of RAM.  This allows kexec-tools to have this vital
information.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d9317eec1eba..19b25ad61385 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1003,9 +1003,25 @@ static void __init reserve_crashkernel(void)
 		(unsigned long)(crash_base >> 20),
 		(unsigned long)(total_mem >> 20));
 
+	/* The crashk resource must always be located in normal mem */
 	crashk_res.start = crash_base;
 	crashk_res.end = crash_base + crash_size - 1;
 	insert_resource(&iomem_resource, &crashk_res);
+
+	if (arm_has_idmap_alias()) {
+		/*
+		 * If we have a special RAM alias for use at boot, we
+		 * need to advertise to kexec tools where the alias is.
+		 */
+		static struct resource crashk_boot_res = {
+			.name = "Crash kernel (boot alias)",
+			.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+		};
+
+		crashk_boot_res.start = phys_to_idmap(crash_base);
+		crashk_boot_res.end = crashk_boot_res.start + crash_size - 1;
+		insert_resource(&iomem_resource, &crashk_boot_res);
+	}
 }
 #else
 static inline void reserve_crashkernel(void) {}
-- 
2.1.0

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King]

Advertise the location of bootable RAM to kexec-tools.  kexec needs to
know where it can place the kernel in RAM, and so be executable when
the system needs to jump into it.

Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
tag.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 19b25ad61385..7cf1c0d4f773 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -847,10 +847,29 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 	kernel_data.end     = virt_to_phys(_end - 1);
 
 	for_each_memblock(memory, region) {
+		phys_addr_t start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
+		phys_addr_t end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		unsigned long boot_alias_start;
+
+		/*
+		 * Some systems have a special memory alias which is only
+		 * used for booting.  We need to advertise this region to
+		 * kexec-tools so they know where bootable RAM is located.
+		 */
+		boot_alias_start = phys_to_idmap(start);
+		if (arm_has_idmap_alias() && boot_alias_start != INVALID_IDMAP_ADDR) {
+			res = memblock_virt_alloc(sizeof(*res), 0);
+			res->name = "System RAM (boot alias)";
+			res->start = boot_alias_start;
+			res->end = phys_to_idmap(end);
+			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+			request_resource(&iomem_resource, res);
+		}
+
 		res = memblock_virt_alloc(sizeof(*res), 0);
 		res->name  = "System RAM";
-		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
-		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		res->start = start;
+		res->end = end;
 		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King]

Advertise the location of bootable RAM to kexec-tools.  kexec needs to
know where it can place the kernel in RAM, and so be executable when
the system needs to jump into it.

Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
tag.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 19b25ad61385..7cf1c0d4f773 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -847,10 +847,29 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 	kernel_data.end     = virt_to_phys(_end - 1);
 
 	for_each_memblock(memory, region) {
+		phys_addr_t start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
+		phys_addr_t end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		unsigned long boot_alias_start;
+
+		/*
+		 * Some systems have a special memory alias which is only
+		 * used for booting.  We need to advertise this region to
+		 * kexec-tools so they know where bootable RAM is located.
+		 */
+		boot_alias_start = phys_to_idmap(start);
+		if (arm_has_idmap_alias() && boot_alias_start != INVALID_IDMAP_ADDR) {
+			res = memblock_virt_alloc(sizeof(*res), 0);
+			res->name = "System RAM (boot alias)";
+			res->start = boot_alias_start;
+			res->end = phys_to_idmap(end);
+			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+			request_resource(&iomem_resource, res);
+		}
+
 		res = memblock_virt_alloc(sizeof(*res), 0);
 		res->name  = "System RAM";
-		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
-		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		res->start = start;
+		res->end = end;
 		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
-- 
2.1.0

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King]

Advertise the location of bootable RAM to kexec-tools.  kexec needs to
know where it can place the kernel in RAM, and so be executable when
the system needs to jump into it.

Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
tag.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 19b25ad61385..7cf1c0d4f773 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -847,10 +847,29 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 	kernel_data.end     = virt_to_phys(_end - 1);
 
 	for_each_memblock(memory, region) {
+		phys_addr_t start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
+		phys_addr_t end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		unsigned long boot_alias_start;
+
+		/*
+		 * Some systems have a special memory alias which is only
+		 * used for booting.  We need to advertise this region to
+		 * kexec-tools so they know where bootable RAM is located.
+		 */
+		boot_alias_start = phys_to_idmap(start);
+		if (arm_has_idmap_alias() && boot_alias_start != INVALID_IDMAP_ADDR) {
+			res = memblock_virt_alloc(sizeof(*res), 0);
+			res->name = "System RAM (boot alias)";
+			res->start = boot_alias_start;
+			res->end = phys_to_idmap(end);
+			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+			request_resource(&iomem_resource, res);
+		}
+
 		res = memblock_virt_alloc(sizeof(*res), 0);
 		res->name  = "System RAM";
-		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
-		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		res->start = start;
+		res->end = end;
 		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
-- 
2.1.0

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King]

Advertise the location of bootable RAM to kexec-tools.  kexec needs to
know where it can place the kernel in RAM, and so be executable when
the system needs to jump into it.

Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
tag.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/kernel/setup.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 19b25ad61385..7cf1c0d4f773 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -847,10 +847,29 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 	kernel_data.end     = virt_to_phys(_end - 1);
 
 	for_each_memblock(memory, region) {
+		phys_addr_t start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
+		phys_addr_t end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		unsigned long boot_alias_start;
+
+		/*
+		 * Some systems have a special memory alias which is only
+		 * used for booting.  We need to advertise this region to
+		 * kexec-tools so they know where bootable RAM is located.
+		 */
+		boot_alias_start = phys_to_idmap(start);
+		if (arm_has_idmap_alias() && boot_alias_start != INVALID_IDMAP_ADDR) {
+			res = memblock_virt_alloc(sizeof(*res), 0);
+			res->name = "System RAM (boot alias)";
+			res->start = boot_alias_start;
+			res->end = phys_to_idmap(end);
+			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+			request_resource(&iomem_resource, res);
+		}
+
 		res = memblock_virt_alloc(sizeof(*res), 0);
 		res->name  = "System RAM";
-		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
-		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
+		res->start = start;
+		res->end = end;
 		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
-- 
2.1.0

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> know where it can place the kernel in RAM, and so be executable when
> the system needs to jump into it.
>
> Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> tag.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Can you please also share git tree path of corresponding kexec-tools changes?

Could it be a better idea (if things in user space become simpler)
that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
user space, and then user space manipulates existing "Crash kernel"
and "System RAM" resources.

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> know where it can place the kernel in RAM, and so be executable when
> the system needs to jump into it.
>
> Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> tag.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Can you please also share git tree path of corresponding kexec-tools changes?

Could it be a better idea (if things in user space become simpler)
that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
user space, and then user space manipulates existing "Crash kernel"
and "System RAM" resources.

~Pratyush

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> know where it can place the kernel in RAM, and so be executable when
> the system needs to jump into it.
>
> Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> tag.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Can you please also share git tree path of corresponding kexec-tools changes?

Could it be a better idea (if things in user space become simpler)
that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
user space, and then user space manipulates existing "Crash kernel"
and "System RAM" resources.

~Pratyush

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

Hi Russell,

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> know where it can place the kernel in RAM, and so be executable when
> the system needs to jump into it.
>
> Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> tag.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Can you please also share git tree path of corresponding kexec-tools changes?

Could it be a better idea (if things in user space become simpler)
that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
user space, and then user space manipulates existing "Crash kernel"
and "System RAM" resources.

~Pratyush

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Hi Russell,
> 
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> > know where it can place the kernel in RAM, and so be executable when
> > the system needs to jump into it.
> >
> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> > tag.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Can you please also share git tree path of corresponding kexec-tools changes?
> 
> Could it be a better idea (if things in user space become simpler)
> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> user space, and then user space manipulates existing "Crash kernel"
> and "System RAM" resources.

Given that it's only _one_ platform right now, I don't think that
additional complexity is worth it.  It means that we have to invent
some API to do it, and I don't see why userspace should even care
about having the delta exported - especially when the conversion
may not be as trivial.

The method I've implemented here keeps things completely independent
of whatever conversion between boot and running physical addresses
may be present on the kernel side as far as userspace is concerned.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Hi Russell,
> 
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> > know where it can place the kernel in RAM, and so be executable when
> > the system needs to jump into it.
> >
> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> > tag.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Can you please also share git tree path of corresponding kexec-tools changes?
> 
> Could it be a better idea (if things in user space become simpler)
> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> user space, and then user space manipulates existing "Crash kernel"
> and "System RAM" resources.

Given that it's only _one_ platform right now, I don't think that
additional complexity is worth it.  It means that we have to invent
some API to do it, and I don't see why userspace should even care
about having the delta exported - especially when the conversion
may not be as trivial.

The method I've implemented here keeps things completely independent
of whatever conversion between boot and running physical addresses
may be present on the kernel side as far as userspace is concerned.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Hi Russell,
> 
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> > know where it can place the kernel in RAM, and so be executable when
> > the system needs to jump into it.
> >
> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> > tag.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Can you please also share git tree path of corresponding kexec-tools changes?
> 
> Could it be a better idea (if things in user space become simpler)
> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> user space, and then user space manipulates existing "Crash kernel"
> and "System RAM" resources.

Given that it's only _one_ platform right now, I don't think that
additional complexity is worth it.  It means that we have to invent
some API to do it, and I don't see why userspace should even care
about having the delta exported - especially when the conversion
may not be as trivial.

The method I've implemented here keeps things completely independent
of whatever conversion between boot and running physical addresses
may be present on the kernel side as far as userspace is concerned.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Hi Russell,
> 
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> > know where it can place the kernel in RAM, and so be executable when
> > the system needs to jump into it.
> >
> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> > tag.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Can you please also share git tree path of corresponding kexec-tools changes?
> 
> Could it be a better idea (if things in user space become simpler)
> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> user space, and then user space manipulates existing "Crash kernel"
> and "System RAM" resources.

Given that it's only _one_ platform right now, I don't think that
additional complexity is worth it.  It means that we have to invent
some API to do it, and I don't see why userspace should even care
about having the delta exported - especially when the conversion
may not be as trivial.

The method I've implemented here keeps things completely independent
of whatever conversion between boot and running physical addresses
may be present on the kernel side as far as userspace is concerned.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> Hi Russell,
>>
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> > know where it can place the kernel in RAM, and so be executable when
>> > the system needs to jump into it.
>> >
>> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> > tag.
>> >
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> Can you please also share git tree path of corresponding kexec-tools changes?
>>
>> Could it be a better idea (if things in user space become simpler)
>> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> user space, and then user space manipulates existing "Crash kernel"
>> and "System RAM" resources.
>
> Given that it's only _one_ platform right now, I don't think that
> additional complexity is worth it.  It means that we have to invent

Probably, I could not communicate it well.  I was not trying  to have
*additional* complexity. Wanted to see if things could be simpler
rather. So this is what my understanding was:
-- We create one patch to pass arch_phys_to_idmap_offset to user space
(say in /sys/kernel/bootmem_idmap_offset)
-- We do not use patch 5,6,11 and 12 of this series. Probably few more
content of the series will go away.
--  In kexec-tools code , we read /sys/kernel/bootmem_idmap_offset and
add that value in "start" and "end" of "Crash Kernel" and "System RAM"
resources.

> some API to do it, and I don't see why userspace should even care
> about having the delta exported - especially when the conversion
> may not be as trivial.
>

Yes, I agree, if translation is not trivial like that of keystone,
then what I am proposing will not work.

Reviewed-by: Pratyush Anand <panand@redhat.com>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> Hi Russell,
>>
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> > know where it can place the kernel in RAM, and so be executable when
>> > the system needs to jump into it.
>> >
>> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> > tag.
>> >
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> Can you please also share git tree path of corresponding kexec-tools changes?
>>
>> Could it be a better idea (if things in user space become simpler)
>> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> user space, and then user space manipulates existing "Crash kernel"
>> and "System RAM" resources.
>
> Given that it's only _one_ platform right now, I don't think that
> additional complexity is worth it.  It means that we have to invent

Probably, I could not communicate it well.  I was not trying  to have
*additional* complexity. Wanted to see if things could be simpler
rather. So this is what my understanding was:
-- We create one patch to pass arch_phys_to_idmap_offset to user space
(say in /sys/kernel/bootmem_idmap_offset)
-- We do not use patch 5,6,11 and 12 of this series. Probably few more
content of the series will go away.
--  In kexec-tools code , we read /sys/kernel/bootmem_idmap_offset and
add that value in "start" and "end" of "Crash Kernel" and "System RAM"
resources.

> some API to do it, and I don't see why userspace should even care
> about having the delta exported - especially when the conversion
> may not be as trivial.
>

Yes, I agree, if translation is not trivial like that of keystone,
then what I am proposing will not work.

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> Hi Russell,
>>
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> > know where it can place the kernel in RAM, and so be executable when
>> > the system needs to jump into it.
>> >
>> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> > tag.
>> >
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> Can you please also share git tree path of corresponding kexec-tools changes?
>>
>> Could it be a better idea (if things in user space become simpler)
>> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> user space, and then user space manipulates existing "Crash kernel"
>> and "System RAM" resources.
>
> Given that it's only _one_ platform right now, I don't think that
> additional complexity is worth it.  It means that we have to invent

Probably, I could not communicate it well.  I was not trying  to have
*additional* complexity. Wanted to see if things could be simpler
rather. So this is what my understanding was:
-- We create one patch to pass arch_phys_to_idmap_offset to user space
(say in /sys/kernel/bootmem_idmap_offset)
-- We do not use patch 5,6,11 and 12 of this series. Probably few more
content of the series will go away.
--  In kexec-tools code , we read /sys/kernel/bootmem_idmap_offset and
add that value in "start" and "end" of "Crash Kernel" and "System RAM"
resources.

> some API to do it, and I don't see why userspace should even care
> about having the delta exported - especially when the conversion
> may not be as trivial.
>

Yes, I agree, if translation is not trivial like that of keystone,
then what I am proposing will not work.

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> Hi Russell,
>>
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> > know where it can place the kernel in RAM, and so be executable when
>> > the system needs to jump into it.
>> >
>> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> > tag.
>> >
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>>
>> Can you please also share git tree path of corresponding kexec-tools changes?
>>
>> Could it be a better idea (if things in user space become simpler)
>> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> user space, and then user space manipulates existing "Crash kernel"
>> and "System RAM" resources.
>
> Given that it's only _one_ platform right now, I don't think that
> additional complexity is worth it.  It means that we have to invent

Probably, I could not communicate it well.  I was not trying  to have
*additional* complexity. Wanted to see if things could be simpler
rather. So this is what my understanding was:
-- We create one patch to pass arch_phys_to_idmap_offset to user space
(say in /sys/kernel/bootmem_idmap_offset)
-- We do not use patch 5,6,11 and 12 of this series. Probably few more
content of the series will go away.
--  In kexec-tools code , we read /sys/kernel/bootmem_idmap_offset and
add that value in "start" and "end" of "Crash Kernel" and "System RAM"
resources.

> some API to do it, and I don't see why userspace should even care
> about having the delta exported - especially when the conversion
> may not be as trivial.
>

Yes, I agree, if translation is not trivial like that of keystone,
then what I am proposing will not work.

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> Hi Russell,
> >>
> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> > know where it can place the kernel in RAM, and so be executable when
> >> > the system needs to jump into it.
> >> >
> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> > tag.
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >>
> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >>
> >> Could it be a better idea (if things in user space become simpler)
> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> user space, and then user space manipulates existing "Crash kernel"
> >> and "System RAM" resources.
> >
> > Given that it's only _one_ platform right now, I don't think that
> > additional complexity is worth it.  It means that we have to invent
> 
> Probably, I could not communicate it well.  I was not trying  to have
> *additional* complexity. Wanted to see if things could be simpler
> rather. So this is what my understanding was:
> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> (say in /sys/kernel/bootmem_idmap_offset)
> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> content of the series will go away.

Patches 11 and 12 don't go away with what you're suggesting.  Patches
11 and 12 are necessary to allow the boot-view addresses to be passed
into the kernel through kexec, and to allow kexec to find appropriate
memory resources.

For example, from patch 11:

@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned
long entry,

-               if ((entry < crashk_res.start) || (entry > crashk_res.end))
+               if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+                   (entry > phys_to_boot_phys(crashk_res.end)))

"entry" is limited to a 32-bit physical address as it is unsigned long,
and is the boot-view physical address.  crashk_res.start is the
running-view physical address.  Without this change, the rest will
always be true on Keystone 2.

@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
-                       if ((mstart < crashk_res.start) ||
-                           (mend > crashk_res.end))
+                       if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+                           (mend > phys_to_boot_phys(crashk_res.end)))

Same problem - mstart and mend are both 32-bit quantities.  The result
is the segment list validation always fails.

@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
-               pfn   = page_to_pfn(pages);
+               pfn   = page_to_boot_pfn(pages);

The result without this change is that we allocate _all_ system memory
looking for a suitable page, never finding one because we never find
a page which matches.  Without a previous patch, killing many
processes and taking the system down.

@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
-               *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+               *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;

The physical address would end up being truncated to 32-bits, but
would actually be larger than 4GiB.  So, *image->entry would point
at the incorrect address, and kexec would fail.

@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
        for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
                ptr = (entry & IND_INDIRECTION) ? \
-                       phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+                       boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)

"entry" is truncated to 32-bit, and so this passes an invalid
physical address which is not part of the lowmem mapping to
phys_to_virt().  The resulting virtual address is undefined.

-       page = pfn_to_page(entry >> PAGE_SHIFT);
+       page = boot_pfn_to_page(entry >> PAGE_SHIFT);

Same, except the resulting struct page pointer is undefined.

... and so it goes on.

The only patches which get replaced are patches 5 and 6 with a new
userspace API.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> Hi Russell,
> >>
> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> > know where it can place the kernel in RAM, and so be executable when
> >> > the system needs to jump into it.
> >> >
> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> > tag.
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >>
> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >>
> >> Could it be a better idea (if things in user space become simpler)
> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> user space, and then user space manipulates existing "Crash kernel"
> >> and "System RAM" resources.
> >
> > Given that it's only _one_ platform right now, I don't think that
> > additional complexity is worth it.  It means that we have to invent
> 
> Probably, I could not communicate it well.  I was not trying  to have
> *additional* complexity. Wanted to see if things could be simpler
> rather. So this is what my understanding was:
> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> (say in /sys/kernel/bootmem_idmap_offset)
> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> content of the series will go away.

Patches 11 and 12 don't go away with what you're suggesting.  Patches
11 and 12 are necessary to allow the boot-view addresses to be passed
into the kernel through kexec, and to allow kexec to find appropriate
memory resources.

For example, from patch 11:

@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned
long entry,

-               if ((entry < crashk_res.start) || (entry > crashk_res.end))
+               if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+                   (entry > phys_to_boot_phys(crashk_res.end)))

"entry" is limited to a 32-bit physical address as it is unsigned long,
and is the boot-view physical address.  crashk_res.start is the
running-view physical address.  Without this change, the rest will
always be true on Keystone 2.

@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
-                       if ((mstart < crashk_res.start) ||
-                           (mend > crashk_res.end))
+                       if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+                           (mend > phys_to_boot_phys(crashk_res.end)))

Same problem - mstart and mend are both 32-bit quantities.  The result
is the segment list validation always fails.

@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
-               pfn   = page_to_pfn(pages);
+               pfn   = page_to_boot_pfn(pages);

The result without this change is that we allocate _all_ system memory
looking for a suitable page, never finding one because we never find
a page which matches.  Without a previous patch, killing many
processes and taking the system down.

@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
-               *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+               *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;

The physical address would end up being truncated to 32-bits, but
would actually be larger than 4GiB.  So, *image->entry would point
at the incorrect address, and kexec would fail.

@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
        for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
                ptr = (entry & IND_INDIRECTION) ? \
-                       phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+                       boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)

"entry" is truncated to 32-bit, and so this passes an invalid
physical address which is not part of the lowmem mapping to
phys_to_virt().  The resulting virtual address is undefined.

-       page = pfn_to_page(entry >> PAGE_SHIFT);
+       page = boot_pfn_to_page(entry >> PAGE_SHIFT);

Same, except the resulting struct page pointer is undefined.

... and so it goes on.

The only patches which get replaced are patches 5 and 6 with a new
userspace API.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> Hi Russell,
> >>
> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> > know where it can place the kernel in RAM, and so be executable when
> >> > the system needs to jump into it.
> >> >
> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> > tag.
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >>
> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >>
> >> Could it be a better idea (if things in user space become simpler)
> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> user space, and then user space manipulates existing "Crash kernel"
> >> and "System RAM" resources.
> >
> > Given that it's only _one_ platform right now, I don't think that
> > additional complexity is worth it.  It means that we have to invent
> 
> Probably, I could not communicate it well.  I was not trying  to have
> *additional* complexity. Wanted to see if things could be simpler
> rather. So this is what my understanding was:
> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> (say in /sys/kernel/bootmem_idmap_offset)
> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> content of the series will go away.

Patches 11 and 12 don't go away with what you're suggesting.  Patches
11 and 12 are necessary to allow the boot-view addresses to be passed
into the kernel through kexec, and to allow kexec to find appropriate
memory resources.

For example, from patch 11:

@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned
long entry,

-               if ((entry < crashk_res.start) || (entry > crashk_res.end))
+               if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+                   (entry > phys_to_boot_phys(crashk_res.end)))

"entry" is limited to a 32-bit physical address as it is unsigned long,
and is the boot-view physical address.  crashk_res.start is the
running-view physical address.  Without this change, the rest will
always be true on Keystone 2.

@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
-                       if ((mstart < crashk_res.start) ||
-                           (mend > crashk_res.end))
+                       if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+                           (mend > phys_to_boot_phys(crashk_res.end)))

Same problem - mstart and mend are both 32-bit quantities.  The result
is the segment list validation always fails.

@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
-               pfn   = page_to_pfn(pages);
+               pfn   = page_to_boot_pfn(pages);

The result without this change is that we allocate _all_ system memory
looking for a suitable page, never finding one because we never find
a page which matches.  Without a previous patch, killing many
processes and taking the system down.

@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
-               *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+               *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;

The physical address would end up being truncated to 32-bits, but
would actually be larger than 4GiB.  So, *image->entry would point
at the incorrect address, and kexec would fail.

@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
        for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
                ptr = (entry & IND_INDIRECTION) ? \
-                       phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+                       boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)

"entry" is truncated to 32-bit, and so this passes an invalid
physical address which is not part of the lowmem mapping to
phys_to_virt().  The resulting virtual address is undefined.

-       page = pfn_to_page(entry >> PAGE_SHIFT);
+       page = boot_pfn_to_page(entry >> PAGE_SHIFT);

Same, except the resulting struct page pointer is undefined.

... and so it goes on.

The only patches which get replaced are patches 5 and 6 with a new
userspace API.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> Hi Russell,
> >>
> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> > know where it can place the kernel in RAM, and so be executable when
> >> > the system needs to jump into it.
> >> >
> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> > tag.
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >>
> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >>
> >> Could it be a better idea (if things in user space become simpler)
> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> user space, and then user space manipulates existing "Crash kernel"
> >> and "System RAM" resources.
> >
> > Given that it's only _one_ platform right now, I don't think that
> > additional complexity is worth it.  It means that we have to invent
> 
> Probably, I could not communicate it well.  I was not trying  to have
> *additional* complexity. Wanted to see if things could be simpler
> rather. So this is what my understanding was:
> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> (say in /sys/kernel/bootmem_idmap_offset)
> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> content of the series will go away.

Patches 11 and 12 don't go away with what you're suggesting.  Patches
11 and 12 are necessary to allow the boot-view addresses to be passed
into the kernel through kexec, and to allow kexec to find appropriate
memory resources.

For example, from patch 11:

@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned
long entry,

-               if ((entry < crashk_res.start) || (entry > crashk_res.end))
+               if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+                   (entry > phys_to_boot_phys(crashk_res.end)))

"entry" is limited to a 32-bit physical address as it is unsigned long,
and is the boot-view physical address.  crashk_res.start is the
running-view physical address.  Without this change, the rest will
always be true on Keystone 2.

@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
-                       if ((mstart < crashk_res.start) ||
-                           (mend > crashk_res.end))
+                       if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+                           (mend > phys_to_boot_phys(crashk_res.end)))

Same problem - mstart and mend are both 32-bit quantities.  The result
is the segment list validation always fails.

@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
-               pfn   = page_to_pfn(pages);
+               pfn   = page_to_boot_pfn(pages);

The result without this change is that we allocate _all_ system memory
looking for a suitable page, never finding one because we never find
a page which matches.  Without a previous patch, killing many
processes and taking the system down.

@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
-               *image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+               *image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;

The physical address would end up being truncated to 32-bits, but
would actually be larger than 4GiB.  So, *image->entry would point
at the incorrect address, and kexec would fail.

@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
        for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
                ptr = (entry & IND_INDIRECTION) ? \
-                       phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+                       boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)

"entry" is truncated to 32-bit, and so this passes an invalid
physical address which is not part of the lowmem mapping to
phys_to_virt().  The resulting virtual address is undefined.

-       page = pfn_to_page(entry >> PAGE_SHIFT);
+       page = boot_pfn_to_page(entry >> PAGE_SHIFT);

Same, except the resulting struct page pointer is undefined.

... and so it goes on.

The only patches which get replaced are patches 5 and 6 with a new
userspace API.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> Hi Russell,
>> >>
>> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> > know where it can place the kernel in RAM, and so be executable when
>> >> > the system needs to jump into it.
>> >> >
>> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> > tag.
>> >> >
>> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >>
>> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >>
>> >> Could it be a better idea (if things in user space become simpler)
>> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> user space, and then user space manipulates existing "Crash kernel"
>> >> and "System RAM" resources.
>> >
>> > Given that it's only _one_ platform right now, I don't think that
>> > additional complexity is worth it.  It means that we have to invent
>>
>> Probably, I could not communicate it well.  I was not trying  to have
>> *additional* complexity. Wanted to see if things could be simpler
>> rather. So this is what my understanding was:
>> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> (say in /sys/kernel/bootmem_idmap_offset)
>> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> content of the series will go away.
>
> Patches 11 and 12 don't go away with what you're suggesting.  Patches
> 11 and 12 are necessary to allow the boot-view addresses to be passed
> into the kernel through kexec, and to allow kexec to find appropriate
> memory resources.

But once we would have manipulated "start" and "end" of "Crash Kernel"
and "System RAM" resources in user space using
/sys/kernel/bootmem_idmap_offset , then kernel through kexec system
call would have already receive boot-view addresses, no?

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> Hi Russell,
>> >>
>> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> > know where it can place the kernel in RAM, and so be executable when
>> >> > the system needs to jump into it.
>> >> >
>> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> > tag.
>> >> >
>> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >>
>> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >>
>> >> Could it be a better idea (if things in user space become simpler)
>> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> user space, and then user space manipulates existing "Crash kernel"
>> >> and "System RAM" resources.
>> >
>> > Given that it's only _one_ platform right now, I don't think that
>> > additional complexity is worth it.  It means that we have to invent
>>
>> Probably, I could not communicate it well.  I was not trying  to have
>> *additional* complexity. Wanted to see if things could be simpler
>> rather. So this is what my understanding was:
>> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> (say in /sys/kernel/bootmem_idmap_offset)
>> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> content of the series will go away.
>
> Patches 11 and 12 don't go away with what you're suggesting.  Patches
> 11 and 12 are necessary to allow the boot-view addresses to be passed
> into the kernel through kexec, and to allow kexec to find appropriate
> memory resources.

But once we would have manipulated "start" and "end" of "Crash Kernel"
and "System RAM" resources in user space using
/sys/kernel/bootmem_idmap_offset , then kernel through kexec system
call would have already receive boot-view addresses, no?

~Pratyush

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> Hi Russell,
>> >>
>> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> > know where it can place the kernel in RAM, and so be executable when
>> >> > the system needs to jump into it.
>> >> >
>> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> > tag.
>> >> >
>> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >>
>> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >>
>> >> Could it be a better idea (if things in user space become simpler)
>> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> user space, and then user space manipulates existing "Crash kernel"
>> >> and "System RAM" resources.
>> >
>> > Given that it's only _one_ platform right now, I don't think that
>> > additional complexity is worth it.  It means that we have to invent
>>
>> Probably, I could not communicate it well.  I was not trying  to have
>> *additional* complexity. Wanted to see if things could be simpler
>> rather. So this is what my understanding was:
>> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> (say in /sys/kernel/bootmem_idmap_offset)
>> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> content of the series will go away.
>
> Patches 11 and 12 don't go away with what you're suggesting.  Patches
> 11 and 12 are necessary to allow the boot-view addresses to be passed
> into the kernel through kexec, and to allow kexec to find appropriate
> memory resources.

But once we would have manipulated "start" and "end" of "Crash Kernel"
and "System RAM" resources in user space using
/sys/kernel/bootmem_idmap_offset , then kernel through kexec system
call would have already receive boot-view addresses, no?

~Pratyush

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> Hi Russell,
>> >>
>> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> > know where it can place the kernel in RAM, and so be executable when
>> >> > the system needs to jump into it.
>> >> >
>> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> > tag.
>> >> >
>> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >>
>> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >>
>> >> Could it be a better idea (if things in user space become simpler)
>> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> user space, and then user space manipulates existing "Crash kernel"
>> >> and "System RAM" resources.
>> >
>> > Given that it's only _one_ platform right now, I don't think that
>> > additional complexity is worth it.  It means that we have to invent
>>
>> Probably, I could not communicate it well.  I was not trying  to have
>> *additional* complexity. Wanted to see if things could be simpler
>> rather. So this is what my understanding was:
>> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> (say in /sys/kernel/bootmem_idmap_offset)
>> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> content of the series will go away.
>
> Patches 11 and 12 don't go away with what you're suggesting.  Patches
> 11 and 12 are necessary to allow the boot-view addresses to be passed
> into the kernel through kexec, and to allow kexec to find appropriate
> memory resources.

But once we would have manipulated "start" and "end" of "Crash Kernel"
and "System RAM" resources in user space using
/sys/kernel/bootmem_idmap_offset , then kernel through kexec system
call would have already receive boot-view addresses, no?

~Pratyush

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> >> Hi Russell,
> >> >>
> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> >> > know where it can place the kernel in RAM, and so be executable when
> >> >> > the system needs to jump into it.
> >> >> >
> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> >> > tag.
> >> >> >
> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> >>
> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >> >>
> >> >> Could it be a better idea (if things in user space become simpler)
> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> >> user space, and then user space manipulates existing "Crash kernel"
> >> >> and "System RAM" resources.
> >> >
> >> > Given that it's only _one_ platform right now, I don't think that
> >> > additional complexity is worth it.  It means that we have to invent
> >>
> >> Probably, I could not communicate it well.  I was not trying  to have
> >> *additional* complexity. Wanted to see if things could be simpler
> >> rather. So this is what my understanding was:
> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> >> (say in /sys/kernel/bootmem_idmap_offset)
> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> >> content of the series will go away.
> >
> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
> > 11 and 12 are necessary to allow the boot-view addresses to be passed
> > into the kernel through kexec, and to allow kexec to find appropriate
> > memory resources.
> 
> But once we would have manipulated "start" and "end" of "Crash Kernel"
> and "System RAM" resources in user space using
> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
> call would have already receive boot-view addresses, no?

Correct, but that's still a problem for all the reasons I gave in the
email to which you replied to.

I'm not sure where the misunderstanding is.

Let me repeat: even if we do what you're suggesting, patches 11 and 12
do *not* go away.  I've explained in detail why each of the changes are
necessary (which you have cut from your reply.)

In other words: exporting this offset via
/sys/kernel/bootmem_idmap_offset is technically inferior to the solution
I have come up with here, and it saves very little complexity and code.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> >> Hi Russell,
> >> >>
> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> >> > know where it can place the kernel in RAM, and so be executable when
> >> >> > the system needs to jump into it.
> >> >> >
> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> >> > tag.
> >> >> >
> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> >>
> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >> >>
> >> >> Could it be a better idea (if things in user space become simpler)
> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> >> user space, and then user space manipulates existing "Crash kernel"
> >> >> and "System RAM" resources.
> >> >
> >> > Given that it's only _one_ platform right now, I don't think that
> >> > additional complexity is worth it.  It means that we have to invent
> >>
> >> Probably, I could not communicate it well.  I was not trying  to have
> >> *additional* complexity. Wanted to see if things could be simpler
> >> rather. So this is what my understanding was:
> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> >> (say in /sys/kernel/bootmem_idmap_offset)
> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> >> content of the series will go away.
> >
> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
> > 11 and 12 are necessary to allow the boot-view addresses to be passed
> > into the kernel through kexec, and to allow kexec to find appropriate
> > memory resources.
> 
> But once we would have manipulated "start" and "end" of "Crash Kernel"
> and "System RAM" resources in user space using
> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
> call would have already receive boot-view addresses, no?

Correct, but that's still a problem for all the reasons I gave in the
email to which you replied to.

I'm not sure where the misunderstanding is.

Let me repeat: even if we do what you're suggesting, patches 11 and 12
do *not* go away.  I've explained in detail why each of the changes are
necessary (which you have cut from your reply.)

In other words: exporting this offset via
/sys/kernel/bootmem_idmap_offset is technically inferior to the solution
I have come up with here, and it saves very little complexity and code.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> >> Hi Russell,
> >> >>
> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> >> > know where it can place the kernel in RAM, and so be executable when
> >> >> > the system needs to jump into it.
> >> >> >
> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> >> > tag.
> >> >> >
> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> >>
> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >> >>
> >> >> Could it be a better idea (if things in user space become simpler)
> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> >> user space, and then user space manipulates existing "Crash kernel"
> >> >> and "System RAM" resources.
> >> >
> >> > Given that it's only _one_ platform right now, I don't think that
> >> > additional complexity is worth it.  It means that we have to invent
> >>
> >> Probably, I could not communicate it well.  I was not trying  to have
> >> *additional* complexity. Wanted to see if things could be simpler
> >> rather. So this is what my understanding was:
> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> >> (say in /sys/kernel/bootmem_idmap_offset)
> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> >> content of the series will go away.
> >
> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
> > 11 and 12 are necessary to allow the boot-view addresses to be passed
> > into the kernel through kexec, and to allow kexec to find appropriate
> > memory resources.
> 
> But once we would have manipulated "start" and "end" of "Crash Kernel"
> and "System RAM" resources in user space using
> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
> call would have already receive boot-view addresses, no?

Correct, but that's still a problem for all the reasons I gave in the
email to which you replied to.

I'm not sure where the misunderstanding is.

Let me repeat: even if we do what you're suggesting, patches 11 and 12
do *not* go away.  I've explained in detail why each of the changes are
necessary (which you have cut from your reply.)

In other words: exporting this offset via
/sys/kernel/bootmem_idmap_offset is technically inferior to the solution
I have come up with here, and it saves very little complexity and code.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> >> Hi Russell,
> >> >>
> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> >> > know where it can place the kernel in RAM, and so be executable when
> >> >> > the system needs to jump into it.
> >> >> >
> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> >> > tag.
> >> >> >
> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >> >>
> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
> >> >>
> >> >> Could it be a better idea (if things in user space become simpler)
> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> >> user space, and then user space manipulates existing "Crash kernel"
> >> >> and "System RAM" resources.
> >> >
> >> > Given that it's only _one_ platform right now, I don't think that
> >> > additional complexity is worth it.  It means that we have to invent
> >>
> >> Probably, I could not communicate it well.  I was not trying  to have
> >> *additional* complexity. Wanted to see if things could be simpler
> >> rather. So this is what my understanding was:
> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> >> (say in /sys/kernel/bootmem_idmap_offset)
> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> >> content of the series will go away.
> >
> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
> > 11 and 12 are necessary to allow the boot-view addresses to be passed
> > into the kernel through kexec, and to allow kexec to find appropriate
> > memory resources.
> 
> But once we would have manipulated "start" and "end" of "Crash Kernel"
> and "System RAM" resources in user space using
> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
> call would have already receive boot-view addresses, no?

Correct, but that's still a problem for all the reasons I gave in the
email to which you replied to.

I'm not sure where the misunderstanding is.

Let me repeat: even if we do what you're suggesting, patches 11 and 12
do *not* go away.  I've explained in detail why each of the changes are
necessary (which you have cut from your reply.)

In other words: exporting this offset via
/sys/kernel/bootmem_idmap_offset is technically inferior to the solution
I have come up with here, and it saves very little complexity and code.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Mon, May 2, 2016 at 3:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
>> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> >> Hi Russell,
>> >> >>
>> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> >> > know where it can place the kernel in RAM, and so be executable when
>> >> >> > the system needs to jump into it.
>> >> >> >
>> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> >> > tag.
>> >> >> >
>> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >> >>
>> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >> >>
>> >> >> Could it be a better idea (if things in user space become simpler)
>> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> >> user space, and then user space manipulates existing "Crash kernel"
>> >> >> and "System RAM" resources.
>> >> >
>> >> > Given that it's only _one_ platform right now, I don't think that
>> >> > additional complexity is worth it.  It means that we have to invent
>> >>
>> >> Probably, I could not communicate it well.  I was not trying  to have
>> >> *additional* complexity. Wanted to see if things could be simpler
>> >> rather. So this is what my understanding was:
>> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> >> (say in /sys/kernel/bootmem_idmap_offset)
>> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> >> content of the series will go away.
>> >
>> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
>> > 11 and 12 are necessary to allow the boot-view addresses to be passed
>> > into the kernel through kexec, and to allow kexec to find appropriate
>> > memory resources.
>>
>> But once we would have manipulated "start" and "end" of "Crash Kernel"
>> and "System RAM" resources in user space using
>> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
>> call would have already receive boot-view addresses, no?
>
> Correct, but that's still a problem for all the reasons I gave in the
> email to which you replied to.
>
> I'm not sure where the misunderstanding is.

No, no..there is no misunderstanding. I agreed to your implementation
because that will work for generic cases and for me complete series is
OK.

I just wanted to clarify my understanding, and so was the last argument.

>
> Let me repeat: even if we do what you're suggesting, patches 11 and 12
> do *not* go away.  I've explained in detail why each of the changes are
> necessary (which you have cut from your reply.)
>

Again, it is just for clarifying myself.
I cut the reply because I understood that in patch 11 and 12, you
convert addresses passed by kexec tools from run time view to boot
view using different helpers like phys_to_boot_phys(). So, had kexec
system call passed boot view addresses, we would have not needed 11
and 12. This is what I wanted to clarify.

> In other words: exporting this offset via
> /sys/kernel/bootmem_idmap_offset is technically inferior to the solution
> I have come up with here, and it saves very little complexity and code.

I still have opinion that code will probably be more simple and reduce
significantly, however solution will siege to work the moment
idmap_offset is not a simple additive value.

Therefore, I am OK with your implementation.

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Mon, May 2, 2016 at 3:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
>> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> >> Hi Russell,
>> >> >>
>> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> >> > know where it can place the kernel in RAM, and so be executable when
>> >> >> > the system needs to jump into it.
>> >> >> >
>> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> >> > tag.
>> >> >> >
>> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >> >>
>> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >> >>
>> >> >> Could it be a better idea (if things in user space become simpler)
>> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> >> user space, and then user space manipulates existing "Crash kernel"
>> >> >> and "System RAM" resources.
>> >> >
>> >> > Given that it's only _one_ platform right now, I don't think that
>> >> > additional complexity is worth it.  It means that we have to invent
>> >>
>> >> Probably, I could not communicate it well.  I was not trying  to have
>> >> *additional* complexity. Wanted to see if things could be simpler
>> >> rather. So this is what my understanding was:
>> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> >> (say in /sys/kernel/bootmem_idmap_offset)
>> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> >> content of the series will go away.
>> >
>> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
>> > 11 and 12 are necessary to allow the boot-view addresses to be passed
>> > into the kernel through kexec, and to allow kexec to find appropriate
>> > memory resources.
>>
>> But once we would have manipulated "start" and "end" of "Crash Kernel"
>> and "System RAM" resources in user space using
>> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
>> call would have already receive boot-view addresses, no?
>
> Correct, but that's still a problem for all the reasons I gave in the
> email to which you replied to.
>
> I'm not sure where the misunderstanding is.

No, no..there is no misunderstanding. I agreed to your implementation
because that will work for generic cases and for me complete series is
OK.

I just wanted to clarify my understanding, and so was the last argument.

>
> Let me repeat: even if we do what you're suggesting, patches 11 and 12
> do *not* go away.  I've explained in detail why each of the changes are
> necessary (which you have cut from your reply.)
>

Again, it is just for clarifying myself.
I cut the reply because I understood that in patch 11 and 12, you
convert addresses passed by kexec tools from run time view to boot
view using different helpers like phys_to_boot_phys(). So, had kexec
system call passed boot view addresses, we would have not needed 11
and 12. This is what I wanted to clarify.

> In other words: exporting this offset via
> /sys/kernel/bootmem_idmap_offset is technically inferior to the solution
> I have come up with here, and it saves very little complexity and code.

I still have opinion that code will probably be more simple and reduce
significantly, however solution will siege to work the moment
idmap_offset is not a simple additive value.

Therefore, I am OK with your implementation.

~Pratyush

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Mon, May 2, 2016 at 3:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
>> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> >> Hi Russell,
>> >> >>
>> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> >> > know where it can place the kernel in RAM, and so be executable when
>> >> >> > the system needs to jump into it.
>> >> >> >
>> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> >> > tag.
>> >> >> >
>> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >> >>
>> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >> >>
>> >> >> Could it be a better idea (if things in user space become simpler)
>> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> >> user space, and then user space manipulates existing "Crash kernel"
>> >> >> and "System RAM" resources.
>> >> >
>> >> > Given that it's only _one_ platform right now, I don't think that
>> >> > additional complexity is worth it.  It means that we have to invent
>> >>
>> >> Probably, I could not communicate it well.  I was not trying  to have
>> >> *additional* complexity. Wanted to see if things could be simpler
>> >> rather. So this is what my understanding was:
>> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> >> (say in /sys/kernel/bootmem_idmap_offset)
>> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> >> content of the series will go away.
>> >
>> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
>> > 11 and 12 are necessary to allow the boot-view addresses to be passed
>> > into the kernel through kexec, and to allow kexec to find appropriate
>> > memory resources.
>>
>> But once we would have manipulated "start" and "end" of "Crash Kernel"
>> and "System RAM" resources in user space using
>> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
>> call would have already receive boot-view addresses, no?
>
> Correct, but that's still a problem for all the reasons I gave in the
> email to which you replied to.
>
> I'm not sure where the misunderstanding is.

No, no..there is no misunderstanding. I agreed to your implementation
because that will work for generic cases and for me complete series is
OK.

I just wanted to clarify my understanding, and so was the last argument.

>
> Let me repeat: even if we do what you're suggesting, patches 11 and 12
> do *not* go away.  I've explained in detail why each of the changes are
> necessary (which you have cut from your reply.)
>

Again, it is just for clarifying myself.
I cut the reply because I understood that in patch 11 and 12, you
convert addresses passed by kexec tools from run time view to boot
view using different helpers like phys_to_boot_phys(). So, had kexec
system call passed boot view addresses, we would have not needed 11
and 12. This is what I wanted to clarify.

> In other words: exporting this offset via
> /sys/kernel/bootmem_idmap_offset is technically inferior to the solution
> I have come up with here, and it saves very little complexity and code.

I still have opinion that code will probably be more simple and reduce
significantly, however solution will siege to work the moment
idmap_offset is not a simple additive value.

Therefore, I am OK with your implementation.

~Pratyush

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Pratyush Anand]

On Mon, May 2, 2016 at 3:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:
>> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:
>> >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> >> Hi Russell,
>> >> >>
>> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> >> <rmk+kernel@arm.linux.org.uk> wrote:
>> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> >> > know where it can place the kernel in RAM, and so be executable when
>> >> >> > the system needs to jump into it.
>> >> >> >
>> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> >> > tag.
>> >> >> >
>> >> >> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >> >>
>> >> >> Can you please also share git tree path of corresponding kexec-tools changes?
>> >> >>
>> >> >> Could it be a better idea (if things in user space become simpler)
>> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> >> user space, and then user space manipulates existing "Crash kernel"
>> >> >> and "System RAM" resources.
>> >> >
>> >> > Given that it's only _one_ platform right now, I don't think that
>> >> > additional complexity is worth it.  It means that we have to invent
>> >>
>> >> Probably, I could not communicate it well.  I was not trying  to have
>> >> *additional* complexity. Wanted to see if things could be simpler
>> >> rather. So this is what my understanding was:
>> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> >> (say in /sys/kernel/bootmem_idmap_offset)
>> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> >> content of the series will go away.
>> >
>> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
>> > 11 and 12 are necessary to allow the boot-view addresses to be passed
>> > into the kernel through kexec, and to allow kexec to find appropriate
>> > memory resources.
>>
>> But once we would have manipulated "start" and "end" of "Crash Kernel"
>> and "System RAM" resources in user space using
>> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
>> call would have already receive boot-view addresses, no?
>
> Correct, but that's still a problem for all the reasons I gave in the
> email to which you replied to.
>
> I'm not sure where the misunderstanding is.

No, no..there is no misunderstanding. I agreed to your implementation
because that will work for generic cases and for me complete series is
OK.

I just wanted to clarify my understanding, and so was the last argument.

>
> Let me repeat: even if we do what you're suggesting, patches 11 and 12
> do *not* go away.  I've explained in detail why each of the changes are
> necessary (which you have cut from your reply.)
>

Again, it is just for clarifying myself.
I cut the reply because I understood that in patch 11 and 12, you
convert addresses passed by kexec tools from run time view to boot
view using different helpers like phys_to_boot_phys(). So, had kexec
system call passed boot view addresses, we would have not needed 11
and 12. This is what I wanted to clarify.

> In other words: exporting this offset via
> /sys/kernel/bootmem_idmap_offset is technically inferior to the solution
> I have come up with here, and it saves very little complexity and code.

I still have opinion that code will probably be more simple and reduce
significantly, however solution will siege to work the moment
idmap_offset is not a simple additive value.

Therefore, I am OK with your implementation.

~Pratyush

[PATCH kexec-tools 01/32] kdump: mmap() and munmap() only work on page-aligned quantites

[Russell King]

The man page for mmap() and munmap() says that mmap() and munmap()
only works for page-aligned addresses, sizes and offsets.  Arrange
to give these interfaces what they want.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 821ee7c..3247a54 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -25,22 +25,35 @@
 #define MAP_WINDOW_SIZE (64*1024*1024)
 #define DEV_MEM "/dev/mem"
 
+#define ALIGN_MASK(x,y) (((x) + (y)) & ~(y))
+#define ALIGN(x,y)	ALIGN_MASK(x, (y) - 1)
+
 static void *map_addr(int fd, unsigned long size, off_t offset)
 {
+	unsigned long page_size = getpagesize();
+	unsigned long map_offset = offset & (page_size - 1);
+	size_t len = ALIGN(size + map_offset, page_size);
 	void *result;
-	result = mmap(0, size, PROT_READ, MAP_SHARED, fd, offset);
+
+	result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
 	if (result == MAP_FAILED) {
 		fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
 			(unsigned long long)offset, size, strerror(errno));
 		exit(5);
 	}
-	return result;
+	return result + map_offset;
 }
 
 static void unmap_addr(void *addr, unsigned long size)
 {
+	unsigned long page_size = getpagesize();
+	unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
+	size_t len = ALIGN(size + map_offset, page_size);
 	int ret;
-	ret = munmap(addr, size);
+
+	addr -= map_offset;
+
+	ret = munmap(addr, len);
 	if (ret < 0) {
 		fprintf(stderr, "munmap failed: %s\n",
 			strerror(errno));
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 01/32] kdump: mmap() and munmap() only work on page-aligned quantites

[Russell King]

The man page for mmap() and munmap() says that mmap() and munmap()
only works for page-aligned addresses, sizes and offsets.  Arrange
to give these interfaces what they want.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 821ee7c..3247a54 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -25,22 +25,35 @@
 #define MAP_WINDOW_SIZE (64*1024*1024)
 #define DEV_MEM "/dev/mem"
 
+#define ALIGN_MASK(x,y) (((x) + (y)) & ~(y))
+#define ALIGN(x,y)	ALIGN_MASK(x, (y) - 1)
+
 static void *map_addr(int fd, unsigned long size, off_t offset)
 {
+	unsigned long page_size = getpagesize();
+	unsigned long map_offset = offset & (page_size - 1);
+	size_t len = ALIGN(size + map_offset, page_size);
 	void *result;
-	result = mmap(0, size, PROT_READ, MAP_SHARED, fd, offset);
+
+	result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
 	if (result == MAP_FAILED) {
 		fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
 			(unsigned long long)offset, size, strerror(errno));
 		exit(5);
 	}
-	return result;
+	return result + map_offset;
 }
 
 static void unmap_addr(void *addr, unsigned long size)
 {
+	unsigned long page_size = getpagesize();
+	unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
+	size_t len = ALIGN(size + map_offset, page_size);
 	int ret;
-	ret = munmap(addr, size);
+
+	addr -= map_offset;
+
+	ret = munmap(addr, len);
 	if (ret < 0) {
 		fprintf(stderr, "munmap failed: %s\n",
 			strerror(errno));
-- 
1.9.1

Re: [PATCH kexec-tools 01/32] kdump: mmap() and munmap() only work on page-aligned quantites

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> The man page for mmap() and munmap() says that mmap() and munmap()
> only works for page-aligned addresses, sizes and offsets.  Arrange
> to give these interfaces what they want.
>

If I read correctly, it talks only offsets to be page aligned.

> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Anyway, changes looks good to me.
Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 821ee7c..3247a54 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -25,22 +25,35 @@
>  #define MAP_WINDOW_SIZE (64*1024*1024)
>  #define DEV_MEM "/dev/mem"
>
> +#define ALIGN_MASK(x,y) (((x) + (y)) & ~(y))
> +#define ALIGN(x,y)     ALIGN_MASK(x, (y) - 1)
> +
>  static void *map_addr(int fd, unsigned long size, off_t offset)
>  {
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = offset & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
>         void *result;
> -       result = mmap(0, size, PROT_READ, MAP_SHARED, fd, offset);
> +
> +       result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
>         if (result == MAP_FAILED) {
>                 fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
>                         (unsigned long long)offset, size, strerror(errno));
>                 exit(5);
>         }
> -       return result;
> +       return result + map_offset;
>  }
>
>  static void unmap_addr(void *addr, unsigned long size)
>  {
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
>         int ret;
> -       ret = munmap(addr, size);
> +
> +       addr -= map_offset;
> +
> +       ret = munmap(addr, len);
>         if (ret < 0) {
>                 fprintf(stderr, "munmap failed: %s\n",
>                         strerror(errno));
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 01/32] kdump: mmap() and munmap() only work on page-aligned quantites

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> The man page for mmap() and munmap() says that mmap() and munmap()
> only works for page-aligned addresses, sizes and offsets.  Arrange
> to give these interfaces what they want.
>

If I read correctly, it talks only offsets to be page aligned.

> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Anyway, changes looks good to me.
Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 821ee7c..3247a54 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -25,22 +25,35 @@
>  #define MAP_WINDOW_SIZE (64*1024*1024)
>  #define DEV_MEM "/dev/mem"
>
> +#define ALIGN_MASK(x,y) (((x) + (y)) & ~(y))
> +#define ALIGN(x,y)     ALIGN_MASK(x, (y) - 1)
> +
>  static void *map_addr(int fd, unsigned long size, off_t offset)
>  {
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = offset & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
>         void *result;
> -       result = mmap(0, size, PROT_READ, MAP_SHARED, fd, offset);
> +
> +       result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
>         if (result == MAP_FAILED) {
>                 fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
>                         (unsigned long long)offset, size, strerror(errno));
>                 exit(5);
>         }
> -       return result;
> +       return result + map_offset;
>  }
>
>  static void unmap_addr(void *addr, unsigned long size)
>  {
> +       unsigned long page_size = getpagesize();
> +       unsigned long map_offset = (uintptr_t)addr & (page_size - 1);
> +       size_t len = ALIGN(size + map_offset, page_size);
>         int ret;
> -       ret = munmap(addr, size);
> +
> +       addr -= map_offset;
> +
> +       ret = munmap(addr, len);
>         if (ret < 0) {
>                 fprintf(stderr, "munmap failed: %s\n",
>                         strerror(errno));
> --
> 1.9.1
>

Re: [PATCH kexec-tools 01/32] kdump: mmap() and munmap() only work on page-aligned quantites

[Russell King - ARM Linux]

On Wed, May 25, 2016 at 11:46:08AM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > The man page for mmap() and munmap() says that mmap() and munmap()
> > only works for page-aligned addresses, sizes and offsets.  Arrange
> > to give these interfaces what they want.
> >
> 
> If I read correctly, it talks only offsets to be page aligned.

Yes, it's not really needed, but as we have to adjust the size anyway to
compensate for the reduced file offset, it makes little difference whether
we align the size or not.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 01/32] kdump: mmap() and munmap() only work on page-aligned quantites

[Russell King - ARM Linux]

On Wed, May 25, 2016 at 11:46:08AM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > The man page for mmap() and munmap() says that mmap() and munmap()
> > only works for page-aligned addresses, sizes and offsets.  Arrange
> > to give these interfaces what they want.
> >
> 
> If I read correctly, it talks only offsets to be page aligned.

Yes, it's not really needed, but as we have to adjust the size anyway to
compensate for the reduced file offset, it makes little difference whether
we align the size or not.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH kexec-tools 02/32] kdump: fix multiple program header entries

[Russell King]

generate_new_headers() forgot to increment the program header pointer
after adding each program header from the kexec template. Fix it to
increment it correctly.

Without this, the program headers contain only the last entry, which
means we will be missing most of the kernel image in the dump.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 3247a54..99a1789 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -192,6 +192,7 @@ static void *generate_new_headers(
 		}
 		memcpy(nphdr, &phdr[i], sizeof(*nphdr));
 		nphdr->p_offset = offset;
+		nphdr++;
 		offset += phdr[i].p_filesz;
 	}
 	
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 02/32] kdump: fix multiple program header entries

[Russell King]

generate_new_headers() forgot to increment the program header pointer
after adding each program header from the kexec template. Fix it to
increment it correctly.

Without this, the program headers contain only the last entry, which
means we will be missing most of the kernel image in the dump.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 3247a54..99a1789 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -192,6 +192,7 @@ static void *generate_new_headers(
 		}
 		memcpy(nphdr, &phdr[i], sizeof(*nphdr));
 		nphdr->p_offset = offset;
+		nphdr++;
 		offset += phdr[i].p_filesz;
 	}
 	
-- 
1.9.1

Re: [PATCH kexec-tools 02/32] kdump: fix multiple program header entries

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> generate_new_headers() forgot to increment the program header pointer
> after adding each program header from the kexec template. Fix it to
> increment it correctly.
>
> Without this, the program headers contain only the last entry, which
> means we will be missing most of the kernel image in the dump.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 3247a54..99a1789 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -192,6 +192,7 @@ static void *generate_new_headers(
>                 }
>                 memcpy(nphdr, &phdr[i], sizeof(*nphdr));
>                 nphdr->p_offset = offset;
> +               nphdr++;
>                 offset += phdr[i].p_filesz;
>         }
>
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 02/32] kdump: fix multiple program header entries

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> generate_new_headers() forgot to increment the program header pointer
> after adding each program header from the kexec template. Fix it to
> increment it correctly.
>
> Without this, the program headers contain only the last entry, which
> means we will be missing most of the kernel image in the dump.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 3247a54..99a1789 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -192,6 +192,7 @@ static void *generate_new_headers(
>                 }
>                 memcpy(nphdr, &phdr[i], sizeof(*nphdr));
>                 nphdr->p_offset = offset;
> +               nphdr++;
>                 offset += phdr[i].p_filesz;
>         }
>
> --
> 1.9.1
>

[PATCH kexec-tools 03/32] kdump: actually write out the memory

[Russell King]

Actually write out the memory rather than writing the notes a second
time.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 99a1789..1f5b984 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -300,7 +300,7 @@ int main(int argc, char **argv)
 	for(i = 0; i < ehdr->e_phnum; i++) {
 		unsigned long long offset, size;
 		size_t wsize;
-		if (phdr[i].p_type != PT_NOTE) {
+		if (phdr[i].p_type == PT_NOTE) {
 			continue;
 		}
 		offset = phdr[i].p_offset;
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 03/32] kdump: actually write out the memory

[Russell King]

Actually write out the memory rather than writing the notes a second
time.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 99a1789..1f5b984 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -300,7 +300,7 @@ int main(int argc, char **argv)
 	for(i = 0; i < ehdr->e_phnum; i++) {
 		unsigned long long offset, size;
 		size_t wsize;
-		if (phdr[i].p_type != PT_NOTE) {
+		if (phdr[i].p_type == PT_NOTE) {
 			continue;
 		}
 		offset = phdr[i].p_offset;
-- 
1.9.1

Re: [PATCH kexec-tools 03/32] kdump: actually write out the memory

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Actually write out the memory rather than writing the notes a second
> time.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 99a1789..1f5b984 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -300,7 +300,7 @@ int main(int argc, char **argv)
>         for(i = 0; i < ehdr->e_phnum; i++) {
>                 unsigned long long offset, size;
>                 size_t wsize;
> -               if (phdr[i].p_type != PT_NOTE) {
> +               if (phdr[i].p_type == PT_NOTE) {
>                         continue;
>                 }
>                 offset = phdr[i].p_offset;
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 03/32] kdump: actually write out the memory

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Actually write out the memory rather than writing the notes a second
> time.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 99a1789..1f5b984 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -300,7 +300,7 @@ int main(int argc, char **argv)
>         for(i = 0; i < ehdr->e_phnum; i++) {
>                 unsigned long long offset, size;
>                 size_t wsize;
> -               if (phdr[i].p_type != PT_NOTE) {
> +               if (phdr[i].p_type == PT_NOTE) {
>                         continue;
>                 }
>                 offset = phdr[i].p_offset;
> --
> 1.9.1
>

[PATCH kexec-tools 04/32] kdump: fix kdump mapping

[Russell King]

When kdump tries to map the program header, it fails to take account
of ehdr->e_phoff being an offset from the start of the ELF "file",
which causes:

Cannot mmap /dev/mem offset: 64 size: 392: Invalid argument

Ensure that we take account of the start address when mapping this.

This fix has been extracted from a larger patch by Vitaly Andrianov
adding support for Keystone 2.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 1f5b984..34d2149 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -284,7 +284,8 @@ int main(int argc, char **argv)
 	}
 	
 	/* Get the program header */
-	phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
+	phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), 
+			start_addr + ehdr->e_phoff);
 
 	/* Collect up the notes */
 	note_bytes = 0;
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 04/32] kdump: fix kdump mapping

[Russell King]

When kdump tries to map the program header, it fails to take account
of ehdr->e_phoff being an offset from the start of the ELF "file",
which causes:

Cannot mmap /dev/mem offset: 64 size: 392: Invalid argument

Ensure that we take account of the start address when mapping this.

This fix has been extracted from a larger patch by Vitaly Andrianov
adding support for Keystone 2.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 1f5b984..34d2149 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -284,7 +284,8 @@ int main(int argc, char **argv)
 	}
 	
 	/* Get the program header */
-	phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
+	phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), 
+			start_addr + ehdr->e_phoff);
 
 	/* Collect up the notes */
 	note_bytes = 0;
-- 
1.9.1

Re: [PATCH kexec-tools 04/32] kdump: fix kdump mapping

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> When kdump tries to map the program header, it fails to take account
> of ehdr->e_phoff being an offset from the start of the ELF "file",
> which causes:
>
> Cannot mmap /dev/mem offset: 64 size: 392: Invalid argument
>
> Ensure that we take account of the start address when mapping this.
>
> This fix has been extracted from a larger patch by Vitaly Andrianov
> adding support for Keystone 2.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kdump/kdump.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 1f5b984..34d2149 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -284,7 +284,8 @@ int main(int argc, char **argv)
>         }
>
>         /* Get the program header */
> -       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
> +       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum),
> +                       start_addr + ehdr->e_phoff);

This is fine. But at the same time should n't we also fix the offset
for mmap of memory segments?  For memory segments, offset is
phdr[i].p_offset, and I do not see generate_new_headers() taking care
of start_addr.

>
>         /* Collect up the notes */
>         note_bytes = 0;
> --
> 1.9.1
>

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 04/32] kdump: fix kdump mapping

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> When kdump tries to map the program header, it fails to take account
> of ehdr->e_phoff being an offset from the start of the ELF "file",
> which causes:
>
> Cannot mmap /dev/mem offset: 64 size: 392: Invalid argument
>
> Ensure that we take account of the start address when mapping this.
>
> This fix has been extracted from a larger patch by Vitaly Andrianov
> adding support for Keystone 2.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kdump/kdump.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 1f5b984..34d2149 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -284,7 +284,8 @@ int main(int argc, char **argv)
>         }
>
>         /* Get the program header */
> -       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
> +       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum),
> +                       start_addr + ehdr->e_phoff);

This is fine. But at the same time should n't we also fix the offset
for mmap of memory segments?  For memory segments, offset is
phdr[i].p_offset, and I do not see generate_new_headers() taking care
of start_addr.

>
>         /* Collect up the notes */
>         note_bytes = 0;
> --
> 1.9.1
>

~Pratyush

Re: [PATCH kexec-tools 04/32] kdump: fix kdump mapping

[Russell King - ARM Linux]

On Wed, May 25, 2016 at 11:47:33AM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > diff --git a/kdump/kdump.c b/kdump/kdump.c
> > index 1f5b984..34d2149 100644
> > --- a/kdump/kdump.c
> > +++ b/kdump/kdump.c
> > @@ -284,7 +284,8 @@ int main(int argc, char **argv)
> >         }
> >
> >         /* Get the program header */
> > -       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
> > +       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum),
> > +                       start_addr + ehdr->e_phoff);
> 
> This is fine. But at the same time should n't we also fix the offset
> for mmap of memory segments?  For memory segments, offset is
> phdr[i].p_offset, and I do not see generate_new_headers() taking care
> of start_addr.

Unfortunately not.  The reason is, p_offset is not an offset, but an
absolute address - see kexec/crashdump-elf.c, which is the bit of
code which creates the table and writes it into kernel memory when
loading the panic kernel:

                phdr->p_offset  = phdr->p_paddr = notes_addr;

                phdr->p_offset  = phdr->p_paddr = vmcoreinfo_addr;

                phdr->p_offset  = phdr->p_paddr = elf_info->kern_paddr_start;

                mstart = range->start;
                phdr->p_offset  = mstart;
                phdr->p_paddr = mstart;

etc.  So, p_offset is also the physical address, not the file offset.
Of course, that could be a bug in crashdump-elf.c.  To change that,
we would also need to fix crashdump-elf.c in lock-step as well.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 04/32] kdump: fix kdump mapping

[Russell King - ARM Linux]

On Wed, May 25, 2016 at 11:47:33AM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > diff --git a/kdump/kdump.c b/kdump/kdump.c
> > index 1f5b984..34d2149 100644
> > --- a/kdump/kdump.c
> > +++ b/kdump/kdump.c
> > @@ -284,7 +284,8 @@ int main(int argc, char **argv)
> >         }
> >
> >         /* Get the program header */
> > -       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum), ehdr->e_phoff);
> > +       phdr = map_addr(fd, sizeof(*phdr)*(ehdr->e_phnum),
> > +                       start_addr + ehdr->e_phoff);
> 
> This is fine. But at the same time should n't we also fix the offset
> for mmap of memory segments?  For memory segments, offset is
> phdr[i].p_offset, and I do not see generate_new_headers() taking care
> of start_addr.

Unfortunately not.  The reason is, p_offset is not an offset, but an
absolute address - see kexec/crashdump-elf.c, which is the bit of
code which creates the table and writes it into kernel memory when
loading the panic kernel:

                phdr->p_offset  = phdr->p_paddr = notes_addr;

                phdr->p_offset  = phdr->p_paddr = vmcoreinfo_addr;

                phdr->p_offset  = phdr->p_paddr = elf_info->kern_paddr_start;

                mstart = range->start;
                phdr->p_offset  = mstart;
                phdr->p_paddr = mstart;

etc.  So, p_offset is also the physical address, not the file offset.
Of course, that could be a bug in crashdump-elf.c.  To change that,
we would also need to fix crashdump-elf.c in lock-step as well.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH kexec-tools 05/32] arm: fix kdump to work on LPAE systems

[Russell King]

We need to use 64-bit file IO when mapping system memory and the core
dump file as we may be running on a LPAE system, otherwise we risk
mapping memory we shouldn't, and causing a kernel oops:

Unhandled fault: asynchronous external abort (0x211) at 0x00000000
pgd = edd2c740
[00000000] *pgd=82ec98003, *pmd=82dcd2003, *pte=00000000

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
index 38137d7..60e433a 100644
--- a/kexec/arch/arm/Makefile
+++ b/kexec/arch/arm/Makefile
@@ -18,6 +18,9 @@ libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%)
 
 arm_CPPFLAGS = -I$(srcdir)/kexec/libfdt
 
+# We want 64-bit file IO for kdump to work correctly on LPAE systems
+arm_CPPFLAGS += -D_FILE_OFFSET_BITS=64
+
 arm_KEXEC_SRCS += $(libfdt_SRCS)
 
 arm_UIMAGE = kexec/kexec-uImage.c
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 05/32] arm: fix kdump to work on LPAE systems

[Russell King]

We need to use 64-bit file IO when mapping system memory and the core
dump file as we may be running on a LPAE system, otherwise we risk
mapping memory we shouldn't, and causing a kernel oops:

Unhandled fault: asynchronous external abort (0x211) at 0x00000000
pgd = edd2c740
[00000000] *pgd=82ec98003, *pmd=82dcd2003, *pte=00000000

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
index 38137d7..60e433a 100644
--- a/kexec/arch/arm/Makefile
+++ b/kexec/arch/arm/Makefile
@@ -18,6 +18,9 @@ libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%)
 
 arm_CPPFLAGS = -I$(srcdir)/kexec/libfdt
 
+# We want 64-bit file IO for kdump to work correctly on LPAE systems
+arm_CPPFLAGS += -D_FILE_OFFSET_BITS=64
+
 arm_KEXEC_SRCS += $(libfdt_SRCS)
 
 arm_UIMAGE = kexec/kexec-uImage.c
-- 
1.9.1

Re: [PATCH kexec-tools 05/32] arm: fix kdump to work on LPAE systems

[Baoquan He]

On 05/03/16 at 11:21am, Russell King wrote:
> We need to use 64-bit file IO when mapping system memory and the core
> dump file as we may be running on a LPAE system, otherwise we risk
> mapping memory we shouldn't, and causing a kernel oops:
> 
> Unhandled fault: asynchronous external abort (0x211) at 0x00000000
> pgd = edd2c740
> [00000000] *pgd=82ec98003, *pmd=82dcd2003, *pte=00000000
> 
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/arch/arm/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
> index 38137d7..60e433a 100644
> --- a/kexec/arch/arm/Makefile
> +++ b/kexec/arch/arm/Makefile
> @@ -18,6 +18,9 @@ libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%)
>  
>  arm_CPPFLAGS = -I$(srcdir)/kexec/libfdt
>  
> +# We want 64-bit file IO for kdump to work correctly on LPAE systems
> +arm_CPPFLAGS += -D_FILE_OFFSET_BITS=64
> +

It makes sense in this situation.

In "man 2 stat" and /usr/include/features.h, we can find the relevant
information.

EOVERFLOW
	pathname or fd refers to a file whose size, inode number, or number
	of blocks cannot be represented in, respectively, the types off_t, ino_t,
	or blkcnt_t.  This error can occur when, for example, an  application
	compiled  on  a  32-bit  platform  without -D_FILE_OFFSET_BITS=64 calls
	stat() on a file whose size exceeds (1<<31)-1 bytes.

Ack this patch.

Acked-by: Baoquan He <bhe@redhat.com>

Baoquan
Thanks

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 05/32] arm: fix kdump to work on LPAE systems

[Baoquan He]

On 05/03/16 at 11:21am, Russell King wrote:
> We need to use 64-bit file IO when mapping system memory and the core
> dump file as we may be running on a LPAE system, otherwise we risk
> mapping memory we shouldn't, and causing a kernel oops:
> 
> Unhandled fault: asynchronous external abort (0x211) at 0x00000000
> pgd = edd2c740
> [00000000] *pgd=82ec98003, *pmd=82dcd2003, *pte=00000000
> 
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/arch/arm/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
> index 38137d7..60e433a 100644
> --- a/kexec/arch/arm/Makefile
> +++ b/kexec/arch/arm/Makefile
> @@ -18,6 +18,9 @@ libfdt_SRCS += $(LIBFDT_SRCS:%=kexec/libfdt/%)
>  
>  arm_CPPFLAGS = -I$(srcdir)/kexec/libfdt
>  
> +# We want 64-bit file IO for kdump to work correctly on LPAE systems
> +arm_CPPFLAGS += -D_FILE_OFFSET_BITS=64
> +

It makes sense in this situation.

In "man 2 stat" and /usr/include/features.h, we can find the relevant
information.

EOVERFLOW
	pathname or fd refers to a file whose size, inode number, or number
	of blocks cannot be represented in, respectively, the types off_t, ino_t,
	or blkcnt_t.  This error can occur when, for example, an  application
	compiled  on  a  32-bit  platform  without -D_FILE_OFFSET_BITS=64 calls
	stat() on a file whose size exceeds (1<<31)-1 bytes.

Ack this patch.

Acked-by: Baoquan He <bhe@redhat.com>

Baoquan
Thanks

[PATCH kexec-tools 06/32] kdump: print mmap() offset in hex

[Russell King]

When mmap() fails, printing a large decimal number is mostly
meaningless - it's not obvious what it means.  Printing a hex number
is more obvious, because we can see whether it's over 32-bit, or not
page aligned.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 34d2149..f34727f 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -37,7 +37,7 @@ static void *map_addr(int fd, unsigned long size, off_t offset)
 
 	result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
 	if (result == MAP_FAILED) {
-		fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
+		fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
 			(unsigned long long)offset, size, strerror(errno));
 		exit(5);
 	}
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 06/32] kdump: print mmap() offset in hex

[Russell King]

When mmap() fails, printing a large decimal number is mostly
meaningless - it's not obvious what it means.  Printing a hex number
is more obvious, because we can see whether it's over 32-bit, or not
page aligned.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kdump/kdump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kdump/kdump.c b/kdump/kdump.c
index 34d2149..f34727f 100644
--- a/kdump/kdump.c
+++ b/kdump/kdump.c
@@ -37,7 +37,7 @@ static void *map_addr(int fd, unsigned long size, off_t offset)
 
 	result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
 	if (result == MAP_FAILED) {
-		fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
+		fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
 			(unsigned long long)offset, size, strerror(errno));
 		exit(5);
 	}
-- 
1.9.1

Re: [PATCH kexec-tools 06/32] kdump: print mmap() offset in hex

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> When mmap() fails, printing a large decimal number is mostly
> meaningless - it's not obvious what it means.  Printing a hex number
> is more obvious, because we can see whether it's over 32-bit, or not
> page aligned.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Looks good to me.
Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 34d2149..f34727f 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -37,7 +37,7 @@ static void *map_addr(int fd, unsigned long size, off_t offset)
>
>         result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
>         if (result == MAP_FAILED) {
> -               fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
> +               fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
>                         (unsigned long long)offset, size, strerror(errno));
>                 exit(5);
>         }
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 06/32] kdump: print mmap() offset in hex

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> When mmap() fails, printing a large decimal number is mostly
> meaningless - it's not obvious what it means.  Printing a hex number
> is more obvious, because we can see whether it's over 32-bit, or not
> page aligned.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Looks good to me.
Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kdump/kdump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kdump/kdump.c b/kdump/kdump.c
> index 34d2149..f34727f 100644
> --- a/kdump/kdump.c
> +++ b/kdump/kdump.c
> @@ -37,7 +37,7 @@ static void *map_addr(int fd, unsigned long size, off_t offset)
>
>         result = mmap(0, len, PROT_READ, MAP_SHARED, fd, offset - map_offset);
>         if (result == MAP_FAILED) {
> -               fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %llu size: %lu: %s\n",
> +               fprintf(stderr, "Cannot mmap " DEV_MEM " offset: %#llx size: %lu: %s\n",
>                         (unsigned long long)offset, size, strerror(errno));
>                 exit(5);
>         }
> --
> 1.9.1
>

[PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Russell King]

Fix warnings caused by selecting 64-bit file IO on 32-bit platforms.

kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat]
kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'off_t' [-Wformat]
kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long
int', but argument 2 has type 'off_t' [-Wformat]

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/kexec-uImage.c | 3 ++-
 kexec/kexec.c        | 4 ++--
 kexec/zlib.c         | 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
index 9df601b..5e24629 100644
--- a/kexec/kexec-uImage.c
+++ b/kexec/kexec-uImage.c
@@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
 	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
 		printf("uImage header claims that image has %d bytes\n",
 				be32_to_cpu(header.ih_size));
-		printf("we read only %ld bytes.\n", len - sizeof(header));
+		printf("we read only %lld bytes.\n",
+		       (long long)len - sizeof(header));
 		return -1;
 	}
 #ifdef HAVE_LIBZ
diff --git a/kexec/kexec.c b/kexec/kexec.c
index f0bd527..500e5a9 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -707,8 +707,8 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
 	/* slurp in the input kernel */
 	kernel_buf = slurp_decompress_file(kernel, &kernel_size);
 
-	dbgprintf("kernel: %p kernel_size: 0x%lx\n",
-		  kernel_buf, kernel_size);
+	dbgprintf("kernel: %p kernel_size: %#llx\n",
+		  kernel_buf, (unsigned long long)kernel_size);
 
 	if (get_memory_ranges(&info.memory_range, &info.memory_ranges,
 		info.kexec_flags) < 0 || info.memory_ranges == 0) {
diff --git a/kexec/zlib.c b/kexec/zlib.c
index 7170ac3..95b6080 100644
--- a/kexec/zlib.c
+++ b/kexec/zlib.c
@@ -60,8 +60,8 @@ char *zlib_decompress_file(const char *filename, off_t *r_size)
 			if ((errno == EINTR) || (errno == EAGAIN))
 				continue;
 			_gzerror(fp, &errnum, &msg);
-			dbgprintf("Read on %s of %ld bytes failed: %s\n",
-					filename, (allocated - size) + 0UL, msg);
+			dbgprintf("Read on %s of %d bytes failed: %s\n",
+				  filename, (int)(allocated - size), msg);
 			size = 0;
 			goto fail;
 		}
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Russell King]

Fix warnings caused by selecting 64-bit file IO on 32-bit platforms.

kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat]
kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'off_t' [-Wformat]
kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long
int', but argument 2 has type 'off_t' [-Wformat]

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/kexec-uImage.c | 3 ++-
 kexec/kexec.c        | 4 ++--
 kexec/zlib.c         | 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
index 9df601b..5e24629 100644
--- a/kexec/kexec-uImage.c
+++ b/kexec/kexec-uImage.c
@@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
 	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
 		printf("uImage header claims that image has %d bytes\n",
 				be32_to_cpu(header.ih_size));
-		printf("we read only %ld bytes.\n", len - sizeof(header));
+		printf("we read only %lld bytes.\n",
+		       (long long)len - sizeof(header));
 		return -1;
 	}
 #ifdef HAVE_LIBZ
diff --git a/kexec/kexec.c b/kexec/kexec.c
index f0bd527..500e5a9 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -707,8 +707,8 @@ static int my_load(const char *type, int fileind, int argc, char **argv,
 	/* slurp in the input kernel */
 	kernel_buf = slurp_decompress_file(kernel, &kernel_size);
 
-	dbgprintf("kernel: %p kernel_size: 0x%lx\n",
-		  kernel_buf, kernel_size);
+	dbgprintf("kernel: %p kernel_size: %#llx\n",
+		  kernel_buf, (unsigned long long)kernel_size);
 
 	if (get_memory_ranges(&info.memory_range, &info.memory_ranges,
 		info.kexec_flags) < 0 || info.memory_ranges == 0) {
diff --git a/kexec/zlib.c b/kexec/zlib.c
index 7170ac3..95b6080 100644
--- a/kexec/zlib.c
+++ b/kexec/zlib.c
@@ -60,8 +60,8 @@ char *zlib_decompress_file(const char *filename, off_t *r_size)
 			if ((errno == EINTR) || (errno == EAGAIN))
 				continue;
 			_gzerror(fp, &errnum, &msg);
-			dbgprintf("Read on %s of %ld bytes failed: %s\n",
-					filename, (allocated - size) + 0UL, msg);
+			dbgprintf("Read on %s of %d bytes failed: %s\n",
+				  filename, (int)(allocated - size), msg);
 			size = 0;
 			goto fail;
 		}
-- 
1.9.1

Re: [PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Baoquan He]

On 05/03/16 at 11:21am, Russell King wrote:
> Fix warnings caused by selecting 64-bit file IO on 32-bit platforms.
> 
> kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat]
> kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'off_t' [-Wformat]
> kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long
> int', but argument 2 has type 'off_t' [-Wformat]
> 
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/kexec-uImage.c | 3 ++-
>  kexec/kexec.c        | 4 ++--
>  kexec/zlib.c         | 4 ++--
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
> index 9df601b..5e24629 100644
> --- a/kexec/kexec-uImage.c
> +++ b/kexec/kexec-uImage.c
> @@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
>  	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
>  		printf("uImage header claims that image has %d bytes\n",
>  				be32_to_cpu(header.ih_size));
> -		printf("we read only %ld bytes.\n", len - sizeof(header));
> +		printf("we read only %lld bytes.\n",
> +		       (long long)len - sizeof(header));

With "D_FILE_OFFSET_BITS=64" adding, off_t is identical to off64_t, is
that necessary to still take a type conversion here?

Is that OK to be like this:

		printf("we read only %lld bytes.\n", len - sizeof(header));


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Baoquan He]

On 05/03/16 at 11:21am, Russell King wrote:
> Fix warnings caused by selecting 64-bit file IO on 32-bit platforms.
> 
> kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat]
> kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'off_t' [-Wformat]
> kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long
> int', but argument 2 has type 'off_t' [-Wformat]
> 
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/kexec-uImage.c | 3 ++-
>  kexec/kexec.c        | 4 ++--
>  kexec/zlib.c         | 4 ++--
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
> index 9df601b..5e24629 100644
> --- a/kexec/kexec-uImage.c
> +++ b/kexec/kexec-uImage.c
> @@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
>  	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
>  		printf("uImage header claims that image has %d bytes\n",
>  				be32_to_cpu(header.ih_size));
> -		printf("we read only %ld bytes.\n", len - sizeof(header));
> +		printf("we read only %lld bytes.\n",
> +		       (long long)len - sizeof(header));

With "D_FILE_OFFSET_BITS=64" adding, off_t is identical to off64_t, is
that necessary to still take a type conversion here?

Is that OK to be like this:

		printf("we read only %lld bytes.\n", len - sizeof(header));

Re: [PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Russell King - ARM Linux]

On Sat, May 28, 2016 at 07:33:54PM +0800, Baoquan He wrote:
> On 05/03/16 at 11:21am, Russell King wrote:
> > diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
> > index 9df601b..5e24629 100644
> > --- a/kexec/kexec-uImage.c
> > +++ b/kexec/kexec-uImage.c
> > @@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
> >  	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
> >  		printf("uImage header claims that image has %d bytes\n",
> >  				be32_to_cpu(header.ih_size));
> > -		printf("we read only %ld bytes.\n", len - sizeof(header));
> > +		printf("we read only %lld bytes.\n",
> > +		       (long long)len - sizeof(header));
> 
> With "D_FILE_OFFSET_BITS=64" adding, off_t is identical to off64_t, is
> that necessary to still take a type conversion here?

The printf format specifies an argument of "long long" type, which is
defined as a data type of at least 64-bits wide.  So, it's more
correct to cast to long long, rather than relying on off64_t being
the same size as long long.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Russell King - ARM Linux]

On Sat, May 28, 2016 at 07:33:54PM +0800, Baoquan He wrote:
> On 05/03/16 at 11:21am, Russell King wrote:
> > diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
> > index 9df601b..5e24629 100644
> > --- a/kexec/kexec-uImage.c
> > +++ b/kexec/kexec-uImage.c
> > @@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
> >  	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
> >  		printf("uImage header claims that image has %d bytes\n",
> >  				be32_to_cpu(header.ih_size));
> > -		printf("we read only %ld bytes.\n", len - sizeof(header));
> > +		printf("we read only %lld bytes.\n",
> > +		       (long long)len - sizeof(header));
> 
> With "D_FILE_OFFSET_BITS=64" adding, off_t is identical to off64_t, is
> that necessary to still take a type conversion here?

The printf format specifies an argument of "long long" type, which is
defined as a data type of at least 64-bits wide.  So, it's more
correct to cast to long long, rather than relying on off64_t being
the same size as long long.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Baoquan He]

On 05/28/16 at 02:53pm, Russell King - ARM Linux wrote:
> On Sat, May 28, 2016 at 07:33:54PM +0800, Baoquan He wrote:
> > On 05/03/16 at 11:21am, Russell King wrote:
> > > diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
> > > index 9df601b..5e24629 100644
> > > --- a/kexec/kexec-uImage.c
> > > +++ b/kexec/kexec-uImage.c
> > > @@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
> > >  	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
> > >  		printf("uImage header claims that image has %d bytes\n",
> > >  				be32_to_cpu(header.ih_size));
> > > -		printf("we read only %ld bytes.\n", len - sizeof(header));
> > > +		printf("we read only %lld bytes.\n",
> > > +		       (long long)len - sizeof(header));
> > 
> > With "D_FILE_OFFSET_BITS=64" adding, off_t is identical to off64_t, is
> > that necessary to still take a type conversion here?
> 
> The printf format specifies an argument of "long long" type, which is
> defined as a data type of at least 64-bits wide.  So, it's more
> correct to cast to long long, rather than relying on off64_t being
> the same size as long long.

Ok, it's fine to have an explict cast here so that people don't need
to consider off_t is long or long long.

Ack this patch.

Acked-by: Baoquan He <bhe@redhat.com>

Thanks
Baoquan


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 07/32] kexec: fix warnings caused by selecting 64-bit file IO on 32-bit platforms

[Baoquan He]

On 05/28/16 at 02:53pm, Russell King - ARM Linux wrote:
> On Sat, May 28, 2016 at 07:33:54PM +0800, Baoquan He wrote:
> > On 05/03/16 at 11:21am, Russell King wrote:
> > > diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c
> > > index 9df601b..5e24629 100644
> > > --- a/kexec/kexec-uImage.c
> > > +++ b/kexec/kexec-uImage.c
> > > @@ -82,7 +82,8 @@ int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch)
> > >  	if (be32_to_cpu(header.ih_size) > len - sizeof(header)) {
> > >  		printf("uImage header claims that image has %d bytes\n",
> > >  				be32_to_cpu(header.ih_size));
> > > -		printf("we read only %ld bytes.\n", len - sizeof(header));
> > > +		printf("we read only %lld bytes.\n",
> > > +		       (long long)len - sizeof(header));
> > 
> > With "D_FILE_OFFSET_BITS=64" adding, off_t is identical to off64_t, is
> > that necessary to still take a type conversion here?
> 
> The printf format specifies an argument of "long long" type, which is
> defined as a data type of at least 64-bits wide.  So, it's more
> correct to cast to long long, rather than relying on off64_t being
> the same size as long long.

Ok, it's fine to have an explict cast here so that people don't need
to consider off_t is long or long long.

Ack this patch.

Acked-by: Baoquan He <bhe@redhat.com>

Thanks
Baoquan

[PATCH kexec-tools 08/32] kexec: add max_size to memory_ranges

[Russell King]

Many implementations statically allocate the memory range array, which
therefore will have a maximum allowable size.  Add this information to
the memory_ranges structure, so we don't have to carry it around.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/kexec.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kexec/kexec.h b/kexec/kexec.h
index c02ac8f..9194f1c 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -142,6 +142,7 @@ struct memory_range {
 
 struct memory_ranges {
         unsigned int size;
+	unsigned int max_size;
         struct memory_range *ranges;
 };
 
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 08/32] kexec: add max_size to memory_ranges

[Russell King]

Many implementations statically allocate the memory range array, which
therefore will have a maximum allowable size.  Add this information to
the memory_ranges structure, so we don't have to carry it around.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/kexec.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kexec/kexec.h b/kexec/kexec.h
index c02ac8f..9194f1c 100644
--- a/kexec/kexec.h
+++ b/kexec/kexec.h
@@ -142,6 +142,7 @@ struct memory_range {
 
 struct memory_ranges {
         unsigned int size;
+	unsigned int max_size;
         struct memory_range *ranges;
 };
 
-- 
1.9.1

Re: [PATCH kexec-tools 08/32] kexec: add max_size to memory_ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Many implementations statically allocate the memory range array, which
> therefore will have a maximum allowable size.  Add this information to
> the memory_ranges structure, so we don't have to carry it around.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/kexec.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kexec/kexec.h b/kexec/kexec.h
> index c02ac8f..9194f1c 100644
> --- a/kexec/kexec.h
> +++ b/kexec/kexec.h
> @@ -142,6 +142,7 @@ struct memory_range {
>
>  struct memory_ranges {
>          unsigned int size;
> +       unsigned int max_size;
>          struct memory_range *ranges;
>  };
>
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 08/32] kexec: add max_size to memory_ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Many implementations statically allocate the memory range array, which
> therefore will have a maximum allowable size.  Add this information to
> the memory_ranges structure, so we don't have to carry it around.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/kexec.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/kexec/kexec.h b/kexec/kexec.h
> index c02ac8f..9194f1c 100644
> --- a/kexec/kexec.h
> +++ b/kexec/kexec.h
> @@ -142,6 +142,7 @@ struct memory_range {
>
>  struct memory_ranges {
>          unsigned int size;
> +       unsigned int max_size;
>          struct memory_range *ranges;
>  };
>
> --
> 1.9.1
>

[PATCH kexec-tools 09/32] kexec: phys_to_virt() must take unsigned long long

[Russell King]

crashdump-elf.c passes unsigned long long addresses into phys_to_virt()
so make phys_to_virt() accept such addresses without truncating them.
This is important for ARM LPAE systems.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/phys_to_virt.c | 2 +-
 kexec/crashdump.h             | 2 +-
 kexec/phys_to_virt.c          | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
index bcced52..c2fe2ea 100644
--- a/kexec/arch/arm/phys_to_virt.c
+++ b/kexec/arch/arm/phys_to_virt.c
@@ -14,7 +14,7 @@
  * http://lists.arm.linux.org.uk/lurker/message/20010723.185051.94ce743c.en.html
  */
 unsigned long
-phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
+phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
 {
 	return paddr + elf_info->page_offset - phys_offset;
 }
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index 95f1f0c..96219a8 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -55,7 +55,7 @@ int crash_create_elf64_headers(struct kexec_info *info,
 unsigned long crash_architecture(struct crash_elf_info *elf_info);
 
 unsigned long phys_to_virt(struct crash_elf_info *elf_info,
-			   unsigned long paddr);
+			   unsigned long long paddr);
 
 unsigned long xen_architecture(struct crash_elf_info *elf_info);
 int xen_get_nr_phys_cpus(void);
diff --git a/kexec/phys_to_virt.c b/kexec/phys_to_virt.c
index 91b6d01..5e8c4e3 100644
--- a/kexec/phys_to_virt.c
+++ b/kexec/phys_to_virt.c
@@ -10,7 +10,7 @@
  * their own implementation.
  */
 unsigned long
-phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
+phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
 {
 	return paddr + elf_info->page_offset;
 }
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 09/32] kexec: phys_to_virt() must take unsigned long long

[Russell King]

crashdump-elf.c passes unsigned long long addresses into phys_to_virt()
so make phys_to_virt() accept such addresses without truncating them.
This is important for ARM LPAE systems.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/phys_to_virt.c | 2 +-
 kexec/crashdump.h             | 2 +-
 kexec/phys_to_virt.c          | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
index bcced52..c2fe2ea 100644
--- a/kexec/arch/arm/phys_to_virt.c
+++ b/kexec/arch/arm/phys_to_virt.c
@@ -14,7 +14,7 @@
  * http://lists.arm.linux.org.uk/lurker/message/20010723.185051.94ce743c.en.html
  */
 unsigned long
-phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
+phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
 {
 	return paddr + elf_info->page_offset - phys_offset;
 }
diff --git a/kexec/crashdump.h b/kexec/crashdump.h
index 95f1f0c..96219a8 100644
--- a/kexec/crashdump.h
+++ b/kexec/crashdump.h
@@ -55,7 +55,7 @@ int crash_create_elf64_headers(struct kexec_info *info,
 unsigned long crash_architecture(struct crash_elf_info *elf_info);
 
 unsigned long phys_to_virt(struct crash_elf_info *elf_info,
-			   unsigned long paddr);
+			   unsigned long long paddr);
 
 unsigned long xen_architecture(struct crash_elf_info *elf_info);
 int xen_get_nr_phys_cpus(void);
diff --git a/kexec/phys_to_virt.c b/kexec/phys_to_virt.c
index 91b6d01..5e8c4e3 100644
--- a/kexec/phys_to_virt.c
+++ b/kexec/phys_to_virt.c
@@ -10,7 +10,7 @@
  * their own implementation.
  */
 unsigned long
-phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
+phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
 {
 	return paddr + elf_info->page_offset;
 }
-- 
1.9.1

Re: [PATCH kexec-tools 09/32] kexec: phys_to_virt() must take unsigned long long

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> crashdump-elf.c passes unsigned long long addresses into phys_to_virt()
> so make phys_to_virt() accept such addresses without truncating them.
> This is important for ARM LPAE systems.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/phys_to_virt.c | 2 +-
>  kexec/crashdump.h             | 2 +-
>  kexec/phys_to_virt.c          | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
> index bcced52..c2fe2ea 100644
> --- a/kexec/arch/arm/phys_to_virt.c
> +++ b/kexec/arch/arm/phys_to_virt.c
> @@ -14,7 +14,7 @@
>   * http://lists.arm.linux.org.uk/lurker/message/20010723.185051.94ce743c.en.html
>   */
>  unsigned long
> -phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
> +phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
>  {
>         return paddr + elf_info->page_offset - phys_offset;
>  }
> diff --git a/kexec/crashdump.h b/kexec/crashdump.h
> index 95f1f0c..96219a8 100644
> --- a/kexec/crashdump.h
> +++ b/kexec/crashdump.h
> @@ -55,7 +55,7 @@ int crash_create_elf64_headers(struct kexec_info *info,
>  unsigned long crash_architecture(struct crash_elf_info *elf_info);
>
>  unsigned long phys_to_virt(struct crash_elf_info *elf_info,
> -                          unsigned long paddr);
> +                          unsigned long long paddr);
>
>  unsigned long xen_architecture(struct crash_elf_info *elf_info);
>  int xen_get_nr_phys_cpus(void);
> diff --git a/kexec/phys_to_virt.c b/kexec/phys_to_virt.c
> index 91b6d01..5e8c4e3 100644
> --- a/kexec/phys_to_virt.c
> +++ b/kexec/phys_to_virt.c
> @@ -10,7 +10,7 @@
>   * their own implementation.
>   */
>  unsigned long
> -phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
> +phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
>  {
>         return paddr + elf_info->page_offset;
>  }
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 09/32] kexec: phys_to_virt() must take unsigned long long

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> crashdump-elf.c passes unsigned long long addresses into phys_to_virt()
> so make phys_to_virt() accept such addresses without truncating them.
> This is important for ARM LPAE systems.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/phys_to_virt.c | 2 +-
>  kexec/crashdump.h             | 2 +-
>  kexec/phys_to_virt.c          | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
> index bcced52..c2fe2ea 100644
> --- a/kexec/arch/arm/phys_to_virt.c
> +++ b/kexec/arch/arm/phys_to_virt.c
> @@ -14,7 +14,7 @@
>   * http://lists.arm.linux.org.uk/lurker/message/20010723.185051.94ce743c.en.html
>   */
>  unsigned long
> -phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
> +phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
>  {
>         return paddr + elf_info->page_offset - phys_offset;
>  }
> diff --git a/kexec/crashdump.h b/kexec/crashdump.h
> index 95f1f0c..96219a8 100644
> --- a/kexec/crashdump.h
> +++ b/kexec/crashdump.h
> @@ -55,7 +55,7 @@ int crash_create_elf64_headers(struct kexec_info *info,
>  unsigned long crash_architecture(struct crash_elf_info *elf_info);
>
>  unsigned long phys_to_virt(struct crash_elf_info *elf_info,
> -                          unsigned long paddr);
> +                          unsigned long long paddr);
>
>  unsigned long xen_architecture(struct crash_elf_info *elf_info);
>  int xen_get_nr_phys_cpus(void);
> diff --git a/kexec/phys_to_virt.c b/kexec/phys_to_virt.c
> index 91b6d01..5e8c4e3 100644
> --- a/kexec/phys_to_virt.c
> +++ b/kexec/phys_to_virt.c
> @@ -10,7 +10,7 @@
>   * their own implementation.
>   */
>  unsigned long
> -phys_to_virt(struct crash_elf_info *elf_info, unsigned long paddr)
> +phys_to_virt(struct crash_elf_info *elf_info, unsigned long long paddr)
>  {
>         return paddr + elf_info->page_offset;
>  }
> --
> 1.9.1
>

[PATCH kexec-tools 10/32] kexec: add generic helper to add to memory_regions

[Russell King]

Add a helper to add a memory range to a memory_regions array.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/Makefile      |  4 ++++
 kexec/mem_regions.c | 30 ++++++++++++++++++++++++++++++
 kexec/mem_regions.h |  9 +++++++++
 3 files changed, 43 insertions(+)
 create mode 100644 kexec/mem_regions.c
 create mode 100644 kexec/mem_regions.h

diff --git a/kexec/Makefile b/kexec/Makefile
index a758b4a..e2aee84 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -69,6 +69,10 @@ dist				+= kexec/fs2dt.c kexec/fs2dt.h
 $(ARCH)_FS2DT			=
 KEXEC_SRCS			+= $($(ARCH)_FS2DT)
 
+dist				+= kexec/mem_regions.c kexec/mem_regions.h
+$(ARCH)_MEM_REGIONS		=
+KEXEC_SRCS			+= $($(ARCH)_MEM_REGIONS)
+
 include $(srcdir)/kexec/arch/alpha/Makefile
 include $(srcdir)/kexec/arch/arm/Makefile
 include $(srcdir)/kexec/arch/i386/Makefile
diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
new file mode 100644
index 0000000..a4952ff
--- /dev/null
+++ b/kexec/mem_regions.c
@@ -0,0 +1,30 @@
+#include "kexec.h"
+#include "mem_regions.h"
+
+/**
+ * mem_regions_add() - add a memory region to a set of ranges
+ * @ranges: ranges to add the memory region to
+ * @max: maximum number of entries in memory region
+ * @base: base address of memory region
+ * @length: length of memory region in bytes
+ * @type: type of memory region
+ *
+ * Add the memory region to the set of ranges, and return %0 if successful,
+ * or %-1 if we ran out of space.
+ */
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+                    unsigned long long length, int type)
+{
+	struct memory_range *range;
+
+	if (ranges->size >= ranges->max_size)
+		return -1;
+
+	range = ranges->ranges + ranges->size++;
+	range->start = base;
+	range->end = base + length - 1;
+	range->type = type;
+
+	return 0;
+}
+
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
new file mode 100644
index 0000000..b9cfba1
--- /dev/null
+++ b/kexec/mem_regions.h
@@ -0,0 +1,9 @@
+#ifndef MEM_REGIONS_H
+#define MEM_REGIONS_H
+
+struct memory_ranges;
+
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+                    unsigned long long length, int type);
+
+#endif
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 10/32] kexec: add generic helper to add to memory_regions

[Russell King]

Add a helper to add a memory range to a memory_regions array.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/Makefile      |  4 ++++
 kexec/mem_regions.c | 30 ++++++++++++++++++++++++++++++
 kexec/mem_regions.h |  9 +++++++++
 3 files changed, 43 insertions(+)
 create mode 100644 kexec/mem_regions.c
 create mode 100644 kexec/mem_regions.h

diff --git a/kexec/Makefile b/kexec/Makefile
index a758b4a..e2aee84 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -69,6 +69,10 @@ dist				+= kexec/fs2dt.c kexec/fs2dt.h
 $(ARCH)_FS2DT			=
 KEXEC_SRCS			+= $($(ARCH)_FS2DT)
 
+dist				+= kexec/mem_regions.c kexec/mem_regions.h
+$(ARCH)_MEM_REGIONS		=
+KEXEC_SRCS			+= $($(ARCH)_MEM_REGIONS)
+
 include $(srcdir)/kexec/arch/alpha/Makefile
 include $(srcdir)/kexec/arch/arm/Makefile
 include $(srcdir)/kexec/arch/i386/Makefile
diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
new file mode 100644
index 0000000..a4952ff
--- /dev/null
+++ b/kexec/mem_regions.c
@@ -0,0 +1,30 @@
+#include "kexec.h"
+#include "mem_regions.h"
+
+/**
+ * mem_regions_add() - add a memory region to a set of ranges
+ * @ranges: ranges to add the memory region to
+ * @max: maximum number of entries in memory region
+ * @base: base address of memory region
+ * @length: length of memory region in bytes
+ * @type: type of memory region
+ *
+ * Add the memory region to the set of ranges, and return %0 if successful,
+ * or %-1 if we ran out of space.
+ */
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+                    unsigned long long length, int type)
+{
+	struct memory_range *range;
+
+	if (ranges->size >= ranges->max_size)
+		return -1;
+
+	range = ranges->ranges + ranges->size++;
+	range->start = base;
+	range->end = base + length - 1;
+	range->type = type;
+
+	return 0;
+}
+
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
new file mode 100644
index 0000000..b9cfba1
--- /dev/null
+++ b/kexec/mem_regions.h
@@ -0,0 +1,9 @@
+#ifndef MEM_REGIONS_H
+#define MEM_REGIONS_H
+
+struct memory_ranges;
+
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+                    unsigned long long length, int type);
+
+#endif
-- 
1.9.1

Re: [PATCH kexec-tools 10/32] kexec: add generic helper to add to memory_regions

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add a helper to add a memory range to a memory_regions array.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/Makefile      |  4 ++++
>  kexec/mem_regions.c | 30 ++++++++++++++++++++++++++++++
>  kexec/mem_regions.h |  9 +++++++++
>  3 files changed, 43 insertions(+)
>  create mode 100644 kexec/mem_regions.c
>  create mode 100644 kexec/mem_regions.h
>
> diff --git a/kexec/Makefile b/kexec/Makefile
> index a758b4a..e2aee84 100644
> --- a/kexec/Makefile
> +++ b/kexec/Makefile
> @@ -69,6 +69,10 @@ dist                         += kexec/fs2dt.c kexec/fs2dt.h
>  $(ARCH)_FS2DT                  =
>  KEXEC_SRCS                     += $($(ARCH)_FS2DT)
>
> +dist                           += kexec/mem_regions.c kexec/mem_regions.h
> +$(ARCH)_MEM_REGIONS            =
> +KEXEC_SRCS                     += $($(ARCH)_MEM_REGIONS)
> +
>  include $(srcdir)/kexec/arch/alpha/Makefile
>  include $(srcdir)/kexec/arch/arm/Makefile
>  include $(srcdir)/kexec/arch/i386/Makefile
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> new file mode 100644
> index 0000000..a4952ff
> --- /dev/null
> +++ b/kexec/mem_regions.c
> @@ -0,0 +1,30 @@
> +#include "kexec.h"
> +#include "mem_regions.h"
> +
> +/**
> + * mem_regions_add() - add a memory region to a set of ranges
> + * @ranges: ranges to add the memory region to
> + * @max: maximum number of entries in memory region
> + * @base: base address of memory region
> + * @length: length of memory region in bytes
> + * @type: type of memory region
> + *
> + * Add the memory region to the set of ranges, and return %0 if successful,
> + * or %-1 if we ran out of space.
> + */
> +int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> +                    unsigned long long length, int type)
> +{
> +       struct memory_range *range;
> +
> +       if (ranges->size >= ranges->max_size)
> +               return -1;
> +
> +       range = ranges->ranges + ranges->size++;
> +       range->start = base;
> +       range->end = base + length - 1;
> +       range->type = type;
> +
> +       return 0;
> +}
> +
> diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
> new file mode 100644
> index 0000000..b9cfba1
> --- /dev/null
> +++ b/kexec/mem_regions.h
> @@ -0,0 +1,9 @@
> +#ifndef MEM_REGIONS_H
> +#define MEM_REGIONS_H
> +
> +struct memory_ranges;
> +
> +int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> +                    unsigned long long length, int type);
> +
> +#endif
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 10/32] kexec: add generic helper to add to memory_regions

[Pratyush Anand]

On Tue, May 3, 2016 at 3:51 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add a helper to add a memory range to a memory_regions array.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/Makefile      |  4 ++++
>  kexec/mem_regions.c | 30 ++++++++++++++++++++++++++++++
>  kexec/mem_regions.h |  9 +++++++++
>  3 files changed, 43 insertions(+)
>  create mode 100644 kexec/mem_regions.c
>  create mode 100644 kexec/mem_regions.h
>
> diff --git a/kexec/Makefile b/kexec/Makefile
> index a758b4a..e2aee84 100644
> --- a/kexec/Makefile
> +++ b/kexec/Makefile
> @@ -69,6 +69,10 @@ dist                         += kexec/fs2dt.c kexec/fs2dt.h
>  $(ARCH)_FS2DT                  =
>  KEXEC_SRCS                     += $($(ARCH)_FS2DT)
>
> +dist                           += kexec/mem_regions.c kexec/mem_regions.h
> +$(ARCH)_MEM_REGIONS            =
> +KEXEC_SRCS                     += $($(ARCH)_MEM_REGIONS)
> +
>  include $(srcdir)/kexec/arch/alpha/Makefile
>  include $(srcdir)/kexec/arch/arm/Makefile
>  include $(srcdir)/kexec/arch/i386/Makefile
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> new file mode 100644
> index 0000000..a4952ff
> --- /dev/null
> +++ b/kexec/mem_regions.c
> @@ -0,0 +1,30 @@
> +#include "kexec.h"
> +#include "mem_regions.h"
> +
> +/**
> + * mem_regions_add() - add a memory region to a set of ranges
> + * @ranges: ranges to add the memory region to
> + * @max: maximum number of entries in memory region
> + * @base: base address of memory region
> + * @length: length of memory region in bytes
> + * @type: type of memory region
> + *
> + * Add the memory region to the set of ranges, and return %0 if successful,
> + * or %-1 if we ran out of space.
> + */
> +int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> +                    unsigned long long length, int type)
> +{
> +       struct memory_range *range;
> +
> +       if (ranges->size >= ranges->max_size)
> +               return -1;
> +
> +       range = ranges->ranges + ranges->size++;
> +       range->start = base;
> +       range->end = base + length - 1;
> +       range->type = type;
> +
> +       return 0;
> +}
> +
> diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
> new file mode 100644
> index 0000000..b9cfba1
> --- /dev/null
> +++ b/kexec/mem_regions.h
> @@ -0,0 +1,9 @@
> +#ifndef MEM_REGIONS_H
> +#define MEM_REGIONS_H
> +
> +struct memory_ranges;
> +
> +int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> +                    unsigned long long length, int type);
> +
> +#endif
> --
> 1.9.1
>

[PATCH kexec-tools 11/32] kexec: add mem_regions sorting implementation

[Russell King]

Add a mem_regions sorting implementation taken from the arm code.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/mem_regions.c | 27 +++++++++++++++++++++++++++
 kexec/mem_regions.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index a4952ff..804984a 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -1,6 +1,33 @@
+#include <stdlib.h>
+
 #include "kexec.h"
 #include "mem_regions.h"
 
+static int mem_range_cmp(const void *a1, const void *a2)
+{
+	const struct memory_range *r1 = a1;
+	const struct memory_range *r2 = a2;
+
+	if (r1->start > r2->start)
+		return 1;
+	if (r1->start < r2->start)
+		return -1;
+
+	return 0;
+}
+
+/**
+ * mem_regions_sort() - sort ranges into ascending address order
+ * @ranges: ranges to sort
+ *
+ * Sort the memory regions into ascending address order.
+ */
+void mem_regions_sort(struct memory_ranges *ranges)
+{
+	qsort(ranges->ranges, ranges->size, sizeof(ranges->ranges),
+	      mem_range_cmp);
+}
+
 /**
  * mem_regions_add() - add a memory region to a set of ranges
  * @ranges: ranges to add the memory region to
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
index b9cfba1..da7b5e8 100644
--- a/kexec/mem_regions.h
+++ b/kexec/mem_regions.h
@@ -3,6 +3,8 @@
 
 struct memory_ranges;
 
+void mem_regions_sort(struct memory_ranges *ranges);
+
 int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
                     unsigned long long length, int type);
 
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 11/32] kexec: add mem_regions sorting implementation

[Russell King]

Add a mem_regions sorting implementation taken from the arm code.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/mem_regions.c | 27 +++++++++++++++++++++++++++
 kexec/mem_regions.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index a4952ff..804984a 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -1,6 +1,33 @@
+#include <stdlib.h>
+
 #include "kexec.h"
 #include "mem_regions.h"
 
+static int mem_range_cmp(const void *a1, const void *a2)
+{
+	const struct memory_range *r1 = a1;
+	const struct memory_range *r2 = a2;
+
+	if (r1->start > r2->start)
+		return 1;
+	if (r1->start < r2->start)
+		return -1;
+
+	return 0;
+}
+
+/**
+ * mem_regions_sort() - sort ranges into ascending address order
+ * @ranges: ranges to sort
+ *
+ * Sort the memory regions into ascending address order.
+ */
+void mem_regions_sort(struct memory_ranges *ranges)
+{
+	qsort(ranges->ranges, ranges->size, sizeof(ranges->ranges),
+	      mem_range_cmp);
+}
+
 /**
  * mem_regions_add() - add a memory region to a set of ranges
  * @ranges: ranges to add the memory region to
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
index b9cfba1..da7b5e8 100644
--- a/kexec/mem_regions.h
+++ b/kexec/mem_regions.h
@@ -3,6 +3,8 @@
 
 struct memory_ranges;
 
+void mem_regions_sort(struct memory_ranges *ranges);
+
 int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
                     unsigned long long length, int type);
 
-- 
1.9.1

Re: [PATCH kexec-tools 11/32] kexec: add mem_regions sorting implementation

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add a mem_regions sorting implementation taken from the arm code.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/mem_regions.c | 27 +++++++++++++++++++++++++++
>  kexec/mem_regions.h |  2 ++
>  2 files changed, 29 insertions(+)
>
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> index a4952ff..804984a 100644
> --- a/kexec/mem_regions.c
> +++ b/kexec/mem_regions.c
> @@ -1,6 +1,33 @@
> +#include <stdlib.h>
> +
>  #include "kexec.h"
>  #include "mem_regions.h"
>
> +static int mem_range_cmp(const void *a1, const void *a2)
> +{
> +       const struct memory_range *r1 = a1;
> +       const struct memory_range *r2 = a2;
> +
> +       if (r1->start > r2->start)
> +               return 1;
> +       if (r1->start < r2->start)
> +               return -1;
> +
> +       return 0;
> +}
> +
> +/**
> + * mem_regions_sort() - sort ranges into ascending address order
> + * @ranges: ranges to sort
> + *
> + * Sort the memory regions into ascending address order.
> + */
> +void mem_regions_sort(struct memory_ranges *ranges)
> +{
> +       qsort(ranges->ranges, ranges->size, sizeof(ranges->ranges),
> +             mem_range_cmp);
> +}
> +
>  /**
>   * mem_regions_add() - add a memory region to a set of ranges
>   * @ranges: ranges to add the memory region to
> diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
> index b9cfba1..da7b5e8 100644
> --- a/kexec/mem_regions.h
> +++ b/kexec/mem_regions.h
> @@ -3,6 +3,8 @@
>
>  struct memory_ranges;
>
> +void mem_regions_sort(struct memory_ranges *ranges);
> +
>  int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
>                      unsigned long long length, int type);
>
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 11/32] kexec: add mem_regions sorting implementation

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add a mem_regions sorting implementation taken from the arm code.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/mem_regions.c | 27 +++++++++++++++++++++++++++
>  kexec/mem_regions.h |  2 ++
>  2 files changed, 29 insertions(+)
>
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> index a4952ff..804984a 100644
> --- a/kexec/mem_regions.c
> +++ b/kexec/mem_regions.c
> @@ -1,6 +1,33 @@
> +#include <stdlib.h>
> +
>  #include "kexec.h"
>  #include "mem_regions.h"
>
> +static int mem_range_cmp(const void *a1, const void *a2)
> +{
> +       const struct memory_range *r1 = a1;
> +       const struct memory_range *r2 = a2;
> +
> +       if (r1->start > r2->start)
> +               return 1;
> +       if (r1->start < r2->start)
> +               return -1;
> +
> +       return 0;
> +}
> +
> +/**
> + * mem_regions_sort() - sort ranges into ascending address order
> + * @ranges: ranges to sort
> + *
> + * Sort the memory regions into ascending address order.
> + */
> +void mem_regions_sort(struct memory_ranges *ranges)
> +{
> +       qsort(ranges->ranges, ranges->size, sizeof(ranges->ranges),
> +             mem_range_cmp);
> +}
> +
>  /**
>   * mem_regions_add() - add a memory region to a set of ranges
>   * @ranges: ranges to add the memory region to
> diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
> index b9cfba1..da7b5e8 100644
> --- a/kexec/mem_regions.h
> +++ b/kexec/mem_regions.h
> @@ -3,6 +3,8 @@
>
>  struct memory_ranges;
>
> +void mem_regions_sort(struct memory_ranges *ranges);
> +
>  int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
>                      unsigned long long length, int type);
>
> --
> 1.9.1
>

[PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Russell King]

Add a helper to exclude a region from a set of memory ranges.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/mem_regions.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 kexec/mem_regions.h |  4 ++++
 2 files changed, 59 insertions(+)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index 804984a..c6ba942 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -29,6 +29,61 @@ void mem_regions_sort(struct memory_ranges *ranges)
 }
 
 /**
+ * mem_regions_exclude() - excludes a memory region from a set of memory ranges
+ * @ranges: memory ranges to exclude the region from
+ * @range: memory range to exclude
+ *
+ * Exclude a memory region from a set of memory ranges.  We assume that
+ * the region to be excluded is either wholely located within one of the
+ * memory ranges, or not at all.
+ */
+int mem_regions_exclude(struct memory_ranges *ranges,
+			const struct memory_range *range)
+{
+	int i;
+
+	for (i = 0; i < ranges->size; i++) {
+		struct memory_range *r = ranges->ranges + i;
+
+		/*
+		 * We assume that crash area is fully contained in
+		 * some larger memory area.
+		 */
+		if (r->start <= range->start && r->end >= range->end) {
+			if (r->start == range->start) {
+				/* Shrink the start of this memory range */
+				r->start = range->end + 1;
+			} else if (r->end == range->end) {
+				/* Shrink the end of this memory range */
+				r->end = range->start - 1;
+			} else {
+				struct memory_range *new;
+
+				/*
+				 * Split this area into 2 smaller ones and
+				 * remove excluded range from between. First
+				 * create new entry for the remaining area.
+				 */
+				if (ranges->size >= ranges->max_size)
+					return -1;
+
+				new = ranges->ranges + ranges->size++;
+				new->start = range->end + 1;
+				new->end = r->end;
+
+				/*
+				 * Update this area to end before excluded
+				 * range.
+				 */
+				r->end = range->start - 1;
+				break;
+			}
+		}
+	}
+	return 0;
+}
+
+/**
  * mem_regions_add() - add a memory region to a set of ranges
  * @ranges: ranges to add the memory region to
  * @max: maximum number of entries in memory region
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
index da7b5e8..ae9e972 100644
--- a/kexec/mem_regions.h
+++ b/kexec/mem_regions.h
@@ -2,9 +2,13 @@
 #define MEM_REGIONS_H
 
 struct memory_ranges;
+struct memory_range;
 
 void mem_regions_sort(struct memory_ranges *ranges);
 
+int mem_regions_exclude(struct memory_ranges *ranges,
+			const struct memory_range *range);
+
 int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
                     unsigned long long length, int type);
 
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Russell King]

Add a helper to exclude a region from a set of memory ranges.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/mem_regions.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 kexec/mem_regions.h |  4 ++++
 2 files changed, 59 insertions(+)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index 804984a..c6ba942 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -29,6 +29,61 @@ void mem_regions_sort(struct memory_ranges *ranges)
 }
 
 /**
+ * mem_regions_exclude() - excludes a memory region from a set of memory ranges
+ * @ranges: memory ranges to exclude the region from
+ * @range: memory range to exclude
+ *
+ * Exclude a memory region from a set of memory ranges.  We assume that
+ * the region to be excluded is either wholely located within one of the
+ * memory ranges, or not at all.
+ */
+int mem_regions_exclude(struct memory_ranges *ranges,
+			const struct memory_range *range)
+{
+	int i;
+
+	for (i = 0; i < ranges->size; i++) {
+		struct memory_range *r = ranges->ranges + i;
+
+		/*
+		 * We assume that crash area is fully contained in
+		 * some larger memory area.
+		 */
+		if (r->start <= range->start && r->end >= range->end) {
+			if (r->start == range->start) {
+				/* Shrink the start of this memory range */
+				r->start = range->end + 1;
+			} else if (r->end == range->end) {
+				/* Shrink the end of this memory range */
+				r->end = range->start - 1;
+			} else {
+				struct memory_range *new;
+
+				/*
+				 * Split this area into 2 smaller ones and
+				 * remove excluded range from between. First
+				 * create new entry for the remaining area.
+				 */
+				if (ranges->size >= ranges->max_size)
+					return -1;
+
+				new = ranges->ranges + ranges->size++;
+				new->start = range->end + 1;
+				new->end = r->end;
+
+				/*
+				 * Update this area to end before excluded
+				 * range.
+				 */
+				r->end = range->start - 1;
+				break;
+			}
+		}
+	}
+	return 0;
+}
+
+/**
  * mem_regions_add() - add a memory region to a set of ranges
  * @ranges: ranges to add the memory region to
  * @max: maximum number of entries in memory region
diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
index da7b5e8..ae9e972 100644
--- a/kexec/mem_regions.h
+++ b/kexec/mem_regions.h
@@ -2,9 +2,13 @@
 #define MEM_REGIONS_H
 
 struct memory_ranges;
+struct memory_range;
 
 void mem_regions_sort(struct memory_ranges *ranges);
 
+int mem_regions_exclude(struct memory_ranges *ranges,
+			const struct memory_range *range);
+
 int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
                     unsigned long long length, int type);
 
-- 
1.9.1

Re: [PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add a helper to exclude a region from a set of memory ranges.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/mem_regions.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  kexec/mem_regions.h |  4 ++++
>  2 files changed, 59 insertions(+)
>
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> index 804984a..c6ba942 100644
> --- a/kexec/mem_regions.c
> +++ b/kexec/mem_regions.c
> @@ -29,6 +29,61 @@ void mem_regions_sort(struct memory_ranges *ranges)
>  }
>
>  /**
> + * mem_regions_exclude() - excludes a memory region from a set of memory ranges
> + * @ranges: memory ranges to exclude the region from
> + * @range: memory range to exclude
> + *
> + * Exclude a memory region from a set of memory ranges.  We assume that
> + * the region to be excluded is either wholely located within one of the
> + * memory ranges, or not at all.
> + */
> +int mem_regions_exclude(struct memory_ranges *ranges,
> +                       const struct memory_range *range)
> +{
> +       int i;
> +
> +       for (i = 0; i < ranges->size; i++) {
> +               struct memory_range *r = ranges->ranges + i;
> +
> +               /*
> +                * We assume that crash area is fully contained in
> +                * some larger memory area.
> +                */
> +               if (r->start <= range->start && r->end >= range->end) {
> +                       if (r->start == range->start) {
> +                               /* Shrink the start of this memory range */
> +                               r->start = range->end + 1;
> +                       } else if (r->end == range->end) {
> +                               /* Shrink the end of this memory range */
> +                               r->end = range->start - 1;

What if r->start == range->start) && (r->end == range->end)?

> +                       } else {
> +                               struct memory_range *new;
> +
> +                               /*
> +                                * Split this area into 2 smaller ones and
> +                                * remove excluded range from between. First
> +                                * create new entry for the remaining area.
> +                                */
> +                               if (ranges->size >= ranges->max_size)
> +                                       return -1;
> +
> +                               new = ranges->ranges + ranges->size++;
> +                               new->start = range->end + 1;
> +                               new->end = r->end;
> +
> +                               /*
> +                                * Update this area to end before excluded
> +                                * range.
> +                                */
> +                               r->end = range->start - 1;
> +                               break;
> +                       }
> +               }
> +       }
> +       return 0;
> +}
> +
> +/**
>   * mem_regions_add() - add a memory region to a set of ranges
>   * @ranges: ranges to add the memory region to
>   * @max: maximum number of entries in memory region
> diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
> index da7b5e8..ae9e972 100644
> --- a/kexec/mem_regions.h
> +++ b/kexec/mem_regions.h
> @@ -2,9 +2,13 @@
>  #define MEM_REGIONS_H
>
>  struct memory_ranges;
> +struct memory_range;
>
>  void mem_regions_sort(struct memory_ranges *ranges);
>
> +int mem_regions_exclude(struct memory_ranges *ranges,
> +                       const struct memory_range *range);
> +
>  int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
>                      unsigned long long length, int type);
>
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add a helper to exclude a region from a set of memory ranges.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/mem_regions.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  kexec/mem_regions.h |  4 ++++
>  2 files changed, 59 insertions(+)
>
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> index 804984a..c6ba942 100644
> --- a/kexec/mem_regions.c
> +++ b/kexec/mem_regions.c
> @@ -29,6 +29,61 @@ void mem_regions_sort(struct memory_ranges *ranges)
>  }
>
>  /**
> + * mem_regions_exclude() - excludes a memory region from a set of memory ranges
> + * @ranges: memory ranges to exclude the region from
> + * @range: memory range to exclude
> + *
> + * Exclude a memory region from a set of memory ranges.  We assume that
> + * the region to be excluded is either wholely located within one of the
> + * memory ranges, or not at all.
> + */
> +int mem_regions_exclude(struct memory_ranges *ranges,
> +                       const struct memory_range *range)
> +{
> +       int i;
> +
> +       for (i = 0; i < ranges->size; i++) {
> +               struct memory_range *r = ranges->ranges + i;
> +
> +               /*
> +                * We assume that crash area is fully contained in
> +                * some larger memory area.
> +                */
> +               if (r->start <= range->start && r->end >= range->end) {
> +                       if (r->start == range->start) {
> +                               /* Shrink the start of this memory range */
> +                               r->start = range->end + 1;
> +                       } else if (r->end == range->end) {
> +                               /* Shrink the end of this memory range */
> +                               r->end = range->start - 1;

What if r->start == range->start) && (r->end == range->end)?

> +                       } else {
> +                               struct memory_range *new;
> +
> +                               /*
> +                                * Split this area into 2 smaller ones and
> +                                * remove excluded range from between. First
> +                                * create new entry for the remaining area.
> +                                */
> +                               if (ranges->size >= ranges->max_size)
> +                                       return -1;
> +
> +                               new = ranges->ranges + ranges->size++;
> +                               new->start = range->end + 1;
> +                               new->end = r->end;
> +
> +                               /*
> +                                * Update this area to end before excluded
> +                                * range.
> +                                */
> +                               r->end = range->start - 1;
> +                               break;
> +                       }
> +               }
> +       }
> +       return 0;
> +}
> +
> +/**
>   * mem_regions_add() - add a memory region to a set of ranges
>   * @ranges: ranges to add the memory region to
>   * @max: maximum number of entries in memory region
> diff --git a/kexec/mem_regions.h b/kexec/mem_regions.h
> index da7b5e8..ae9e972 100644
> --- a/kexec/mem_regions.h
> +++ b/kexec/mem_regions.h
> @@ -2,9 +2,13 @@
>  #define MEM_REGIONS_H
>
>  struct memory_ranges;
> +struct memory_range;
>
>  void mem_regions_sort(struct memory_ranges *ranges);
>
> +int mem_regions_exclude(struct memory_ranges *ranges,
> +                       const struct memory_range *range);
> +
>  int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
>                      unsigned long long length, int type);
>
> --
> 1.9.1
>

Re: [PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Russell King - ARM Linux]

On Wed, May 25, 2016 at 01:30:44PM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > +int mem_regions_exclude(struct memory_ranges *ranges,
> > +                       const struct memory_range *range)
> > +{
> > +       int i;
> > +
> > +       for (i = 0; i < ranges->size; i++) {
> > +               struct memory_range *r = ranges->ranges + i;
> > +
> > +               /*
> > +                * We assume that crash area is fully contained in
> > +                * some larger memory area.
> > +                */
> > +               if (r->start <= range->start && r->end >= range->end) {
> > +                       if (r->start == range->start) {
> > +                               /* Shrink the start of this memory range */
> > +                               r->start = range->end + 1;
> > +                       } else if (r->end == range->end) {
> > +                               /* Shrink the end of this memory range */
> > +                               r->end = range->start - 1;
> 
> What if r->start == range->start) && (r->end == range->end)?

I suppose that could happen, so what about this patch on top (untested).
This isn't something I'd be able to test on real hardware, it needs a
separate test-suite to be written to do modular testing...

 kexec/mem_regions.c | 94 +++++++++++++++++++++++++++++++----------------------
 1 file changed, 55 insertions(+), 39 deletions(-)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index c6ba942..4e7061b 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -29,6 +29,50 @@ void mem_regions_sort(struct memory_ranges *ranges)
 }
 
 /**
+ * mem_regions_add() - add a memory region to a set of ranges
+ * @ranges: ranges to add the memory region to
+ * @max: maximum number of entries in memory region
+ * @base: base address of memory region
+ * @length: length of memory region in bytes
+ * @type: type of memory region
+ *
+ * Add the memory region to the set of ranges, and return %0 if successful,
+ * or %-1 if we ran out of space.
+ */
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+                    unsigned long long length, int type)
+{
+	struct memory_range *range;
+
+	if (ranges->size >= ranges->max_size)
+		return -1;
+
+	range = ranges->ranges + ranges->size++;
+	range->start = base;
+	range->end = base + length - 1;
+	range->type = type;
+
+	return 0;
+}
+
+static void mem_regions_remove(struct memory_ranges *ranges, int index)
+{
+	int tail_entries;
+
+	/* we are assured to have at least one entry */
+	ranges->size -= 1;
+
+	/* if we have following entries, shuffle them down one place */
+	tail_entries = ranges->size - index;
+	if (tail_entries)
+		memmove(ranges->ranges + index, ranges->ranges + index + 1,
+			tail_entries * sizeof(*ranges->ranges));
+
+	/* zero the new tail entry */
+	memset(ranges->ranges + ranges->size, 0, sizeof(*ranges->ranges));
+}
+
+/**
  * mem_regions_exclude() - excludes a memory region from a set of memory ranges
  * @ranges: memory ranges to exclude the region from
  * @range: memory range to exclude
@@ -40,7 +84,7 @@ void mem_regions_sort(struct memory_ranges *ranges)
 int mem_regions_exclude(struct memory_ranges *ranges,
 			const struct memory_range *range)
 {
-	int i;
+	int i, ret;
 
 	for (i = 0; i < ranges->size; i++) {
 		struct memory_range *r = ranges->ranges + i;
@@ -51,25 +95,25 @@ int mem_regions_exclude(struct memory_ranges *ranges,
 		 */
 		if (r->start <= range->start && r->end >= range->end) {
 			if (r->start == range->start) {
-				/* Shrink the start of this memory range */
-				r->start = range->end + 1;
+				if (r->end == range->end)
+					/* Remove this entry */
+					mem_regions_remove(ranges, i);
+				else
+					/* Shrink the start of this memory range */
+					r->start = range->end + 1;
 			} else if (r->end == range->end) {
 				/* Shrink the end of this memory range */
 				r->end = range->start - 1;
 			} else {
-				struct memory_range *new;
-
 				/*
 				 * Split this area into 2 smaller ones and
 				 * remove excluded range from between. First
 				 * create new entry for the remaining area.
 				 */
-				if (ranges->size >= ranges->max_size)
-					return -1;
-
-				new = ranges->ranges + ranges->size++;
-				new->start = range->end + 1;
-				new->end = r->end;
+				ret = mem_regions_add(ranges, range->end + 1,
+						      r->end, 0);
+				if (ret < 0)
+					return ret;
 
 				/*
 				 * Update this area to end before excluded
@@ -82,31 +126,3 @@ int mem_regions_exclude(struct memory_ranges *ranges,
 	}
 	return 0;
 }
-
-/**
- * mem_regions_add() - add a memory region to a set of ranges
- * @ranges: ranges to add the memory region to
- * @max: maximum number of entries in memory region
- * @base: base address of memory region
- * @length: length of memory region in bytes
- * @type: type of memory region
- *
- * Add the memory region to the set of ranges, and return %0 if successful,
- * or %-1 if we ran out of space.
- */
-int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
-                    unsigned long long length, int type)
-{
-	struct memory_range *range;
-
-	if (ranges->size >= ranges->max_size)
-		return -1;
-
-	range = ranges->ranges + ranges->size++;
-	range->start = base;
-	range->end = base + length - 1;
-	range->type = type;
-
-	return 0;
-}
-


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Russell King - ARM Linux]

On Wed, May 25, 2016 at 01:30:44PM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > +int mem_regions_exclude(struct memory_ranges *ranges,
> > +                       const struct memory_range *range)
> > +{
> > +       int i;
> > +
> > +       for (i = 0; i < ranges->size; i++) {
> > +               struct memory_range *r = ranges->ranges + i;
> > +
> > +               /*
> > +                * We assume that crash area is fully contained in
> > +                * some larger memory area.
> > +                */
> > +               if (r->start <= range->start && r->end >= range->end) {
> > +                       if (r->start == range->start) {
> > +                               /* Shrink the start of this memory range */
> > +                               r->start = range->end + 1;
> > +                       } else if (r->end == range->end) {
> > +                               /* Shrink the end of this memory range */
> > +                               r->end = range->start - 1;
> 
> What if r->start == range->start) && (r->end == range->end)?

I suppose that could happen, so what about this patch on top (untested).
This isn't something I'd be able to test on real hardware, it needs a
separate test-suite to be written to do modular testing...

 kexec/mem_regions.c | 94 +++++++++++++++++++++++++++++++----------------------
 1 file changed, 55 insertions(+), 39 deletions(-)

diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
index c6ba942..4e7061b 100644
--- a/kexec/mem_regions.c
+++ b/kexec/mem_regions.c
@@ -29,6 +29,50 @@ void mem_regions_sort(struct memory_ranges *ranges)
 }
 
 /**
+ * mem_regions_add() - add a memory region to a set of ranges
+ * @ranges: ranges to add the memory region to
+ * @max: maximum number of entries in memory region
+ * @base: base address of memory region
+ * @length: length of memory region in bytes
+ * @type: type of memory region
+ *
+ * Add the memory region to the set of ranges, and return %0 if successful,
+ * or %-1 if we ran out of space.
+ */
+int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
+                    unsigned long long length, int type)
+{
+	struct memory_range *range;
+
+	if (ranges->size >= ranges->max_size)
+		return -1;
+
+	range = ranges->ranges + ranges->size++;
+	range->start = base;
+	range->end = base + length - 1;
+	range->type = type;
+
+	return 0;
+}
+
+static void mem_regions_remove(struct memory_ranges *ranges, int index)
+{
+	int tail_entries;
+
+	/* we are assured to have at least one entry */
+	ranges->size -= 1;
+
+	/* if we have following entries, shuffle them down one place */
+	tail_entries = ranges->size - index;
+	if (tail_entries)
+		memmove(ranges->ranges + index, ranges->ranges + index + 1,
+			tail_entries * sizeof(*ranges->ranges));
+
+	/* zero the new tail entry */
+	memset(ranges->ranges + ranges->size, 0, sizeof(*ranges->ranges));
+}
+
+/**
  * mem_regions_exclude() - excludes a memory region from a set of memory ranges
  * @ranges: memory ranges to exclude the region from
  * @range: memory range to exclude
@@ -40,7 +84,7 @@ void mem_regions_sort(struct memory_ranges *ranges)
 int mem_regions_exclude(struct memory_ranges *ranges,
 			const struct memory_range *range)
 {
-	int i;
+	int i, ret;
 
 	for (i = 0; i < ranges->size; i++) {
 		struct memory_range *r = ranges->ranges + i;
@@ -51,25 +95,25 @@ int mem_regions_exclude(struct memory_ranges *ranges,
 		 */
 		if (r->start <= range->start && r->end >= range->end) {
 			if (r->start == range->start) {
-				/* Shrink the start of this memory range */
-				r->start = range->end + 1;
+				if (r->end == range->end)
+					/* Remove this entry */
+					mem_regions_remove(ranges, i);
+				else
+					/* Shrink the start of this memory range */
+					r->start = range->end + 1;
 			} else if (r->end == range->end) {
 				/* Shrink the end of this memory range */
 				r->end = range->start - 1;
 			} else {
-				struct memory_range *new;
-
 				/*
 				 * Split this area into 2 smaller ones and
 				 * remove excluded range from between. First
 				 * create new entry for the remaining area.
 				 */
-				if (ranges->size >= ranges->max_size)
-					return -1;
-
-				new = ranges->ranges + ranges->size++;
-				new->start = range->end + 1;
-				new->end = r->end;
+				ret = mem_regions_add(ranges, range->end + 1,
+						      r->end, 0);
+				if (ret < 0)
+					return ret;
 
 				/*
 				 * Update this area to end before excluded
@@ -82,31 +126,3 @@ int mem_regions_exclude(struct memory_ranges *ranges,
 	}
 	return 0;
 }
-
-/**
- * mem_regions_add() - add a memory region to a set of ranges
- * @ranges: ranges to add the memory region to
- * @max: maximum number of entries in memory region
- * @base: base address of memory region
- * @length: length of memory region in bytes
- * @type: type of memory region
- *
- * Add the memory region to the set of ranges, and return %0 if successful,
- * or %-1 if we ran out of space.
- */
-int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
-                    unsigned long long length, int type)
-{
-	struct memory_range *range;
-
-	if (ranges->size >= ranges->max_size)
-		return -1;
-
-	range = ranges->ranges + ranges->size++;
-	range->start = base;
-	range->end = base + length - 1;
-	range->type = type;
-
-	return 0;
-}
-


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Pratyush Anand]

On Thu, May 26, 2016 at 2:26 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, May 25, 2016 at 01:30:44PM +0530, Pratyush Anand wrote:
>> On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
>> > +int mem_regions_exclude(struct memory_ranges *ranges,
>> > +                       const struct memory_range *range)
>> > +{
>> > +       int i;
>> > +
>> > +       for (i = 0; i < ranges->size; i++) {
>> > +               struct memory_range *r = ranges->ranges + i;
>> > +
>> > +               /*
>> > +                * We assume that crash area is fully contained in
>> > +                * some larger memory area.
>> > +                */
>> > +               if (r->start <= range->start && r->end >= range->end) {
>> > +                       if (r->start == range->start) {
>> > +                               /* Shrink the start of this memory range */
>> > +                               r->start = range->end + 1;
>> > +                       } else if (r->end == range->end) {
>> > +                               /* Shrink the end of this memory range */
>> > +                               r->end = range->start - 1;
>>
>> What if r->start == range->start) && (r->end == range->end)?
>
> I suppose that could happen, so what about this patch on top (untested).

I think, it should be fine, except.....

> This isn't something I'd be able to test on real hardware, it needs a
> separate test-suite to be written to do modular testing...
>
>  kexec/mem_regions.c | 94 +++++++++++++++++++++++++++++++----------------------
>  1 file changed, 55 insertions(+), 39 deletions(-)
>
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> index c6ba942..4e7061b 100644
> --- a/kexec/mem_regions.c
> +++ b/kexec/mem_regions.c
> @@ -29,6 +29,50 @@ void mem_regions_sort(struct memory_ranges *ranges)
>  }
>
>  /**
> + * mem_regions_add() - add a memory region to a set of ranges
> + * @ranges: ranges to add the memory region to
> + * @max: maximum number of entries in memory region
> + * @base: base address of memory region
> + * @length: length of memory region in bytes
> + * @type: type of memory region
> + *
> + * Add the memory region to the set of ranges, and return %0 if successful,
> + * or %-1 if we ran out of space.
> + */
> +int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> +                    unsigned long long length, int type)
> +{
> +       struct memory_range *range;
> +
> +       if (ranges->size >= ranges->max_size)
> +               return -1;
> +
> +       range = ranges->ranges + ranges->size++;
> +       range->start = base;
> +       range->end = base + length - 1;
> +       range->type = type;
> +
> +       return 0;
> +}
> +
> +static void mem_regions_remove(struct memory_ranges *ranges, int index)
> +{
> +       int tail_entries;
> +
> +       /* we are assured to have at least one entry */
> +       ranges->size -= 1;
> +
> +       /* if we have following entries, shuffle them down one place */
> +       tail_entries = ranges->size - index;
> +       if (tail_entries)
> +               memmove(ranges->ranges + index, ranges->ranges + index + 1,
> +                       tail_entries * sizeof(*ranges->ranges));
> +
> +       /* zero the new tail entry */
> +       memset(ranges->ranges + ranges->size, 0, sizeof(*ranges->ranges));
> +}
> +
> +/**
>   * mem_regions_exclude() - excludes a memory region from a set of memory ranges
>   * @ranges: memory ranges to exclude the region from
>   * @range: memory range to exclude
> @@ -40,7 +84,7 @@ void mem_regions_sort(struct memory_ranges *ranges)
>  int mem_regions_exclude(struct memory_ranges *ranges,
>                         const struct memory_range *range)
>  {
> -       int i;
> +       int i, ret;
>
>         for (i = 0; i < ranges->size; i++) {
>                 struct memory_range *r = ranges->ranges + i;
> @@ -51,25 +95,25 @@ int mem_regions_exclude(struct memory_ranges *ranges,
>                  */
>                 if (r->start <= range->start && r->end >= range->end) {
>                         if (r->start == range->start) {
> -                               /* Shrink the start of this memory range */
> -                               r->start = range->end + 1;
> +                               if (r->end == range->end)
> +                                       /* Remove this entry */
> +                                       mem_regions_remove(ranges, i);
> +                               else
> +                                       /* Shrink the start of this memory range */
> +                                       r->start = range->end + 1;
>                         } else if (r->end == range->end) {
>                                 /* Shrink the end of this memory range */
>                                 r->end = range->start - 1;
>                         } else {
> -                               struct memory_range *new;
> -
>                                 /*
>                                  * Split this area into 2 smaller ones and
>                                  * remove excluded range from between. First
>                                  * create new entry for the remaining area.
>                                  */
> -                               if (ranges->size >= ranges->max_size)
> -                                       return -1;
> -
> -                               new = ranges->ranges + ranges->size++;
> -                               new->start = range->end + 1;
> -                               new->end = r->end;
> +                               ret = mem_regions_add(ranges, range->end + 1,
> +                                                     r->end, 0);

3rd argument should be (r->end - range->end)

> +                               if (ret < 0)
> +                                       return ret;
>
>                                 /*
>                                  * Update this area to end before excluded
> @@ -82,31 +126,3 @@ int mem_regions_exclude(struct memory_ranges *ranges,
>         }
>         return 0;
>  }
> -
> -/**
> - * mem_regions_add() - add a memory region to a set of ranges
> - * @ranges: ranges to add the memory region to
> - * @max: maximum number of entries in memory region
> - * @base: base address of memory region
> - * @length: length of memory region in bytes
> - * @type: type of memory region
> - *
> - * Add the memory region to the set of ranges, and return %0 if successful,
> - * or %-1 if we ran out of space.
> - */
> -int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> -                    unsigned long long length, int type)
> -{
> -       struct memory_range *range;
> -
> -       if (ranges->size >= ranges->max_size)
> -               return -1;
> -
> -       range = ranges->ranges + ranges->size++;
> -       range->start = base;
> -       range->end = base + length - 1;
> -       range->type = type;
> -
> -       return 0;
> -}
> -
>
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Pratyush Anand]

On Thu, May 26, 2016 at 2:26 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, May 25, 2016 at 01:30:44PM +0530, Pratyush Anand wrote:
>> On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
>> > +int mem_regions_exclude(struct memory_ranges *ranges,
>> > +                       const struct memory_range *range)
>> > +{
>> > +       int i;
>> > +
>> > +       for (i = 0; i < ranges->size; i++) {
>> > +               struct memory_range *r = ranges->ranges + i;
>> > +
>> > +               /*
>> > +                * We assume that crash area is fully contained in
>> > +                * some larger memory area.
>> > +                */
>> > +               if (r->start <= range->start && r->end >= range->end) {
>> > +                       if (r->start == range->start) {
>> > +                               /* Shrink the start of this memory range */
>> > +                               r->start = range->end + 1;
>> > +                       } else if (r->end == range->end) {
>> > +                               /* Shrink the end of this memory range */
>> > +                               r->end = range->start - 1;
>>
>> What if r->start == range->start) && (r->end == range->end)?
>
> I suppose that could happen, so what about this patch on top (untested).

I think, it should be fine, except.....

> This isn't something I'd be able to test on real hardware, it needs a
> separate test-suite to be written to do modular testing...
>
>  kexec/mem_regions.c | 94 +++++++++++++++++++++++++++++++----------------------
>  1 file changed, 55 insertions(+), 39 deletions(-)
>
> diff --git a/kexec/mem_regions.c b/kexec/mem_regions.c
> index c6ba942..4e7061b 100644
> --- a/kexec/mem_regions.c
> +++ b/kexec/mem_regions.c
> @@ -29,6 +29,50 @@ void mem_regions_sort(struct memory_ranges *ranges)
>  }
>
>  /**
> + * mem_regions_add() - add a memory region to a set of ranges
> + * @ranges: ranges to add the memory region to
> + * @max: maximum number of entries in memory region
> + * @base: base address of memory region
> + * @length: length of memory region in bytes
> + * @type: type of memory region
> + *
> + * Add the memory region to the set of ranges, and return %0 if successful,
> + * or %-1 if we ran out of space.
> + */
> +int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> +                    unsigned long long length, int type)
> +{
> +       struct memory_range *range;
> +
> +       if (ranges->size >= ranges->max_size)
> +               return -1;
> +
> +       range = ranges->ranges + ranges->size++;
> +       range->start = base;
> +       range->end = base + length - 1;
> +       range->type = type;
> +
> +       return 0;
> +}
> +
> +static void mem_regions_remove(struct memory_ranges *ranges, int index)
> +{
> +       int tail_entries;
> +
> +       /* we are assured to have at least one entry */
> +       ranges->size -= 1;
> +
> +       /* if we have following entries, shuffle them down one place */
> +       tail_entries = ranges->size - index;
> +       if (tail_entries)
> +               memmove(ranges->ranges + index, ranges->ranges + index + 1,
> +                       tail_entries * sizeof(*ranges->ranges));
> +
> +       /* zero the new tail entry */
> +       memset(ranges->ranges + ranges->size, 0, sizeof(*ranges->ranges));
> +}
> +
> +/**
>   * mem_regions_exclude() - excludes a memory region from a set of memory ranges
>   * @ranges: memory ranges to exclude the region from
>   * @range: memory range to exclude
> @@ -40,7 +84,7 @@ void mem_regions_sort(struct memory_ranges *ranges)
>  int mem_regions_exclude(struct memory_ranges *ranges,
>                         const struct memory_range *range)
>  {
> -       int i;
> +       int i, ret;
>
>         for (i = 0; i < ranges->size; i++) {
>                 struct memory_range *r = ranges->ranges + i;
> @@ -51,25 +95,25 @@ int mem_regions_exclude(struct memory_ranges *ranges,
>                  */
>                 if (r->start <= range->start && r->end >= range->end) {
>                         if (r->start == range->start) {
> -                               /* Shrink the start of this memory range */
> -                               r->start = range->end + 1;
> +                               if (r->end == range->end)
> +                                       /* Remove this entry */
> +                                       mem_regions_remove(ranges, i);
> +                               else
> +                                       /* Shrink the start of this memory range */
> +                                       r->start = range->end + 1;
>                         } else if (r->end == range->end) {
>                                 /* Shrink the end of this memory range */
>                                 r->end = range->start - 1;
>                         } else {
> -                               struct memory_range *new;
> -
>                                 /*
>                                  * Split this area into 2 smaller ones and
>                                  * remove excluded range from between. First
>                                  * create new entry for the remaining area.
>                                  */
> -                               if (ranges->size >= ranges->max_size)
> -                                       return -1;
> -
> -                               new = ranges->ranges + ranges->size++;
> -                               new->start = range->end + 1;
> -                               new->end = r->end;
> +                               ret = mem_regions_add(ranges, range->end + 1,
> +                                                     r->end, 0);

3rd argument should be (r->end - range->end)

> +                               if (ret < 0)
> +                                       return ret;
>
>                                 /*
>                                  * Update this area to end before excluded
> @@ -82,31 +126,3 @@ int mem_regions_exclude(struct memory_ranges *ranges,
>         }
>         return 0;
>  }
> -
> -/**
> - * mem_regions_add() - add a memory region to a set of ranges
> - * @ranges: ranges to add the memory region to
> - * @max: maximum number of entries in memory region
> - * @base: base address of memory region
> - * @length: length of memory region in bytes
> - * @type: type of memory region
> - *
> - * Add the memory region to the set of ranges, and return %0 if successful,
> - * or %-1 if we ran out of space.
> - */
> -int mem_regions_add(struct memory_ranges *ranges, unsigned long long base,
> -                    unsigned long long length, int type)
> -{
> -       struct memory_range *range;
> -
> -       if (ranges->size >= ranges->max_size)
> -               return -1;
> -
> -       range = ranges->ranges + ranges->size++;
> -       range->start = base;
> -       range->end = base + length - 1;
> -       range->type = type;
> -
> -       return 0;
> -}
> -
>
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

~Pratyush

Re: [PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Russell King - ARM Linux]

On Fri, May 27, 2016 at 08:37:41PM +0530, Pratyush Anand wrote:
> On Thu, May 26, 2016 at 2:26 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > -                               new = ranges->ranges + ranges->size++;
> > -                               new->start = range->end + 1;
> > -                               new->end = r->end;
> > +                               ret = mem_regions_add(ranges, range->end + 1,
> > +                                                     r->end, 0);
> 
> 3rd argument should be (r->end - range->end)

Yes indeed, thanks for pointing that out.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 12/32] kexec: add helper to exlude a region from a set of memory ranges

[Russell King - ARM Linux]

On Fri, May 27, 2016 at 08:37:41PM +0530, Pratyush Anand wrote:
> On Thu, May 26, 2016 at 2:26 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > -                               new = ranges->ranges + ranges->size++;
> > -                               new->start = range->end + 1;
> > -                               new->end = r->end;
> > +                               ret = mem_regions_add(ranges, range->end + 1,
> > +                                                     r->end, 0);
> 
> 3rd argument should be (r->end - range->end)

Yes indeed, thanks for pointing that out.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH kexec-tools 13/32] arm: fix pointer signedness warning in kexec-uImage-arm.c

[Russell King]

kexec/arch/arm/kexec-uImage-arm.c: In function 'uImage_arm_probe':
kexec/arch/arm/kexec-uImage-arm.c:14:2: warning: pointer targets in passing argument 1 of 'uImage_probe_kernel' differ in signedness [-Wpointer-sign]

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-uImage-arm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-uImage-arm.c b/kexec/arch/arm/kexec-uImage-arm.c
index 03c2f4d..8e0a9ac 100644
--- a/kexec/arch/arm/kexec-uImage-arm.c
+++ b/kexec/arch/arm/kexec-uImage-arm.c
@@ -11,7 +11,8 @@
 
 int uImage_arm_probe(const char *buf, off_t len)
 {
-	return uImage_probe_kernel(buf, len, IH_ARCH_ARM);
+	return uImage_probe_kernel((const unsigned char *)buf, len,
+				   IH_ARCH_ARM);
 }
 
 int uImage_arm_load(int argc, char **argv, const char *buf, off_t len,
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 13/32] arm: fix pointer signedness warning in kexec-uImage-arm.c

[Russell King]

kexec/arch/arm/kexec-uImage-arm.c: In function 'uImage_arm_probe':
kexec/arch/arm/kexec-uImage-arm.c:14:2: warning: pointer targets in passing argument 1 of 'uImage_probe_kernel' differ in signedness [-Wpointer-sign]

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-uImage-arm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-uImage-arm.c b/kexec/arch/arm/kexec-uImage-arm.c
index 03c2f4d..8e0a9ac 100644
--- a/kexec/arch/arm/kexec-uImage-arm.c
+++ b/kexec/arch/arm/kexec-uImage-arm.c
@@ -11,7 +11,8 @@
 
 int uImage_arm_probe(const char *buf, off_t len)
 {
-	return uImage_probe_kernel(buf, len, IH_ARCH_ARM);
+	return uImage_probe_kernel((const unsigned char *)buf, len,
+				   IH_ARCH_ARM);
 }
 
 int uImage_arm_load(int argc, char **argv, const char *buf, off_t len,
-- 
1.9.1

Re: [PATCH kexec-tools 13/32] arm: fix pointer signedness warning in kexec-uImage-arm.c

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> kexec/arch/arm/kexec-uImage-arm.c: In function 'uImage_arm_probe':
> kexec/arch/arm/kexec-uImage-arm.c:14:2: warning: pointer targets in passing argument 1 of 'uImage_probe_kernel' differ in signedness [-Wpointer-sign]
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-uImage-arm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-uImage-arm.c b/kexec/arch/arm/kexec-uImage-arm.c
> index 03c2f4d..8e0a9ac 100644
> --- a/kexec/arch/arm/kexec-uImage-arm.c
> +++ b/kexec/arch/arm/kexec-uImage-arm.c
> @@ -11,7 +11,8 @@
>
>  int uImage_arm_probe(const char *buf, off_t len)
>  {
> -       return uImage_probe_kernel(buf, len, IH_ARCH_ARM);
> +       return uImage_probe_kernel((const unsigned char *)buf, len,
> +                                  IH_ARCH_ARM);
>  }
>
>  int uImage_arm_load(int argc, char **argv, const char *buf, off_t len,
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 13/32] arm: fix pointer signedness warning in kexec-uImage-arm.c

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> kexec/arch/arm/kexec-uImage-arm.c: In function 'uImage_arm_probe':
> kexec/arch/arm/kexec-uImage-arm.c:14:2: warning: pointer targets in passing argument 1 of 'uImage_probe_kernel' differ in signedness [-Wpointer-sign]
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-uImage-arm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-uImage-arm.c b/kexec/arch/arm/kexec-uImage-arm.c
> index 03c2f4d..8e0a9ac 100644
> --- a/kexec/arch/arm/kexec-uImage-arm.c
> +++ b/kexec/arch/arm/kexec-uImage-arm.c
> @@ -11,7 +11,8 @@
>
>  int uImage_arm_probe(const char *buf, off_t len)
>  {
> -       return uImage_probe_kernel(buf, len, IH_ARCH_ARM);
> +       return uImage_probe_kernel((const unsigned char *)buf, len,
> +                                  IH_ARCH_ARM);
>  }
>
>  int uImage_arm_load(int argc, char **argv, const char *buf, off_t len,
> --
> 1.9.1
>

[PATCH kexec-tools 14/32] arm: fix off-by-one on memory end

[Russell King]

The memory range end is inclusive, not exclusive (see x86).  We should
not be adding one to the value parsed from the /proc/iomem resources.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-arm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index 4e90e69..e47fc00 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -51,7 +51,6 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 		if (count != 2)
 			continue;
 		str = line + consumed;
-		end = end + 1;
 
 		if (memcmp(str, "System RAM\n", 11) == 0) {
 			type = RANGE_RAM;
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 14/32] arm: fix off-by-one on memory end

[Russell King]

The memory range end is inclusive, not exclusive (see x86).  We should
not be adding one to the value parsed from the /proc/iomem resources.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-arm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index 4e90e69..e47fc00 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -51,7 +51,6 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 		if (count != 2)
 			continue;
 		str = line + consumed;
-		end = end + 1;
 
 		if (memcmp(str, "System RAM\n", 11) == 0) {
 			type = RANGE_RAM;
-- 
1.9.1

Re: [PATCH kexec-tools 14/32] arm: fix off-by-one on memory end

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> The memory range end is inclusive, not exclusive (see x86).  We should
> not be adding one to the value parsed from the /proc/iomem resources.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

I think, this also need to be fixed for ARM64 patches. +Geoff

> ---
>  kexec/arch/arm/kexec-arm.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
> index 4e90e69..e47fc00 100644
> --- a/kexec/arch/arm/kexec-arm.c
> +++ b/kexec/arch/arm/kexec-arm.c
> @@ -51,7 +51,6 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>                 if (count != 2)
>                         continue;
>                 str = line + consumed;
> -               end = end + 1;
>
>                 if (memcmp(str, "System RAM\n", 11) == 0) {
>                         type = RANGE_RAM;
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 14/32] arm: fix off-by-one on memory end

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> The memory range end is inclusive, not exclusive (see x86).  We should
> not be adding one to the value parsed from the /proc/iomem resources.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

I think, this also need to be fixed for ARM64 patches. +Geoff

> ---
>  kexec/arch/arm/kexec-arm.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
> index 4e90e69..e47fc00 100644
> --- a/kexec/arch/arm/kexec-arm.c
> +++ b/kexec/arch/arm/kexec-arm.c
> @@ -51,7 +51,6 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>                 if (count != 2)
>                         continue;
>                 str = line + consumed;
> -               end = end + 1;
>
>                 if (memcmp(str, "System RAM\n", 11) == 0) {
>                         type = RANGE_RAM;
> --
> 1.9.1
>

[PATCH kexec-tools 15/32] arm: fix get_kernel_stext_sym() to close its file

[Russell King]

Fix get_kernel_stext_sym() so that it closes its file once it's
finsihed with it - there's no need to leak file descriptors.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index b523e5f..a390187 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -71,25 +71,34 @@ static unsigned long long get_kernel_stext_sym(void)
 	char sym[128];
 	char line[128];
 	FILE *fp;
-	unsigned long long vaddr;
+	unsigned long long vaddr = 0;
 	char type;
 
-	fp = fopen(kallsyms, "r");	if (!fp) {
+	fp = fopen(kallsyms, "r");
+	if (!fp) {
 		fprintf(stderr, "Cannot open %s\n", kallsyms);
 		return 0;
 	}
 
 	while(fgets(line, sizeof(line), fp) != NULL) {
-		if (sscanf(line, "%Lx %c %s", &vaddr, &type, sym) != 3)
+		unsigned long long addr;
+
+		if (sscanf(line, "%Lx %c %s", &addr, &type, sym) != 3)
 			continue;
+
 		if (strcmp(sym, stext) == 0) {
-			dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, vaddr);
-			return vaddr;
+			dbgprintf("kernel symbol %s vaddr = %#llx\n", stext, addr);
+			vaddr = addr;
+			break;
 		}
 	}
 
-	fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
-	return 0;
+	fclose(fp);
+
+	if (vaddr == 0)
+		fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
+
+	return vaddr;
 }
 
 static int get_kernel_page_offset(struct kexec_info *info,
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 15/32] arm: fix get_kernel_stext_sym() to close its file

[Russell King]

Fix get_kernel_stext_sym() so that it closes its file once it's
finsihed with it - there's no need to leak file descriptors.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index b523e5f..a390187 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -71,25 +71,34 @@ static unsigned long long get_kernel_stext_sym(void)
 	char sym[128];
 	char line[128];
 	FILE *fp;
-	unsigned long long vaddr;
+	unsigned long long vaddr = 0;
 	char type;
 
-	fp = fopen(kallsyms, "r");	if (!fp) {
+	fp = fopen(kallsyms, "r");
+	if (!fp) {
 		fprintf(stderr, "Cannot open %s\n", kallsyms);
 		return 0;
 	}
 
 	while(fgets(line, sizeof(line), fp) != NULL) {
-		if (sscanf(line, "%Lx %c %s", &vaddr, &type, sym) != 3)
+		unsigned long long addr;
+
+		if (sscanf(line, "%Lx %c %s", &addr, &type, sym) != 3)
 			continue;
+
 		if (strcmp(sym, stext) == 0) {
-			dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, vaddr);
-			return vaddr;
+			dbgprintf("kernel symbol %s vaddr = %#llx\n", stext, addr);
+			vaddr = addr;
+			break;
 		}
 	}
 
-	fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
-	return 0;
+	fclose(fp);
+
+	if (vaddr == 0)
+		fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
+
+	return vaddr;
 }
 
 static int get_kernel_page_offset(struct kexec_info *info,
-- 
1.9.1

Re: [PATCH kexec-tools 15/32] arm: fix get_kernel_stext_sym() to close its file

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Fix get_kernel_stext_sym() so that it closes its file once it's
> finsihed with it - there's no need to leak file descriptors.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index b523e5f..a390187 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -71,25 +71,34 @@ static unsigned long long get_kernel_stext_sym(void)
>         char sym[128];
>         char line[128];
>         FILE *fp;
> -       unsigned long long vaddr;
> +       unsigned long long vaddr = 0;
>         char type;
>
> -       fp = fopen(kallsyms, "r");      if (!fp) {
> +       fp = fopen(kallsyms, "r");
> +       if (!fp) {
>                 fprintf(stderr, "Cannot open %s\n", kallsyms);
>                 return 0;
>         }
>
>         while(fgets(line, sizeof(line), fp) != NULL) {
> -               if (sscanf(line, "%Lx %c %s", &vaddr, &type, sym) != 3)
> +               unsigned long long addr;
> +
> +               if (sscanf(line, "%Lx %c %s", &addr, &type, sym) != 3)
>                         continue;
> +
>                 if (strcmp(sym, stext) == 0) {
> -                       dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, vaddr);
> -                       return vaddr;
> +                       dbgprintf("kernel symbol %s vaddr = %#llx\n", stext, addr);
> +                       vaddr = addr;
> +                       break;
>                 }
>         }
>
> -       fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
> -       return 0;
> +       fclose(fp);
> +
> +       if (vaddr == 0)
> +               fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
> +
> +       return vaddr;
>  }
>
>  static int get_kernel_page_offset(struct kexec_info *info,
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 15/32] arm: fix get_kernel_stext_sym() to close its file

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Fix get_kernel_stext_sym() so that it closes its file once it's
> finsihed with it - there's no need to leak file descriptors.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index b523e5f..a390187 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -71,25 +71,34 @@ static unsigned long long get_kernel_stext_sym(void)
>         char sym[128];
>         char line[128];
>         FILE *fp;
> -       unsigned long long vaddr;
> +       unsigned long long vaddr = 0;
>         char type;
>
> -       fp = fopen(kallsyms, "r");      if (!fp) {
> +       fp = fopen(kallsyms, "r");
> +       if (!fp) {
>                 fprintf(stderr, "Cannot open %s\n", kallsyms);
>                 return 0;
>         }
>
>         while(fgets(line, sizeof(line), fp) != NULL) {
> -               if (sscanf(line, "%Lx %c %s", &vaddr, &type, sym) != 3)
> +               unsigned long long addr;
> +
> +               if (sscanf(line, "%Lx %c %s", &addr, &type, sym) != 3)
>                         continue;
> +
>                 if (strcmp(sym, stext) == 0) {
> -                       dbgprintf("kernel symbol %s vaddr = %16llx\n", stext, vaddr);
> -                       return vaddr;
> +                       dbgprintf("kernel symbol %s vaddr = %#llx\n", stext, addr);
> +                       vaddr = addr;
> +                       break;
>                 }
>         }
>
> -       fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
> -       return 0;
> +       fclose(fp);
> +
> +       if (vaddr == 0)
> +               fprintf(stderr, "Cannot get kernel %s symbol address\n", stext);
> +
> +       return vaddr;
>  }
>
>  static int get_kernel_page_offset(struct kexec_info *info,
> --
> 1.9.1
>

[PATCH kexec-tools 16/32] arm: fix ELF32/ELF64 check

[Russell King]

Rather than using ULONG_MAX to decide whether to use the ELF64 or ELF32
core dump format, use UINT32_MAX instead - we include stdint.h, so we
might as well use a constant which is meaningful for the limits of
the 32-bit ELF format.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index a390187..fcc4d42 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -369,8 +369,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	if (last_ranges < 0)
 		last_ranges = 0;
 
-	if (crash_memory_ranges[last_ranges].end > ULONG_MAX) {
-
+	if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
 		/* for support LPAE enabled kernel*/
 		elf_info.class = ELFCLASS64;
 
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 16/32] arm: fix ELF32/ELF64 check

[Russell King]

Rather than using ULONG_MAX to decide whether to use the ELF64 or ELF32
core dump format, use UINT32_MAX instead - we include stdint.h, so we
might as well use a constant which is meaningful for the limits of
the 32-bit ELF format.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index a390187..fcc4d42 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -369,8 +369,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	if (last_ranges < 0)
 		last_ranges = 0;
 
-	if (crash_memory_ranges[last_ranges].end > ULONG_MAX) {
-
+	if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
 		/* for support LPAE enabled kernel*/
 		elf_info.class = ELFCLASS64;
 
-- 
1.9.1

[PATCH kexec-tools 17/32] arm: return proper error for missing crash kernel

[Russell King]

Return the proper error code (ENOCRASHKERNEL) for a missing crash
kernel region in /proc/iomem, so the error handling in kexec.c can
print the appropriate message.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
index d85ab9b..4755f06 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -451,7 +451,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
 			 * No crash kernel memory reserved. We cannot do more
 			 * but just bail out.
 			 */
-			return -1;
+			return ENOCRASHKERNEL;
 		}
 		base = start;
 	} else {
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 17/32] arm: return proper error for missing crash kernel

[Russell King]

Return the proper error code (ENOCRASHKERNEL) for a missing crash
kernel region in /proc/iomem, so the error handling in kexec.c can
print the appropriate message.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
index d85ab9b..4755f06 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -451,7 +451,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
 			 * No crash kernel memory reserved. We cannot do more
 			 * but just bail out.
 			 */
-			return -1;
+			return ENOCRASHKERNEL;
 		}
 		base = start;
 	} else {
-- 
1.9.1

Re: [PATCH kexec-tools 17/32] arm: return proper error for missing crash kernel

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Return the proper error code (ENOCRASHKERNEL) for a missing crash
> kernel region in /proc/iomem, so the error handling in kexec.c can
> print the appropriate message.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-zImage-arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
> index d85ab9b..4755f06 100644
> --- a/kexec/arch/arm/kexec-zImage-arm.c
> +++ b/kexec/arch/arm/kexec-zImage-arm.c
> @@ -451,7 +451,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
>                          * No crash kernel memory reserved. We cannot do more
>                          * but just bail out.
>                          */
> -                       return -1;
> +                       return ENOCRASHKERNEL;
>                 }
>                 base = start;
>         } else {
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 17/32] arm: return proper error for missing crash kernel

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Return the proper error code (ENOCRASHKERNEL) for a missing crash
> kernel region in /proc/iomem, so the error handling in kexec.c can
> print the appropriate message.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-zImage-arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
> index d85ab9b..4755f06 100644
> --- a/kexec/arch/arm/kexec-zImage-arm.c
> +++ b/kexec/arch/arm/kexec-zImage-arm.c
> @@ -451,7 +451,7 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
>                          * No crash kernel memory reserved. We cannot do more
>                          * but just bail out.
>                          */
> -                       return -1;
> +                       return ENOCRASHKERNEL;
>                 }
>                 base = start;
>         } else {
> --
> 1.9.1
>

[PATCH kexec-tools 18/32] arm: report if crash kernel is out of bounds

[Russell King]

Report an error if the crash kernel memory region is outside of the
boot-view memory range - this can happen with systems such as
Keystone 2.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 11 +++++++++++
 kexec/arch/arm/crashdump-arm.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index fcc4d42..739c906 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -365,6 +365,17 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	if (get_kernel_page_offset(info, &elf_info))
 		return -1;
 
+	/*
+	 * Ensure that the crash kernel memory range is sane. The crash kernel
+	 * must be located within memory which is visible during booting.
+	 */
+	if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
+		fprintf(stderr,
+			"Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
+			crash_reserved_mem.start, crash_reserved_mem.end);
+		return -1;
+	}
+
 	last_ranges = usablemem_rgns.size - 1;
 	if (last_ranges < 0)
 		last_ranges = 0;
diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
index 2dbde04..7314960 100644
--- a/kexec/arch/arm/crashdump-arm.h
+++ b/kexec/arch/arm/crashdump-arm.h
@@ -9,6 +9,7 @@ extern "C" {
 #define DEFAULT_PAGE_OFFSET		(0xc0000000)
 #define KVBASE_MASK	(0x1ffffff)
 #define CRASH_MAX_MEMORY_RANGES	32
+#define ARM_MAX_VIRTUAL		UINT32_MAX
 
 
 extern struct memory_ranges usablemem_rgns;
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 18/32] arm: report if crash kernel is out of bounds

[Russell King]

Report an error if the crash kernel memory region is outside of the
boot-view memory range - this can happen with systems such as
Keystone 2.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 11 +++++++++++
 kexec/arch/arm/crashdump-arm.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index fcc4d42..739c906 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -365,6 +365,17 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	if (get_kernel_page_offset(info, &elf_info))
 		return -1;
 
+	/*
+	 * Ensure that the crash kernel memory range is sane. The crash kernel
+	 * must be located within memory which is visible during booting.
+	 */
+	if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
+		fprintf(stderr,
+			"Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
+			crash_reserved_mem.start, crash_reserved_mem.end);
+		return -1;
+	}
+
 	last_ranges = usablemem_rgns.size - 1;
 	if (last_ranges < 0)
 		last_ranges = 0;
diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
index 2dbde04..7314960 100644
--- a/kexec/arch/arm/crashdump-arm.h
+++ b/kexec/arch/arm/crashdump-arm.h
@@ -9,6 +9,7 @@ extern "C" {
 #define DEFAULT_PAGE_OFFSET		(0xc0000000)
 #define KVBASE_MASK	(0x1ffffff)
 #define CRASH_MAX_MEMORY_RANGES	32
+#define ARM_MAX_VIRTUAL		UINT32_MAX
 
 
 extern struct memory_ranges usablemem_rgns;
-- 
1.9.1

Re: [PATCH kexec-tools 18/32] arm: report if crash kernel is out of bounds

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Report an error if the crash kernel memory region is outside of the
> boot-view memory range - this can happen with systems such as
> Keystone 2.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/arch/arm/crashdump-arm.c | 11 +++++++++++
>  kexec/arch/arm/crashdump-arm.h |  1 +
>  2 files changed, 12 insertions(+)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index fcc4d42..739c906 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -365,6 +365,17 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>         if (get_kernel_page_offset(info, &elf_info))
>                 return -1;
>
> +       /*
> +        * Ensure that the crash kernel memory range is sane. The crash kernel
> +        * must be located within memory which is visible during booting.
> +        */
> +       if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
> +               fprintf(stderr,
> +                       "Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
> +                       crash_reserved_mem.start, crash_reserved_mem.end);
> +               return -1;
> +       }
> +
>         last_ranges = usablemem_rgns.size - 1;
>         if (last_ranges < 0)
>                 last_ranges = 0;
> diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
> index 2dbde04..7314960 100644
> --- a/kexec/arch/arm/crashdump-arm.h
> +++ b/kexec/arch/arm/crashdump-arm.h
> @@ -9,6 +9,7 @@ extern "C" {
>  #define DEFAULT_PAGE_OFFSET            (0xc0000000)
>  #define KVBASE_MASK    (0x1ffffff)
>  #define CRASH_MAX_MEMORY_RANGES        32
> +#define ARM_MAX_VIRTUAL                UINT32_MAX

If I see a kernel code then a virtual address is always defined as
unsigned long. So, shouldn't we use ULONG_MAX instead?

>
>
>  extern struct memory_ranges usablemem_rgns;
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 18/32] arm: report if crash kernel is out of bounds

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Report an error if the crash kernel memory region is outside of the
> boot-view memory range - this can happen with systems such as
> Keystone 2.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>
> ---
>  kexec/arch/arm/crashdump-arm.c | 11 +++++++++++
>  kexec/arch/arm/crashdump-arm.h |  1 +
>  2 files changed, 12 insertions(+)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index fcc4d42..739c906 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -365,6 +365,17 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>         if (get_kernel_page_offset(info, &elf_info))
>                 return -1;
>
> +       /*
> +        * Ensure that the crash kernel memory range is sane. The crash kernel
> +        * must be located within memory which is visible during booting.
> +        */
> +       if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
> +               fprintf(stderr,
> +                       "Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
> +                       crash_reserved_mem.start, crash_reserved_mem.end);
> +               return -1;
> +       }
> +
>         last_ranges = usablemem_rgns.size - 1;
>         if (last_ranges < 0)
>                 last_ranges = 0;
> diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
> index 2dbde04..7314960 100644
> --- a/kexec/arch/arm/crashdump-arm.h
> +++ b/kexec/arch/arm/crashdump-arm.h
> @@ -9,6 +9,7 @@ extern "C" {
>  #define DEFAULT_PAGE_OFFSET            (0xc0000000)
>  #define KVBASE_MASK    (0x1ffffff)
>  #define CRASH_MAX_MEMORY_RANGES        32
> +#define ARM_MAX_VIRTUAL                UINT32_MAX

If I see a kernel code then a virtual address is always defined as
unsigned long. So, shouldn't we use ULONG_MAX instead?

>
>
>  extern struct memory_ranges usablemem_rgns;
> --
> 1.9.1
>

Re: [PATCH kexec-tools 18/32] arm: report if crash kernel is out of bounds

[Russell King - ARM Linux]

On Fri, May 27, 2016 at 04:57:47PM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
> > index 2dbde04..7314960 100644
> > --- a/kexec/arch/arm/crashdump-arm.h
> > +++ b/kexec/arch/arm/crashdump-arm.h
> > @@ -9,6 +9,7 @@ extern "C" {
> >  #define DEFAULT_PAGE_OFFSET            (0xc0000000)
> >  #define KVBASE_MASK    (0x1ffffff)
> >  #define CRASH_MAX_MEMORY_RANGES        32
> > +#define ARM_MAX_VIRTUAL                UINT32_MAX
> 
> If I see a kernel code then a virtual address is always defined as
> unsigned long. So, shouldn't we use ULONG_MAX instead?

What is the definition of ULONG_MAX?  The maximum unsigned value that
can fit in an unsigned long quantity.

While unsigned long _may_ be 32-bit, it's a very round-about way to
say "the maximum virtual address is the maximum unsigned 32-bit value".
Hence why I'm using UINT32_MAX here - it's a tighter and accurate
macro for what we're wanting.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 18/32] arm: report if crash kernel is out of bounds

[Russell King - ARM Linux]

On Fri, May 27, 2016 at 04:57:47PM +0530, Pratyush Anand wrote:
> On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> > diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
> > index 2dbde04..7314960 100644
> > --- a/kexec/arch/arm/crashdump-arm.h
> > +++ b/kexec/arch/arm/crashdump-arm.h
> > @@ -9,6 +9,7 @@ extern "C" {
> >  #define DEFAULT_PAGE_OFFSET            (0xc0000000)
> >  #define KVBASE_MASK    (0x1ffffff)
> >  #define CRASH_MAX_MEMORY_RANGES        32
> > +#define ARM_MAX_VIRTUAL                UINT32_MAX
> 
> If I see a kernel code then a virtual address is always defined as
> unsigned long. So, shouldn't we use ULONG_MAX instead?

What is the definition of ULONG_MAX?  The maximum unsigned value that
can fit in an unsigned long quantity.

While unsigned long _may_ be 32-bit, it's a very round-about way to
say "the maximum virtual address is the maximum unsigned 32-bit value".
Hence why I'm using UINT32_MAX here - it's a tighter and accurate
macro for what we're wanting.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH kexec-tools 19/32] arm: add memory ranges debug

[Russell King]

Add the call to dbgprint_mem_range() into the ARM version of
get_memory_ranges().

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index e47fc00..eeb27b4 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -70,6 +70,9 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 	fclose(fp);
 	*range = memory_range;
 	*ranges = memory_ranges;
+
+	dbgprint_mem_range("MEMORY RANGES", *range, *ranges);
+
 	return 0;
 }
 
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 19/32] arm: add memory ranges debug

[Russell King]

Add the call to dbgprint_mem_range() into the ARM version of
get_memory_ranges().

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index e47fc00..eeb27b4 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -70,6 +70,9 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 	fclose(fp);
 	*range = memory_range;
 	*ranges = memory_ranges;
+
+	dbgprint_mem_range("MEMORY RANGES", *range, *ranges);
+
 	return 0;
 }
 
-- 
1.9.1

Re: [PATCH kexec-tools 19/32] arm: add memory ranges debug

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add the call to dbgprint_mem_range() into the ARM version of
> get_memory_ranges().
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-arm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
> index e47fc00..eeb27b4 100644
> --- a/kexec/arch/arm/kexec-arm.c
> +++ b/kexec/arch/arm/kexec-arm.c
> @@ -70,6 +70,9 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>         fclose(fp);
>         *range = memory_range;
>         *ranges = memory_ranges;
> +
> +       dbgprint_mem_range("MEMORY RANGES", *range, *ranges);
> +
>         return 0;
>  }
>
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 19/32] arm: add memory ranges debug

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add the call to dbgprint_mem_range() into the ARM version of
> get_memory_ranges().
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-arm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
> index e47fc00..eeb27b4 100644
> --- a/kexec/arch/arm/kexec-arm.c
> +++ b/kexec/arch/arm/kexec-arm.c
> @@ -70,6 +70,9 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>         fclose(fp);
>         *range = memory_range;
>         *ranges = memory_ranges;
> +
> +       dbgprint_mem_range("MEMORY RANGES", *range, *ranges);
> +
>         return 0;
>  }
>
> --
> 1.9.1
>

[PATCH kexec-tools 20/32] arm: add maximum number of memory ranges

[Russell King]

Add the maximum number of memory ranges to the list of usable memory
ranges, so that we don't have to carry this around.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 739c906..195b43f 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -46,8 +46,8 @@
  */
 static struct memory_range crash_memory_ranges[CRASH_MAX_MEMORY_RANGES];
 struct memory_ranges usablemem_rgns = {
-    .size = 0,
-    .ranges = crash_memory_ranges,
+	.max_size = CRASH_MAX_MEMORY_RANGES,
+	.ranges = crash_memory_ranges,
 };
 
 /* memory range reserved for crashkernel */
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 20/32] arm: add maximum number of memory ranges

[Russell King]

Add the maximum number of memory ranges to the list of usable memory
ranges, so that we don't have to carry this around.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 739c906..195b43f 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -46,8 +46,8 @@
  */
 static struct memory_range crash_memory_ranges[CRASH_MAX_MEMORY_RANGES];
 struct memory_ranges usablemem_rgns = {
-    .size = 0,
-    .ranges = crash_memory_ranges,
+	.max_size = CRASH_MAX_MEMORY_RANGES,
+	.ranges = crash_memory_ranges,
 };
 
 /* memory range reserved for crashkernel */
-- 
1.9.1

Re: [PATCH kexec-tools 20/32] arm: add maximum number of memory ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add the maximum number of memory ranges to the list of usable memory
> ranges, so that we don't have to carry this around.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 739c906..195b43f 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -46,8 +46,8 @@
>   */
>  static struct memory_range crash_memory_ranges[CRASH_MAX_MEMORY_RANGES];
>  struct memory_ranges usablemem_rgns = {
> -    .size = 0,
> -    .ranges = crash_memory_ranges,
> +       .max_size = CRASH_MAX_MEMORY_RANGES,
> +       .ranges = crash_memory_ranges,
>  };
>
>  /* memory range reserved for crashkernel */
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 20/32] arm: add maximum number of memory ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add the maximum number of memory ranges to the list of usable memory
> ranges, so that we don't have to carry this around.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 739c906..195b43f 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -46,8 +46,8 @@
>   */
>  static struct memory_range crash_memory_ranges[CRASH_MAX_MEMORY_RANGES];
>  struct memory_ranges usablemem_rgns = {
> -    .size = 0,
> -    .ranges = crash_memory_ranges,
> +       .max_size = CRASH_MAX_MEMORY_RANGES,
> +       .ranges = crash_memory_ranges,
>  };
>
>  /* memory range reserved for crashkernel */
> --
> 1.9.1
>

[PATCH kexec-tools 21/32] arm: parse crash_reserved_mem early

[Russell King]

We parse the crash kernel memory region in several locations in the
kexec tools - once to check that there's a region, another time for
real when we're locating the memory regions to dump, and another
while loading the image.

Move the real parsing step to is_crashkernel_mem_reserved(), which
matches what x86 is doing.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 47 +++++++++++++++++++++++++++++++-----------
 kexec/arch/arm/iomem.h         |  7 +++++++
 2 files changed, 42 insertions(+), 12 deletions(-)
 create mode 100644 kexec/arch/arm/iomem.h

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 195b43f..85afd9f 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -31,6 +31,7 @@
 #include "../../kexec-elf.h"
 #include "../../crashdump.h"
 #include "crashdump-arm.h"
+#include "iomem.h"
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #define ELFDATANATIVE ELFDATA2LSB
@@ -139,9 +140,8 @@ static int get_kernel_page_offset(struct kexec_info *info,
  * @length: size of the memory region
  *
  * This function is called once for each memory region found in /proc/iomem. It
- * locates system RAM and crashkernel reserved memory and places these to
- * variables: @crash_memory_ranges and @crash_reserved_mem. Number of memory
- * regions is placed in @crash_memory_nr_ranges.
+ * locates system RAM and places these into @crash_memory_ranges. Number of
+ * memory regions is placed in @crash_memory_nr_ranges.
  */
 static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
 				char *str, unsigned long long base,
@@ -159,10 +159,6 @@ static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
 		range->end = base + length - 1;
 		range->type = RANGE_RAM;
 		usablemem_rgns.size++;
-	} else if (strncmp(str, "Crash kernel\n", 13) == 0) {
-		crash_reserved_mem.start = base;
-		crash_reserved_mem.end = base + length - 1;
-		crash_reserved_mem.type = RANGE_RAM;
 	}
 
 	return 0;
@@ -424,12 +420,39 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	return 0;
 }
 
-int is_crashkernel_mem_reserved(void)
+/**
+ * iomem_range_callback() - callback called for each iomem region
+ * @data: not used
+ * @nr: not used
+ * @str: name of the memory region (not NULL terminated)
+ * @base: start address of the memory region
+ * @length: size of the memory region
+ *
+ * This function is called for each memory range in /proc/iomem, and stores
+ * the location of the crash kernel range into @crash_reserved_mem.
+ */
+static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
+				char *str, unsigned long long base,
+				unsigned long long length)
 {
-	uint64_t start, end;
+	if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+		crash_reserved_mem.start = base;
+		crash_reserved_mem.end = base + length - 1;
+		crash_reserved_mem.type = RANGE_RAM;
+	}
+	return 0;
+}
 
-	if (parse_iomem_single("Crash kernel\n", &start, &end) == 0)
-		return start != end;
+/**
+ * is_crashkernel_mem_reserved() - check for the crashkernel reserved region
+ *
+ * Check for the crashkernel reserved region in /proc/iomem, and return
+ * true if it is present, or false otherwise. We use this to store the
+ * location of this region.
+ */
+int is_crashkernel_mem_reserved(void)
+{
+	kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
 
-	return 0;
+	return crash_reserved_mem.start != crash_reserved_mem.end;
 }
diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
new file mode 100644
index 0000000..81c593d
--- /dev/null
+++ b/kexec/arch/arm/iomem.h
@@ -0,0 +1,7 @@
+#ifndef IOMEM_H
+#define IOMEM_H
+
+#define SYSTEM_RAM		"System RAM\n"
+#define CRASH_KERNEL		"Crash kernel\n"
+
+#endif
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 21/32] arm: parse crash_reserved_mem early

[Russell King]

We parse the crash kernel memory region in several locations in the
kexec tools - once to check that there's a region, another time for
real when we're locating the memory regions to dump, and another
while loading the image.

Move the real parsing step to is_crashkernel_mem_reserved(), which
matches what x86 is doing.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 47 +++++++++++++++++++++++++++++++-----------
 kexec/arch/arm/iomem.h         |  7 +++++++
 2 files changed, 42 insertions(+), 12 deletions(-)
 create mode 100644 kexec/arch/arm/iomem.h

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 195b43f..85afd9f 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -31,6 +31,7 @@
 #include "../../kexec-elf.h"
 #include "../../crashdump.h"
 #include "crashdump-arm.h"
+#include "iomem.h"
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #define ELFDATANATIVE ELFDATA2LSB
@@ -139,9 +140,8 @@ static int get_kernel_page_offset(struct kexec_info *info,
  * @length: size of the memory region
  *
  * This function is called once for each memory region found in /proc/iomem. It
- * locates system RAM and crashkernel reserved memory and places these to
- * variables: @crash_memory_ranges and @crash_reserved_mem. Number of memory
- * regions is placed in @crash_memory_nr_ranges.
+ * locates system RAM and places these into @crash_memory_ranges. Number of
+ * memory regions is placed in @crash_memory_nr_ranges.
  */
 static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
 				char *str, unsigned long long base,
@@ -159,10 +159,6 @@ static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
 		range->end = base + length - 1;
 		range->type = RANGE_RAM;
 		usablemem_rgns.size++;
-	} else if (strncmp(str, "Crash kernel\n", 13) == 0) {
-		crash_reserved_mem.start = base;
-		crash_reserved_mem.end = base + length - 1;
-		crash_reserved_mem.type = RANGE_RAM;
 	}
 
 	return 0;
@@ -424,12 +420,39 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	return 0;
 }
 
-int is_crashkernel_mem_reserved(void)
+/**
+ * iomem_range_callback() - callback called for each iomem region
+ * @data: not used
+ * @nr: not used
+ * @str: name of the memory region (not NULL terminated)
+ * @base: start address of the memory region
+ * @length: size of the memory region
+ *
+ * This function is called for each memory range in /proc/iomem, and stores
+ * the location of the crash kernel range into @crash_reserved_mem.
+ */
+static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
+				char *str, unsigned long long base,
+				unsigned long long length)
 {
-	uint64_t start, end;
+	if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+		crash_reserved_mem.start = base;
+		crash_reserved_mem.end = base + length - 1;
+		crash_reserved_mem.type = RANGE_RAM;
+	}
+	return 0;
+}
 
-	if (parse_iomem_single("Crash kernel\n", &start, &end) == 0)
-		return start != end;
+/**
+ * is_crashkernel_mem_reserved() - check for the crashkernel reserved region
+ *
+ * Check for the crashkernel reserved region in /proc/iomem, and return
+ * true if it is present, or false otherwise. We use this to store the
+ * location of this region.
+ */
+int is_crashkernel_mem_reserved(void)
+{
+	kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
 
-	return 0;
+	return crash_reserved_mem.start != crash_reserved_mem.end;
 }
diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
new file mode 100644
index 0000000..81c593d
--- /dev/null
+++ b/kexec/arch/arm/iomem.h
@@ -0,0 +1,7 @@
+#ifndef IOMEM_H
+#define IOMEM_H
+
+#define SYSTEM_RAM		"System RAM\n"
+#define CRASH_KERNEL		"Crash kernel\n"
+
+#endif
-- 
1.9.1

Re: [PATCH kexec-tools 21/32] arm: parse crash_reserved_mem early

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> We parse the crash kernel memory region in several locations in the
> kexec tools - once to check that there's a region, another time for
> real when we're locating the memory regions to dump, and another
> while loading the image.
>
> Move the real parsing step to is_crashkernel_mem_reserved(), which
> matches what x86 is doing.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 47 +++++++++++++++++++++++++++++++-----------
>  kexec/arch/arm/iomem.h         |  7 +++++++
>  2 files changed, 42 insertions(+), 12 deletions(-)
>  create mode 100644 kexec/arch/arm/iomem.h
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 195b43f..85afd9f 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -31,6 +31,7 @@
>  #include "../../kexec-elf.h"
>  #include "../../crashdump.h"
>  #include "crashdump-arm.h"
> +#include "iomem.h"
>
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  #define ELFDATANATIVE ELFDATA2LSB
> @@ -139,9 +140,8 @@ static int get_kernel_page_offset(struct kexec_info *info,
>   * @length: size of the memory region
>   *
>   * This function is called once for each memory region found in /proc/iomem. It
> - * locates system RAM and crashkernel reserved memory and places these to
> - * variables: @crash_memory_ranges and @crash_reserved_mem. Number of memory
> - * regions is placed in @crash_memory_nr_ranges.
> + * locates system RAM and places these into @crash_memory_ranges. Number of
> + * memory regions is placed in @crash_memory_nr_ranges.
>   */
>  static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 char *str, unsigned long long base,
> @@ -159,10 +159,6 @@ static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
>                 range->end = base + length - 1;
>                 range->type = RANGE_RAM;
>                 usablemem_rgns.size++;
> -       } else if (strncmp(str, "Crash kernel\n", 13) == 0) {
> -               crash_reserved_mem.start = base;
> -               crash_reserved_mem.end = base + length - 1;
> -               crash_reserved_mem.type = RANGE_RAM;
>         }
>
>         return 0;
> @@ -424,12 +420,39 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>         return 0;
>  }
>
> -int is_crashkernel_mem_reserved(void)
> +/**
> + * iomem_range_callback() - callback called for each iomem region
> + * @data: not used
> + * @nr: not used
> + * @str: name of the memory region (not NULL terminated)
> + * @base: start address of the memory region
> + * @length: size of the memory region
> + *
> + * This function is called for each memory range in /proc/iomem, and stores
> + * the location of the crash kernel range into @crash_reserved_mem.
> + */
> +static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
> +                               char *str, unsigned long long base,
> +                               unsigned long long length)
>  {
> -       uint64_t start, end;
> +       if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> +               crash_reserved_mem.start = base;
> +               crash_reserved_mem.end = base + length - 1;
> +               crash_reserved_mem.type = RANGE_RAM;
> +       }
> +       return 0;
> +}
>
> -       if (parse_iomem_single("Crash kernel\n", &start, &end) == 0)
> -               return start != end;
> +/**
> + * is_crashkernel_mem_reserved() - check for the crashkernel reserved region
> + *
> + * Check for the crashkernel reserved region in /proc/iomem, and return
> + * true if it is present, or false otherwise. We use this to store the
> + * location of this region.
> + */
> +int is_crashkernel_mem_reserved(void)
> +{
> +       kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
>
> -       return 0;
> +       return crash_reserved_mem.start != crash_reserved_mem.end;
>  }
> diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
> new file mode 100644
> index 0000000..81c593d
> --- /dev/null
> +++ b/kexec/arch/arm/iomem.h
> @@ -0,0 +1,7 @@
> +#ifndef IOMEM_H
> +#define IOMEM_H
> +
> +#define SYSTEM_RAM             "System RAM\n"
> +#define CRASH_KERNEL           "Crash kernel\n"
> +
> +#endif
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 21/32] arm: parse crash_reserved_mem early

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> We parse the crash kernel memory region in several locations in the
> kexec tools - once to check that there's a region, another time for
> real when we're locating the memory regions to dump, and another
> while loading the image.
>
> Move the real parsing step to is_crashkernel_mem_reserved(), which
> matches what x86 is doing.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 47 +++++++++++++++++++++++++++++++-----------
>  kexec/arch/arm/iomem.h         |  7 +++++++
>  2 files changed, 42 insertions(+), 12 deletions(-)
>  create mode 100644 kexec/arch/arm/iomem.h
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 195b43f..85afd9f 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -31,6 +31,7 @@
>  #include "../../kexec-elf.h"
>  #include "../../crashdump.h"
>  #include "crashdump-arm.h"
> +#include "iomem.h"
>
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  #define ELFDATANATIVE ELFDATA2LSB
> @@ -139,9 +140,8 @@ static int get_kernel_page_offset(struct kexec_info *info,
>   * @length: size of the memory region
>   *
>   * This function is called once for each memory region found in /proc/iomem. It
> - * locates system RAM and crashkernel reserved memory and places these to
> - * variables: @crash_memory_ranges and @crash_reserved_mem. Number of memory
> - * regions is placed in @crash_memory_nr_ranges.
> + * locates system RAM and places these into @crash_memory_ranges. Number of
> + * memory regions is placed in @crash_memory_nr_ranges.
>   */
>  static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 char *str, unsigned long long base,
> @@ -159,10 +159,6 @@ static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
>                 range->end = base + length - 1;
>                 range->type = RANGE_RAM;
>                 usablemem_rgns.size++;
> -       } else if (strncmp(str, "Crash kernel\n", 13) == 0) {
> -               crash_reserved_mem.start = base;
> -               crash_reserved_mem.end = base + length - 1;
> -               crash_reserved_mem.type = RANGE_RAM;
>         }
>
>         return 0;
> @@ -424,12 +420,39 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>         return 0;
>  }
>
> -int is_crashkernel_mem_reserved(void)
> +/**
> + * iomem_range_callback() - callback called for each iomem region
> + * @data: not used
> + * @nr: not used
> + * @str: name of the memory region (not NULL terminated)
> + * @base: start address of the memory region
> + * @length: size of the memory region
> + *
> + * This function is called for each memory range in /proc/iomem, and stores
> + * the location of the crash kernel range into @crash_reserved_mem.
> + */
> +static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
> +                               char *str, unsigned long long base,
> +                               unsigned long long length)
>  {
> -       uint64_t start, end;
> +       if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> +               crash_reserved_mem.start = base;
> +               crash_reserved_mem.end = base + length - 1;
> +               crash_reserved_mem.type = RANGE_RAM;
> +       }
> +       return 0;
> +}
>
> -       if (parse_iomem_single("Crash kernel\n", &start, &end) == 0)
> -               return start != end;
> +/**
> + * is_crashkernel_mem_reserved() - check for the crashkernel reserved region
> + *
> + * Check for the crashkernel reserved region in /proc/iomem, and return
> + * true if it is present, or false otherwise. We use this to store the
> + * location of this region.
> + */
> +int is_crashkernel_mem_reserved(void)
> +{
> +       kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
>
> -       return 0;
> +       return crash_reserved_mem.start != crash_reserved_mem.end;
>  }
> diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
> new file mode 100644
> index 0000000..81c593d
> --- /dev/null
> +++ b/kexec/arch/arm/iomem.h
> @@ -0,0 +1,7 @@
> +#ifndef IOMEM_H
> +#define IOMEM_H
> +
> +#define SYSTEM_RAM             "System RAM\n"
> +#define CRASH_KERNEL           "Crash kernel\n"
> +
> +#endif
> --
> 1.9.1
>

[PATCH kexec-tools 22/32] arm: use generic mem_region sorting implementation

[Russell King]

Use the generic mem_region sorting implementation.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 85afd9f..d6db566 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -202,19 +202,6 @@ static void crash_exclude_range(void)
 	}
 }
 
-static int range_cmp(const void *a1, const void *a2)
-{
-	const struct memory_range *r1 = a1;
-	const struct memory_range *r2 = a2;
-
-	if (r1->start > r2->start)
-		return 1;
-	if (r1->start < r2->start)
-		return -1;
-
-	return 0;
-}
-
 /**
  * crash_get_memory_ranges() - read system physical memory
  *
@@ -246,8 +233,7 @@ static int crash_get_memory_ranges(void)
 	/*
 	 * Make sure that the memory regions are sorted.
 	 */
-	qsort(usablemem_rgns.ranges, usablemem_rgns.size,
-	      sizeof(*usablemem_rgns.ranges), range_cmp);
+	mem_regions_sort(&usablemem_rgns);
 
 	return 0;
 }
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 22/32] arm: use generic mem_region sorting implementation

[Russell King]

Use the generic mem_region sorting implementation.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 85afd9f..d6db566 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -202,19 +202,6 @@ static void crash_exclude_range(void)
 	}
 }
 
-static int range_cmp(const void *a1, const void *a2)
-{
-	const struct memory_range *r1 = a1;
-	const struct memory_range *r2 = a2;
-
-	if (r1->start > r2->start)
-		return 1;
-	if (r1->start < r2->start)
-		return -1;
-
-	return 0;
-}
-
 /**
  * crash_get_memory_ranges() - read system physical memory
  *
@@ -246,8 +233,7 @@ static int crash_get_memory_ranges(void)
 	/*
 	 * Make sure that the memory regions are sorted.
 	 */
-	qsort(usablemem_rgns.ranges, usablemem_rgns.size,
-	      sizeof(*usablemem_rgns.ranges), range_cmp);
+	mem_regions_sort(&usablemem_rgns);
 
 	return 0;
 }
-- 
1.9.1

Re: [PATCH kexec-tools 22/32] arm: use generic mem_region sorting implementation

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Use the generic mem_region sorting implementation.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 16 +---------------
>  1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 85afd9f..d6db566 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -202,19 +202,6 @@ static void crash_exclude_range(void)
>         }
>  }
>
> -static int range_cmp(const void *a1, const void *a2)
> -{
> -       const struct memory_range *r1 = a1;
> -       const struct memory_range *r2 = a2;
> -
> -       if (r1->start > r2->start)
> -               return 1;
> -       if (r1->start < r2->start)
> -               return -1;
> -
> -       return 0;
> -}
> -
>  /**
>   * crash_get_memory_ranges() - read system physical memory
>   *
> @@ -246,8 +233,7 @@ static int crash_get_memory_ranges(void)
>         /*
>          * Make sure that the memory regions are sorted.
>          */
> -       qsort(usablemem_rgns.ranges, usablemem_rgns.size,
> -             sizeof(*usablemem_rgns.ranges), range_cmp);
> +       mem_regions_sort(&usablemem_rgns);
>
>         return 0;
>  }
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 22/32] arm: use generic mem_region sorting implementation

[Pratyush Anand]

On Tue, May 3, 2016 at 3:52 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Use the generic mem_region sorting implementation.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 16 +---------------
>  1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 85afd9f..d6db566 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -202,19 +202,6 @@ static void crash_exclude_range(void)
>         }
>  }
>
> -static int range_cmp(const void *a1, const void *a2)
> -{
> -       const struct memory_range *r1 = a1;
> -       const struct memory_range *r2 = a2;
> -
> -       if (r1->start > r2->start)
> -               return 1;
> -       if (r1->start < r2->start)
> -               return -1;
> -
> -       return 0;
> -}
> -
>  /**
>   * crash_get_memory_ranges() - read system physical memory
>   *
> @@ -246,8 +233,7 @@ static int crash_get_memory_ranges(void)
>         /*
>          * Make sure that the memory regions are sorted.
>          */
> -       qsort(usablemem_rgns.ranges, usablemem_rgns.size,
> -             sizeof(*usablemem_rgns.ranges), range_cmp);
> +       mem_regions_sort(&usablemem_rgns);
>
>         return 0;
>  }
> --
> 1.9.1
>

[PATCH kexec-tools 23/32] arm: move crash system RAM parsing earlier

[Russell King]

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/Makefile        |  2 ++
 kexec/arch/arm/crashdump-arm.c | 51 ++++++++----------------------------------
 2 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
index 60e433a..71db8c3 100644
--- a/kexec/arch/arm/Makefile
+++ b/kexec/arch/arm/Makefile
@@ -7,6 +7,8 @@ arm_FS2DT              = kexec/fs2dt.c
 arm_FS2DT_INCLUDE      = -include $(srcdir)/kexec/arch/arm/crashdump-arm.h \
                          -include $(srcdir)/kexec/arch/arm/kexec-arm.h
 
+arm_MEM_REGIONS        = kexec/mem_regions.c
+
 arm_KEXEC_SRCS=  kexec/arch/arm/kexec-elf-rel-arm.c
 arm_KEXEC_SRCS+= kexec/arch/arm/kexec-zImage-arm.c
 arm_KEXEC_SRCS+= kexec/arch/arm/kexec-uImage-arm.c
diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index d6db566..f2e6a0d 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -30,6 +30,7 @@
 #include "../../kexec.h"
 #include "../../kexec-elf.h"
 #include "../../crashdump.h"
+#include "../../mem_regions.h"
 #include "crashdump-arm.h"
 #include "iomem.h"
 
@@ -132,39 +133,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 }
 
 /**
- * crash_range_callback() - callback called for each iomem region
- * @data: not used
- * @nr: not used
- * @str: name of the memory region
- * @base: start address of the memory region
- * @length: size of the memory region
- *
- * This function is called once for each memory region found in /proc/iomem. It
- * locates system RAM and places these into @crash_memory_ranges. Number of
- * memory regions is placed in @crash_memory_nr_ranges.
- */
-static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
-				char *str, unsigned long long base,
-				unsigned long long length)
-{
-	struct memory_range *range;
-
-	if (usablemem_rgns.size >= CRASH_MAX_MEMORY_RANGES)
-		return 1;
-
-	range = usablemem_rgns.ranges + usablemem_rgns.size;
-
-	if (strncmp(str, "System RAM\n", 11) == 0) {
-		range->start = base;
-		range->end = base + length - 1;
-		range->type = RANGE_RAM;
-		usablemem_rgns.size++;
-	}
-
-	return 0;
-}
-
-/**
  * crash_exclude_range() - excludes memory region reserved for crashkernel
  *
  * Function locates where crashkernel reserved memory is and removes that region
@@ -213,12 +181,6 @@ static void crash_exclude_range(void)
  */
 static int crash_get_memory_ranges(void)
 {
-	/*
-	 * First read all memory regions that can be considered as
-	 * system memory including the crash area.
-	 */
-	kexec_iomem_for_each_line(NULL, crash_range_callback, NULL);
-
 	if (usablemem_rgns.size < 1) {
 		errno = EINVAL;
 		return -1;
@@ -414,8 +376,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
  * @base: start address of the memory region
  * @length: size of the memory region
  *
- * This function is called for each memory range in /proc/iomem, and stores
- * the location of the crash kernel range into @crash_reserved_mem.
+ * This function is called for each memory range in /proc/iomem, stores
+ * the location of the crash kernel range into @crash_reserved_mem, and
+ * stores the system RAM into @usablemem_rgns.
  */
 static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 				char *str, unsigned long long base,
@@ -426,6 +389,10 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 		crash_reserved_mem.end = base + length - 1;
 		crash_reserved_mem.type = RANGE_RAM;
 	}
+	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
+		return mem_regions_add(&usablemem_rgns,
+				       base, length, RANGE_RAM);
+	}
 	return 0;
 }
 
@@ -434,7 +401,7 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
  *
  * Check for the crashkernel reserved region in /proc/iomem, and return
  * true if it is present, or false otherwise. We use this to store the
- * location of this region.
+ * location of this region, and system RAM regions.
  */
 int is_crashkernel_mem_reserved(void)
 {
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 23/32] arm: move crash system RAM parsing earlier

[Russell King]

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/Makefile        |  2 ++
 kexec/arch/arm/crashdump-arm.c | 51 ++++++++----------------------------------
 2 files changed, 11 insertions(+), 42 deletions(-)

diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
index 60e433a..71db8c3 100644
--- a/kexec/arch/arm/Makefile
+++ b/kexec/arch/arm/Makefile
@@ -7,6 +7,8 @@ arm_FS2DT              = kexec/fs2dt.c
 arm_FS2DT_INCLUDE      = -include $(srcdir)/kexec/arch/arm/crashdump-arm.h \
                          -include $(srcdir)/kexec/arch/arm/kexec-arm.h
 
+arm_MEM_REGIONS        = kexec/mem_regions.c
+
 arm_KEXEC_SRCS=  kexec/arch/arm/kexec-elf-rel-arm.c
 arm_KEXEC_SRCS+= kexec/arch/arm/kexec-zImage-arm.c
 arm_KEXEC_SRCS+= kexec/arch/arm/kexec-uImage-arm.c
diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index d6db566..f2e6a0d 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -30,6 +30,7 @@
 #include "../../kexec.h"
 #include "../../kexec-elf.h"
 #include "../../crashdump.h"
+#include "../../mem_regions.h"
 #include "crashdump-arm.h"
 #include "iomem.h"
 
@@ -132,39 +133,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 }
 
 /**
- * crash_range_callback() - callback called for each iomem region
- * @data: not used
- * @nr: not used
- * @str: name of the memory region
- * @base: start address of the memory region
- * @length: size of the memory region
- *
- * This function is called once for each memory region found in /proc/iomem. It
- * locates system RAM and places these into @crash_memory_ranges. Number of
- * memory regions is placed in @crash_memory_nr_ranges.
- */
-static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
-				char *str, unsigned long long base,
-				unsigned long long length)
-{
-	struct memory_range *range;
-
-	if (usablemem_rgns.size >= CRASH_MAX_MEMORY_RANGES)
-		return 1;
-
-	range = usablemem_rgns.ranges + usablemem_rgns.size;
-
-	if (strncmp(str, "System RAM\n", 11) == 0) {
-		range->start = base;
-		range->end = base + length - 1;
-		range->type = RANGE_RAM;
-		usablemem_rgns.size++;
-	}
-
-	return 0;
-}
-
-/**
  * crash_exclude_range() - excludes memory region reserved for crashkernel
  *
  * Function locates where crashkernel reserved memory is and removes that region
@@ -213,12 +181,6 @@ static void crash_exclude_range(void)
  */
 static int crash_get_memory_ranges(void)
 {
-	/*
-	 * First read all memory regions that can be considered as
-	 * system memory including the crash area.
-	 */
-	kexec_iomem_for_each_line(NULL, crash_range_callback, NULL);
-
 	if (usablemem_rgns.size < 1) {
 		errno = EINVAL;
 		return -1;
@@ -414,8 +376,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
  * @base: start address of the memory region
  * @length: size of the memory region
  *
- * This function is called for each memory range in /proc/iomem, and stores
- * the location of the crash kernel range into @crash_reserved_mem.
+ * This function is called for each memory range in /proc/iomem, stores
+ * the location of the crash kernel range into @crash_reserved_mem, and
+ * stores the system RAM into @usablemem_rgns.
  */
 static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 				char *str, unsigned long long base,
@@ -426,6 +389,10 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 		crash_reserved_mem.end = base + length - 1;
 		crash_reserved_mem.type = RANGE_RAM;
 	}
+	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
+		return mem_regions_add(&usablemem_rgns,
+				       base, length, RANGE_RAM);
+	}
 	return 0;
 }
 
@@ -434,7 +401,7 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
  *
  * Check for the crashkernel reserved region in /proc/iomem, and return
  * true if it is present, or false otherwise. We use this to store the
- * location of this region.
+ * location of this region, and system RAM regions.
  */
 int is_crashkernel_mem_reserved(void)
 {
-- 
1.9.1

Re: [PATCH kexec-tools 23/32] arm: move crash system RAM parsing earlier

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/Makefile        |  2 ++
>  kexec/arch/arm/crashdump-arm.c | 51 ++++++++----------------------------------
>  2 files changed, 11 insertions(+), 42 deletions(-)
>
> diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
> index 60e433a..71db8c3 100644
> --- a/kexec/arch/arm/Makefile
> +++ b/kexec/arch/arm/Makefile
> @@ -7,6 +7,8 @@ arm_FS2DT              = kexec/fs2dt.c
>  arm_FS2DT_INCLUDE      = -include $(srcdir)/kexec/arch/arm/crashdump-arm.h \
>                           -include $(srcdir)/kexec/arch/arm/kexec-arm.h
>
> +arm_MEM_REGIONS        = kexec/mem_regions.c
> +
>  arm_KEXEC_SRCS=  kexec/arch/arm/kexec-elf-rel-arm.c
>  arm_KEXEC_SRCS+= kexec/arch/arm/kexec-zImage-arm.c
>  arm_KEXEC_SRCS+= kexec/arch/arm/kexec-uImage-arm.c
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index d6db566..f2e6a0d 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -30,6 +30,7 @@
>  #include "../../kexec.h"
>  #include "../../kexec-elf.h"
>  #include "../../crashdump.h"
> +#include "../../mem_regions.h"
>  #include "crashdump-arm.h"
>  #include "iomem.h"
>
> @@ -132,39 +133,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
>  }
>
>  /**
> - * crash_range_callback() - callback called for each iomem region
> - * @data: not used
> - * @nr: not used
> - * @str: name of the memory region
> - * @base: start address of the memory region
> - * @length: size of the memory region
> - *
> - * This function is called once for each memory region found in /proc/iomem. It
> - * locates system RAM and places these into @crash_memory_ranges. Number of
> - * memory regions is placed in @crash_memory_nr_ranges.
> - */
> -static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
> -                               char *str, unsigned long long base,
> -                               unsigned long long length)
> -{
> -       struct memory_range *range;
> -
> -       if (usablemem_rgns.size >= CRASH_MAX_MEMORY_RANGES)
> -               return 1;
> -
> -       range = usablemem_rgns.ranges + usablemem_rgns.size;
> -
> -       if (strncmp(str, "System RAM\n", 11) == 0) {
> -               range->start = base;
> -               range->end = base + length - 1;
> -               range->type = RANGE_RAM;
> -               usablemem_rgns.size++;
> -       }
> -
> -       return 0;
> -}
> -
> -/**
>   * crash_exclude_range() - excludes memory region reserved for crashkernel
>   *
>   * Function locates where crashkernel reserved memory is and removes that region
> @@ -213,12 +181,6 @@ static void crash_exclude_range(void)
>   */
>  static int crash_get_memory_ranges(void)
>  {
> -       /*
> -        * First read all memory regions that can be considered as
> -        * system memory including the crash area.
> -        */
> -       kexec_iomem_for_each_line(NULL, crash_range_callback, NULL);
> -
>         if (usablemem_rgns.size < 1) {
>                 errno = EINVAL;
>                 return -1;
> @@ -414,8 +376,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>   * @base: start address of the memory region
>   * @length: size of the memory region
>   *
> - * This function is called for each memory range in /proc/iomem, and stores
> - * the location of the crash kernel range into @crash_reserved_mem.
> + * This function is called for each memory range in /proc/iomem, stores
> + * the location of the crash kernel range into @crash_reserved_mem, and
> + * stores the system RAM into @usablemem_rgns.
>   */
>  static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 char *str, unsigned long long base,
> @@ -426,6 +389,10 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                 crash_reserved_mem.end = base + length - 1;
>                 crash_reserved_mem.type = RANGE_RAM;
>         }
> +       else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
> +               return mem_regions_add(&usablemem_rgns,
> +                                      base, length, RANGE_RAM);
> +       }
>         return 0;
>  }
>
> @@ -434,7 +401,7 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>   *
>   * Check for the crashkernel reserved region in /proc/iomem, and return
>   * true if it is present, or false otherwise. We use this to store the
> - * location of this region.
> + * location of this region, and system RAM regions.
>   */
>  int is_crashkernel_mem_reserved(void)
>  {
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 23/32] arm: move crash system RAM parsing earlier

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/Makefile        |  2 ++
>  kexec/arch/arm/crashdump-arm.c | 51 ++++++++----------------------------------
>  2 files changed, 11 insertions(+), 42 deletions(-)
>
> diff --git a/kexec/arch/arm/Makefile b/kexec/arch/arm/Makefile
> index 60e433a..71db8c3 100644
> --- a/kexec/arch/arm/Makefile
> +++ b/kexec/arch/arm/Makefile
> @@ -7,6 +7,8 @@ arm_FS2DT              = kexec/fs2dt.c
>  arm_FS2DT_INCLUDE      = -include $(srcdir)/kexec/arch/arm/crashdump-arm.h \
>                           -include $(srcdir)/kexec/arch/arm/kexec-arm.h
>
> +arm_MEM_REGIONS        = kexec/mem_regions.c
> +
>  arm_KEXEC_SRCS=  kexec/arch/arm/kexec-elf-rel-arm.c
>  arm_KEXEC_SRCS+= kexec/arch/arm/kexec-zImage-arm.c
>  arm_KEXEC_SRCS+= kexec/arch/arm/kexec-uImage-arm.c
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index d6db566..f2e6a0d 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -30,6 +30,7 @@
>  #include "../../kexec.h"
>  #include "../../kexec-elf.h"
>  #include "../../crashdump.h"
> +#include "../../mem_regions.h"
>  #include "crashdump-arm.h"
>  #include "iomem.h"
>
> @@ -132,39 +133,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
>  }
>
>  /**
> - * crash_range_callback() - callback called for each iomem region
> - * @data: not used
> - * @nr: not used
> - * @str: name of the memory region
> - * @base: start address of the memory region
> - * @length: size of the memory region
> - *
> - * This function is called once for each memory region found in /proc/iomem. It
> - * locates system RAM and places these into @crash_memory_ranges. Number of
> - * memory regions is placed in @crash_memory_nr_ranges.
> - */
> -static int crash_range_callback(void *UNUSED(data), int UNUSED(nr),
> -                               char *str, unsigned long long base,
> -                               unsigned long long length)
> -{
> -       struct memory_range *range;
> -
> -       if (usablemem_rgns.size >= CRASH_MAX_MEMORY_RANGES)
> -               return 1;
> -
> -       range = usablemem_rgns.ranges + usablemem_rgns.size;
> -
> -       if (strncmp(str, "System RAM\n", 11) == 0) {
> -               range->start = base;
> -               range->end = base + length - 1;
> -               range->type = RANGE_RAM;
> -               usablemem_rgns.size++;
> -       }
> -
> -       return 0;
> -}
> -
> -/**
>   * crash_exclude_range() - excludes memory region reserved for crashkernel
>   *
>   * Function locates where crashkernel reserved memory is and removes that region
> @@ -213,12 +181,6 @@ static void crash_exclude_range(void)
>   */
>  static int crash_get_memory_ranges(void)
>  {
> -       /*
> -        * First read all memory regions that can be considered as
> -        * system memory including the crash area.
> -        */
> -       kexec_iomem_for_each_line(NULL, crash_range_callback, NULL);
> -
>         if (usablemem_rgns.size < 1) {
>                 errno = EINVAL;
>                 return -1;
> @@ -414,8 +376,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>   * @base: start address of the memory region
>   * @length: size of the memory region
>   *
> - * This function is called for each memory range in /proc/iomem, and stores
> - * the location of the crash kernel range into @crash_reserved_mem.
> + * This function is called for each memory range in /proc/iomem, stores
> + * the location of the crash kernel range into @crash_reserved_mem, and
> + * stores the system RAM into @usablemem_rgns.
>   */
>  static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 char *str, unsigned long long base,
> @@ -426,6 +389,10 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                 crash_reserved_mem.end = base + length - 1;
>                 crash_reserved_mem.type = RANGE_RAM;
>         }
> +       else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
> +               return mem_regions_add(&usablemem_rgns,
> +                                      base, length, RANGE_RAM);
> +       }
>         return 0;
>  }
>
> @@ -434,7 +401,7 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>   *
>   * Check for the crashkernel reserved region in /proc/iomem, and return
>   * true if it is present, or false otherwise. We use this to store the
> - * location of this region.
> + * location of this region, and system RAM regions.
>   */
>  int is_crashkernel_mem_reserved(void)
>  {
> --
> 1.9.1
>

[PATCH kexec-tools 24/32] arm: add support for platforms with boot memory aliases

[Russell King]

The kexec API deals with boot-view addresses, rather than normal system
view addresses.  This causes problems for platforms such as Keystone 2,
where the boot view is substantially different from the normal system
view.

This is because Keystone 2 boots from a memory alias in the lower 4GiB,
before switching to a high alias at 32GiB.

We handle this in a generic way by introducing boot alias resources in
/proc/iomem:

80000000-dfffffff : System RAM (boot alias)
  9f800000-9fffffff : Crash kernel (boot alias)
800000000-85fffffff : System RAM
  800008000-800790e37 : Kernel code
  8007ec000-8008b856f : Kernel data
  81f800000-81fffffff : Crash kernel

To allow kexec to load a kernel, we need to add the boot alias of RAM
to the memory ranges returned by get_memory_ranges().  Parse the
system RAM boot alias into the memory ranges.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/iomem.h     | 2 ++
 kexec/arch/arm/kexec-arm.c | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
index 81c593d..85f958e 100644
--- a/kexec/arch/arm/iomem.h
+++ b/kexec/arch/arm/iomem.h
@@ -2,6 +2,8 @@
 #define IOMEM_H
 
 #define SYSTEM_RAM		"System RAM\n"
+#define SYSTEM_RAM_BOOT		"System RAM (boot alias)\n"
 #define CRASH_KERNEL		"Crash kernel\n"
+#define CRASH_KERNEL_BOOT	"Crash kernel (boot alias)\n"
 
 #endif
diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index eeb27b4..2194b7c 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -18,6 +18,7 @@
 #include "kexec-arm.h"
 #include <arch/options.h>
 #include "../../fs2dt.h"
+#include "iomem.h"
 
 #define MAX_MEMORY_RANGES 64
 #define MAX_LINE 160
@@ -52,7 +53,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 			continue;
 		str = line + consumed;
 
-		if (memcmp(str, "System RAM\n", 11) == 0) {
+		if (memcmp(str, SYSTEM_RAM_BOOT, strlen(SYSTEM_RAM_BOOT)) == 0 ||
+		    memcmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 			type = RANGE_RAM;
 		}
 		else if (memcmp(str, "reserved\n", 9) == 0) {
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 24/32] arm: add support for platforms with boot memory aliases

[Russell King]

The kexec API deals with boot-view addresses, rather than normal system
view addresses.  This causes problems for platforms such as Keystone 2,
where the boot view is substantially different from the normal system
view.

This is because Keystone 2 boots from a memory alias in the lower 4GiB,
before switching to a high alias at 32GiB.

We handle this in a generic way by introducing boot alias resources in
/proc/iomem:

80000000-dfffffff : System RAM (boot alias)
  9f800000-9fffffff : Crash kernel (boot alias)
800000000-85fffffff : System RAM
  800008000-800790e37 : Kernel code
  8007ec000-8008b856f : Kernel data
  81f800000-81fffffff : Crash kernel

To allow kexec to load a kernel, we need to add the boot alias of RAM
to the memory ranges returned by get_memory_ranges().  Parse the
system RAM boot alias into the memory ranges.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/iomem.h     | 2 ++
 kexec/arch/arm/kexec-arm.c | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
index 81c593d..85f958e 100644
--- a/kexec/arch/arm/iomem.h
+++ b/kexec/arch/arm/iomem.h
@@ -2,6 +2,8 @@
 #define IOMEM_H
 
 #define SYSTEM_RAM		"System RAM\n"
+#define SYSTEM_RAM_BOOT		"System RAM (boot alias)\n"
 #define CRASH_KERNEL		"Crash kernel\n"
+#define CRASH_KERNEL_BOOT	"Crash kernel (boot alias)\n"
 
 #endif
diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
index eeb27b4..2194b7c 100644
--- a/kexec/arch/arm/kexec-arm.c
+++ b/kexec/arch/arm/kexec-arm.c
@@ -18,6 +18,7 @@
 #include "kexec-arm.h"
 #include <arch/options.h>
 #include "../../fs2dt.h"
+#include "iomem.h"
 
 #define MAX_MEMORY_RANGES 64
 #define MAX_LINE 160
@@ -52,7 +53,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 			continue;
 		str = line + consumed;
 
-		if (memcmp(str, "System RAM\n", 11) == 0) {
+		if (memcmp(str, SYSTEM_RAM_BOOT, strlen(SYSTEM_RAM_BOOT)) == 0 ||
+		    memcmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 			type = RANGE_RAM;
 		}
 		else if (memcmp(str, "reserved\n", 9) == 0) {
-- 
1.9.1

Re: [PATCH kexec-tools 24/32] arm: add support for platforms with boot memory aliases

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> The kexec API deals with boot-view addresses, rather than normal system
> view addresses.  This causes problems for platforms such as Keystone 2,
> where the boot view is substantially different from the normal system
> view.
>
> This is because Keystone 2 boots from a memory alias in the lower 4GiB,
> before switching to a high alias at 32GiB.
>
> We handle this in a generic way by introducing boot alias resources in
> /proc/iomem:
>
> 80000000-dfffffff : System RAM (boot alias)
>   9f800000-9fffffff : Crash kernel (boot alias)
> 800000000-85fffffff : System RAM
>   800008000-800790e37 : Kernel code
>   8007ec000-8008b856f : Kernel data
>   81f800000-81fffffff : Crash kernel
>
> To allow kexec to load a kernel, we need to add the boot alias of RAM
> to the memory ranges returned by get_memory_ranges().  Parse the
> system RAM boot alias into the memory ranges.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/iomem.h     | 2 ++
>  kexec/arch/arm/kexec-arm.c | 4 +++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
> index 81c593d..85f958e 100644
> --- a/kexec/arch/arm/iomem.h
> +++ b/kexec/arch/arm/iomem.h
> @@ -2,6 +2,8 @@
>  #define IOMEM_H
>
>  #define SYSTEM_RAM             "System RAM\n"
> +#define SYSTEM_RAM_BOOT                "System RAM (boot alias)\n"
>  #define CRASH_KERNEL           "Crash kernel\n"
> +#define CRASH_KERNEL_BOOT      "Crash kernel (boot alias)\n"
>
>  #endif
> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
> index eeb27b4..2194b7c 100644
> --- a/kexec/arch/arm/kexec-arm.c
> +++ b/kexec/arch/arm/kexec-arm.c
> @@ -18,6 +18,7 @@
>  #include "kexec-arm.h"
>  #include <arch/options.h>
>  #include "../../fs2dt.h"
> +#include "iomem.h"
>
>  #define MAX_MEMORY_RANGES 64
>  #define MAX_LINE 160
> @@ -52,7 +53,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>                         continue;
>                 str = line + consumed;
>
> -               if (memcmp(str, "System RAM\n", 11) == 0) {
> +               if (memcmp(str, SYSTEM_RAM_BOOT, strlen(SYSTEM_RAM_BOOT)) == 0 ||
> +                   memcmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                         type = RANGE_RAM;
>                 }
>                 else if (memcmp(str, "reserved\n", 9) == 0) {
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 24/32] arm: add support for platforms with boot memory aliases

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> The kexec API deals with boot-view addresses, rather than normal system
> view addresses.  This causes problems for platforms such as Keystone 2,
> where the boot view is substantially different from the normal system
> view.
>
> This is because Keystone 2 boots from a memory alias in the lower 4GiB,
> before switching to a high alias at 32GiB.
>
> We handle this in a generic way by introducing boot alias resources in
> /proc/iomem:
>
> 80000000-dfffffff : System RAM (boot alias)
>   9f800000-9fffffff : Crash kernel (boot alias)
> 800000000-85fffffff : System RAM
>   800008000-800790e37 : Kernel code
>   8007ec000-8008b856f : Kernel data
>   81f800000-81fffffff : Crash kernel
>
> To allow kexec to load a kernel, we need to add the boot alias of RAM
> to the memory ranges returned by get_memory_ranges().  Parse the
> system RAM boot alias into the memory ranges.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/iomem.h     | 2 ++
>  kexec/arch/arm/kexec-arm.c | 4 +++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/iomem.h b/kexec/arch/arm/iomem.h
> index 81c593d..85f958e 100644
> --- a/kexec/arch/arm/iomem.h
> +++ b/kexec/arch/arm/iomem.h
> @@ -2,6 +2,8 @@
>  #define IOMEM_H
>
>  #define SYSTEM_RAM             "System RAM\n"
> +#define SYSTEM_RAM_BOOT                "System RAM (boot alias)\n"
>  #define CRASH_KERNEL           "Crash kernel\n"
> +#define CRASH_KERNEL_BOOT      "Crash kernel (boot alias)\n"
>
>  #endif
> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
> index eeb27b4..2194b7c 100644
> --- a/kexec/arch/arm/kexec-arm.c
> +++ b/kexec/arch/arm/kexec-arm.c
> @@ -18,6 +18,7 @@
>  #include "kexec-arm.h"
>  #include <arch/options.h>
>  #include "../../fs2dt.h"
> +#include "iomem.h"
>
>  #define MAX_MEMORY_RANGES 64
>  #define MAX_LINE 160
> @@ -52,7 +53,8 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>                         continue;
>                 str = line + consumed;
>
> -               if (memcmp(str, "System RAM\n", 11) == 0) {
> +               if (memcmp(str, SYSTEM_RAM_BOOT, strlen(SYSTEM_RAM_BOOT)) == 0 ||
> +                   memcmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                         type = RANGE_RAM;
>                 }
>                 else if (memcmp(str, "reserved\n", 9) == 0) {
> --
> 1.9.1
>

[PATCH kexec-tools 25/32] arm: crashdump needs boot alias of crash kernel region

[Russell King]

When crashdumping, we need the boot memory alias of the crash kernel
region rather than the system view.  Arrange to check for the boot
alias of the crash kernel region first, and if found, use it instead
of the main alias.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
index 4755f06..fdd2910 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -20,6 +20,7 @@
 #include "kexec-arm.h"
 #include "../../fs2dt.h"
 #include "crashdump-arm.h"
+#include "iomem.h"
 
 #define BOOT_PARAMS_SIZE 1536
 
@@ -446,7 +447,8 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
 		 * We put the dump capture kernel at the start of crashkernel
 		 * reserved memory.
 		 */
-		if (parse_iomem_single("Crash kernel\n", &start, &end)) {
+		if (parse_iomem_single(CRASH_KERNEL_BOOT, &start, &end) &&
+		    parse_iomem_single(CRASH_KERNEL, &start, &end)) {
 			/*
 			 * No crash kernel memory reserved. We cannot do more
 			 * but just bail out.
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 25/32] arm: crashdump needs boot alias of crash kernel region

[Russell King]

When crashdumping, we need the boot memory alias of the crash kernel
region rather than the system view.  Arrange to check for the boot
alias of the crash kernel region first, and if found, use it instead
of the main alias.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/kexec-zImage-arm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
index 4755f06..fdd2910 100644
--- a/kexec/arch/arm/kexec-zImage-arm.c
+++ b/kexec/arch/arm/kexec-zImage-arm.c
@@ -20,6 +20,7 @@
 #include "kexec-arm.h"
 #include "../../fs2dt.h"
 #include "crashdump-arm.h"
+#include "iomem.h"
 
 #define BOOT_PARAMS_SIZE 1536
 
@@ -446,7 +447,8 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
 		 * We put the dump capture kernel at the start of crashkernel
 		 * reserved memory.
 		 */
-		if (parse_iomem_single("Crash kernel\n", &start, &end)) {
+		if (parse_iomem_single(CRASH_KERNEL_BOOT, &start, &end) &&
+		    parse_iomem_single(CRASH_KERNEL, &start, &end)) {
 			/*
 			 * No crash kernel memory reserved. We cannot do more
 			 * but just bail out.
-- 
1.9.1

Re: [PATCH kexec-tools 25/32] arm: crashdump needs boot alias of crash kernel region

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> When crashdumping, we need the boot memory alias of the crash kernel
> region rather than the system view.  Arrange to check for the boot
> alias of the crash kernel region first, and if found, use it instead
> of the main alias.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-zImage-arm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
> index 4755f06..fdd2910 100644
> --- a/kexec/arch/arm/kexec-zImage-arm.c
> +++ b/kexec/arch/arm/kexec-zImage-arm.c
> @@ -20,6 +20,7 @@
>  #include "kexec-arm.h"
>  #include "../../fs2dt.h"
>  #include "crashdump-arm.h"
> +#include "iomem.h"
>
>  #define BOOT_PARAMS_SIZE 1536
>
> @@ -446,7 +447,8 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
>                  * We put the dump capture kernel at the start of crashkernel
>                  * reserved memory.
>                  */
> -               if (parse_iomem_single("Crash kernel\n", &start, &end)) {
> +               if (parse_iomem_single(CRASH_KERNEL_BOOT, &start, &end) &&
> +                   parse_iomem_single(CRASH_KERNEL, &start, &end)) {
>                         /*
>                          * No crash kernel memory reserved. We cannot do more
>                          * but just bail out.
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 25/32] arm: crashdump needs boot alias of crash kernel region

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> When crashdumping, we need the boot memory alias of the crash kernel
> region rather than the system view.  Arrange to check for the boot
> alias of the crash kernel region first, and if found, use it instead
> of the main alias.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/kexec-zImage-arm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c
> index 4755f06..fdd2910 100644
> --- a/kexec/arch/arm/kexec-zImage-arm.c
> +++ b/kexec/arch/arm/kexec-zImage-arm.c
> @@ -20,6 +20,7 @@
>  #include "kexec-arm.h"
>  #include "../../fs2dt.h"
>  #include "crashdump-arm.h"
> +#include "iomem.h"
>
>  #define BOOT_PARAMS_SIZE 1536
>
> @@ -446,7 +447,8 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len,
>                  * We put the dump capture kernel at the start of crashkernel
>                  * reserved memory.
>                  */
> -               if (parse_iomem_single("Crash kernel\n", &start, &end)) {
> +               if (parse_iomem_single(CRASH_KERNEL_BOOT, &start, &end) &&
> +                   parse_iomem_single(CRASH_KERNEL, &start, &end)) {
>                         /*
>                          * No crash kernel memory reserved. We cannot do more
>                          * but just bail out.
> --
> 1.9.1
>

[PATCH kexec-tools 26/32] arm: rename crash_reserved_mem to crash_kernel_mem

[Russell King]

Rename crash_reserved_mem to crash_kernel_mem as we want to support
multiple reserved memory ranges.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index f2e6a0d..1a6ab88 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -53,7 +53,7 @@ struct memory_ranges usablemem_rgns = {
 };
 
 /* memory range reserved for crashkernel */
-static struct memory_range crash_reserved_mem;
+static struct memory_range crash_kernel_mem;
 
 static struct crash_elf_info elf_info = {
 	.class		= ELFCLASS32,
@@ -140,7 +140,7 @@ static int get_kernel_page_offset(struct kexec_info *info,
  */
 static void crash_exclude_range(void)
 {
-	const struct memory_range *range = &crash_reserved_mem;
+	const struct memory_range *range = &crash_kernel_mem;
 	int i;
 
 	for (i = 0; i < usablemem_rgns.size; i++) {
@@ -262,8 +262,8 @@ static void dump_memory_ranges(void)
 		return;
 
 	dbgprintf("crashkernel: [%#llx - %#llx] (%ldM)\n",
-		  crash_reserved_mem.start, crash_reserved_mem.end,
-		  (unsigned long)range_size(&crash_reserved_mem) >> 20);
+		  crash_kernel_mem.start, crash_kernel_mem.end,
+		  (unsigned long)range_size(&crash_kernel_mem) >> 20);
 
 	for (i = 0; i < usablemem_rgns.size; i++) {
 		struct memory_range *r = usablemem_rgns.ranges + i;
@@ -313,10 +313,10 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * Ensure that the crash kernel memory range is sane. The crash kernel
 	 * must be located within memory which is visible during booting.
 	 */
-	if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
+	if (crash_kernel_mem.end > ARM_MAX_VIRTUAL) {
 		fprintf(stderr,
 			"Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
-			crash_reserved_mem.start, crash_reserved_mem.end);
+			crash_kernel_mem.start, crash_kernel_mem.end);
 		return -1;
 	}
 
@@ -349,8 +349,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * regions to be aligned to SECTION_SIZE.
 	 */
 	elfcorehdr = add_buffer_phys_virt(info, buf, bufsz, bufsz, 1 << 20,
-					  crash_reserved_mem.start,
-					  crash_reserved_mem.end, -1, 0);
+					  crash_kernel_mem.start,
+					  crash_kernel_mem.end, -1, 0);
 
 	dbgprintf("elfcorehdr: %#lx\n", elfcorehdr);
 	cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
@@ -360,7 +360,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * prevents the dump capture kernel from using any other memory regions
 	 * which belong to the primary kernel.
 	 */
-	cmdline_add_mem(mod_cmdline, elfcorehdr - crash_reserved_mem.start);
+	cmdline_add_mem(mod_cmdline, elfcorehdr - crash_kernel_mem.start);
 
 	dump_memory_ranges();
 	dbgprintf("kernel command line: \"%s\"\n", mod_cmdline);
@@ -377,7 +377,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
  * @length: size of the memory region
  *
  * This function is called for each memory range in /proc/iomem, stores
- * the location of the crash kernel range into @crash_reserved_mem, and
+ * the location of the crash kernel range into @crash_kernel_mem, and
  * stores the system RAM into @usablemem_rgns.
  */
 static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
@@ -385,9 +385,9 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 				unsigned long long length)
 {
 	if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
-		crash_reserved_mem.start = base;
-		crash_reserved_mem.end = base + length - 1;
-		crash_reserved_mem.type = RANGE_RAM;
+		crash_kernel_mem.start = base;
+		crash_kernel_mem.end = base + length - 1;
+		crash_kernel_mem.type = RANGE_RAM;
 	}
 	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 		return mem_regions_add(&usablemem_rgns,
@@ -407,5 +407,5 @@ int is_crashkernel_mem_reserved(void)
 {
 	kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
 
-	return crash_reserved_mem.start != crash_reserved_mem.end;
+	return crash_kernel_mem.start != crash_kernel_mem.end;
 }
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 26/32] arm: rename crash_reserved_mem to crash_kernel_mem

[Russell King]

Rename crash_reserved_mem to crash_kernel_mem as we want to support
multiple reserved memory ranges.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index f2e6a0d..1a6ab88 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -53,7 +53,7 @@ struct memory_ranges usablemem_rgns = {
 };
 
 /* memory range reserved for crashkernel */
-static struct memory_range crash_reserved_mem;
+static struct memory_range crash_kernel_mem;
 
 static struct crash_elf_info elf_info = {
 	.class		= ELFCLASS32,
@@ -140,7 +140,7 @@ static int get_kernel_page_offset(struct kexec_info *info,
  */
 static void crash_exclude_range(void)
 {
-	const struct memory_range *range = &crash_reserved_mem;
+	const struct memory_range *range = &crash_kernel_mem;
 	int i;
 
 	for (i = 0; i < usablemem_rgns.size; i++) {
@@ -262,8 +262,8 @@ static void dump_memory_ranges(void)
 		return;
 
 	dbgprintf("crashkernel: [%#llx - %#llx] (%ldM)\n",
-		  crash_reserved_mem.start, crash_reserved_mem.end,
-		  (unsigned long)range_size(&crash_reserved_mem) >> 20);
+		  crash_kernel_mem.start, crash_kernel_mem.end,
+		  (unsigned long)range_size(&crash_kernel_mem) >> 20);
 
 	for (i = 0; i < usablemem_rgns.size; i++) {
 		struct memory_range *r = usablemem_rgns.ranges + i;
@@ -313,10 +313,10 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * Ensure that the crash kernel memory range is sane. The crash kernel
 	 * must be located within memory which is visible during booting.
 	 */
-	if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
+	if (crash_kernel_mem.end > ARM_MAX_VIRTUAL) {
 		fprintf(stderr,
 			"Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
-			crash_reserved_mem.start, crash_reserved_mem.end);
+			crash_kernel_mem.start, crash_kernel_mem.end);
 		return -1;
 	}
 
@@ -349,8 +349,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * regions to be aligned to SECTION_SIZE.
 	 */
 	elfcorehdr = add_buffer_phys_virt(info, buf, bufsz, bufsz, 1 << 20,
-					  crash_reserved_mem.start,
-					  crash_reserved_mem.end, -1, 0);
+					  crash_kernel_mem.start,
+					  crash_kernel_mem.end, -1, 0);
 
 	dbgprintf("elfcorehdr: %#lx\n", elfcorehdr);
 	cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
@@ -360,7 +360,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * prevents the dump capture kernel from using any other memory regions
 	 * which belong to the primary kernel.
 	 */
-	cmdline_add_mem(mod_cmdline, elfcorehdr - crash_reserved_mem.start);
+	cmdline_add_mem(mod_cmdline, elfcorehdr - crash_kernel_mem.start);
 
 	dump_memory_ranges();
 	dbgprintf("kernel command line: \"%s\"\n", mod_cmdline);
@@ -377,7 +377,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
  * @length: size of the memory region
  *
  * This function is called for each memory range in /proc/iomem, stores
- * the location of the crash kernel range into @crash_reserved_mem, and
+ * the location of the crash kernel range into @crash_kernel_mem, and
  * stores the system RAM into @usablemem_rgns.
  */
 static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
@@ -385,9 +385,9 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 				unsigned long long length)
 {
 	if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
-		crash_reserved_mem.start = base;
-		crash_reserved_mem.end = base + length - 1;
-		crash_reserved_mem.type = RANGE_RAM;
+		crash_kernel_mem.start = base;
+		crash_kernel_mem.end = base + length - 1;
+		crash_kernel_mem.type = RANGE_RAM;
 	}
 	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 		return mem_regions_add(&usablemem_rgns,
@@ -407,5 +407,5 @@ int is_crashkernel_mem_reserved(void)
 {
 	kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
 
-	return crash_reserved_mem.start != crash_reserved_mem.end;
+	return crash_kernel_mem.start != crash_kernel_mem.end;
 }
-- 
1.9.1

Re: [PATCH kexec-tools 26/32] arm: rename crash_reserved_mem to crash_kernel_mem

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Rename crash_reserved_mem to crash_kernel_mem as we want to support
> multiple reserved memory ranges.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 28 ++++++++++++++--------------
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index f2e6a0d..1a6ab88 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -53,7 +53,7 @@ struct memory_ranges usablemem_rgns = {
>  };
>
>  /* memory range reserved for crashkernel */
> -static struct memory_range crash_reserved_mem;
> +static struct memory_range crash_kernel_mem;
>
>  static struct crash_elf_info elf_info = {
>         .class          = ELFCLASS32,
> @@ -140,7 +140,7 @@ static int get_kernel_page_offset(struct kexec_info *info,
>   */
>  static void crash_exclude_range(void)
>  {
> -       const struct memory_range *range = &crash_reserved_mem;
> +       const struct memory_range *range = &crash_kernel_mem;
>         int i;
>
>         for (i = 0; i < usablemem_rgns.size; i++) {
> @@ -262,8 +262,8 @@ static void dump_memory_ranges(void)
>                 return;
>
>         dbgprintf("crashkernel: [%#llx - %#llx] (%ldM)\n",
> -                 crash_reserved_mem.start, crash_reserved_mem.end,
> -                 (unsigned long)range_size(&crash_reserved_mem) >> 20);
> +                 crash_kernel_mem.start, crash_kernel_mem.end,
> +                 (unsigned long)range_size(&crash_kernel_mem) >> 20);
>
>         for (i = 0; i < usablemem_rgns.size; i++) {
>                 struct memory_range *r = usablemem_rgns.ranges + i;
> @@ -313,10 +313,10 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * Ensure that the crash kernel memory range is sane. The crash kernel
>          * must be located within memory which is visible during booting.
>          */
> -       if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
> +       if (crash_kernel_mem.end > ARM_MAX_VIRTUAL) {
>                 fprintf(stderr,
>                         "Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
> -                       crash_reserved_mem.start, crash_reserved_mem.end);
> +                       crash_kernel_mem.start, crash_kernel_mem.end);
>                 return -1;
>         }
>
> @@ -349,8 +349,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * regions to be aligned to SECTION_SIZE.
>          */
>         elfcorehdr = add_buffer_phys_virt(info, buf, bufsz, bufsz, 1 << 20,
> -                                         crash_reserved_mem.start,
> -                                         crash_reserved_mem.end, -1, 0);
> +                                         crash_kernel_mem.start,
> +                                         crash_kernel_mem.end, -1, 0);
>
>         dbgprintf("elfcorehdr: %#lx\n", elfcorehdr);
>         cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
> @@ -360,7 +360,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * prevents the dump capture kernel from using any other memory regions
>          * which belong to the primary kernel.
>          */
> -       cmdline_add_mem(mod_cmdline, elfcorehdr - crash_reserved_mem.start);
> +       cmdline_add_mem(mod_cmdline, elfcorehdr - crash_kernel_mem.start);
>
>         dump_memory_ranges();
>         dbgprintf("kernel command line: \"%s\"\n", mod_cmdline);
> @@ -377,7 +377,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>   * @length: size of the memory region
>   *
>   * This function is called for each memory range in /proc/iomem, stores
> - * the location of the crash kernel range into @crash_reserved_mem, and
> + * the location of the crash kernel range into @crash_kernel_mem, and
>   * stores the system RAM into @usablemem_rgns.
>   */
>  static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
> @@ -385,9 +385,9 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 unsigned long long length)
>  {
>         if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> -               crash_reserved_mem.start = base;
> -               crash_reserved_mem.end = base + length - 1;
> -               crash_reserved_mem.type = RANGE_RAM;
> +               crash_kernel_mem.start = base;
> +               crash_kernel_mem.end = base + length - 1;
> +               crash_kernel_mem.type = RANGE_RAM;
>         }
>         else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                 return mem_regions_add(&usablemem_rgns,
> @@ -407,5 +407,5 @@ int is_crashkernel_mem_reserved(void)
>  {
>         kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
>
> -       return crash_reserved_mem.start != crash_reserved_mem.end;
> +       return crash_kernel_mem.start != crash_kernel_mem.end;
>  }
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 26/32] arm: rename crash_reserved_mem to crash_kernel_mem

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Rename crash_reserved_mem to crash_kernel_mem as we want to support
> multiple reserved memory ranges.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 28 ++++++++++++++--------------
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index f2e6a0d..1a6ab88 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -53,7 +53,7 @@ struct memory_ranges usablemem_rgns = {
>  };
>
>  /* memory range reserved for crashkernel */
> -static struct memory_range crash_reserved_mem;
> +static struct memory_range crash_kernel_mem;
>
>  static struct crash_elf_info elf_info = {
>         .class          = ELFCLASS32,
> @@ -140,7 +140,7 @@ static int get_kernel_page_offset(struct kexec_info *info,
>   */
>  static void crash_exclude_range(void)
>  {
> -       const struct memory_range *range = &crash_reserved_mem;
> +       const struct memory_range *range = &crash_kernel_mem;
>         int i;
>
>         for (i = 0; i < usablemem_rgns.size; i++) {
> @@ -262,8 +262,8 @@ static void dump_memory_ranges(void)
>                 return;
>
>         dbgprintf("crashkernel: [%#llx - %#llx] (%ldM)\n",
> -                 crash_reserved_mem.start, crash_reserved_mem.end,
> -                 (unsigned long)range_size(&crash_reserved_mem) >> 20);
> +                 crash_kernel_mem.start, crash_kernel_mem.end,
> +                 (unsigned long)range_size(&crash_kernel_mem) >> 20);
>
>         for (i = 0; i < usablemem_rgns.size; i++) {
>                 struct memory_range *r = usablemem_rgns.ranges + i;
> @@ -313,10 +313,10 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * Ensure that the crash kernel memory range is sane. The crash kernel
>          * must be located within memory which is visible during booting.
>          */
> -       if (crash_reserved_mem.end > ARM_MAX_VIRTUAL) {
> +       if (crash_kernel_mem.end > ARM_MAX_VIRTUAL) {
>                 fprintf(stderr,
>                         "Crash kernel memory [0x%llx-0x%llx] is inaccessible at boot - unable to load crash kernel\n",
> -                       crash_reserved_mem.start, crash_reserved_mem.end);
> +                       crash_kernel_mem.start, crash_kernel_mem.end);
>                 return -1;
>         }
>
> @@ -349,8 +349,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * regions to be aligned to SECTION_SIZE.
>          */
>         elfcorehdr = add_buffer_phys_virt(info, buf, bufsz, bufsz, 1 << 20,
> -                                         crash_reserved_mem.start,
> -                                         crash_reserved_mem.end, -1, 0);
> +                                         crash_kernel_mem.start,
> +                                         crash_kernel_mem.end, -1, 0);
>
>         dbgprintf("elfcorehdr: %#lx\n", elfcorehdr);
>         cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
> @@ -360,7 +360,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * prevents the dump capture kernel from using any other memory regions
>          * which belong to the primary kernel.
>          */
> -       cmdline_add_mem(mod_cmdline, elfcorehdr - crash_reserved_mem.start);
> +       cmdline_add_mem(mod_cmdline, elfcorehdr - crash_kernel_mem.start);
>
>         dump_memory_ranges();
>         dbgprintf("kernel command line: \"%s\"\n", mod_cmdline);
> @@ -377,7 +377,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>   * @length: size of the memory region
>   *
>   * This function is called for each memory range in /proc/iomem, stores
> - * the location of the crash kernel range into @crash_reserved_mem, and
> + * the location of the crash kernel range into @crash_kernel_mem, and
>   * stores the system RAM into @usablemem_rgns.
>   */
>  static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
> @@ -385,9 +385,9 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 unsigned long long length)
>  {
>         if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> -               crash_reserved_mem.start = base;
> -               crash_reserved_mem.end = base + length - 1;
> -               crash_reserved_mem.type = RANGE_RAM;
> +               crash_kernel_mem.start = base;
> +               crash_kernel_mem.end = base + length - 1;
> +               crash_kernel_mem.type = RANGE_RAM;
>         }
>         else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                 return mem_regions_add(&usablemem_rgns,
> @@ -407,5 +407,5 @@ int is_crashkernel_mem_reserved(void)
>  {
>         kexec_iomem_for_each_line(NULL, iomem_range_callback, NULL);
>
> -       return crash_reserved_mem.start != crash_reserved_mem.end;
> +       return crash_kernel_mem.start != crash_kernel_mem.end;
>  }
> --
> 1.9.1
>

[PATCH kexec-tools 27/32] arm: add support for multiple reserved regions

[Russell King]

Add support for reserving multiple memory regions rather than just a
single region.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 66 ++++++++++++++++--------------------------
 1 file changed, 25 insertions(+), 41 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 1a6ab88..9113f5e 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -55,6 +55,14 @@ struct memory_ranges usablemem_rgns = {
 /* memory range reserved for crashkernel */
 static struct memory_range crash_kernel_mem;
 
+/* reserved regions */
+#define CRASH_MAX_RESERVED_RANGES 2
+static struct memory_range crash_reserved_ranges[CRASH_MAX_RESERVED_RANGES];
+static struct memory_ranges crash_reserved_rgns = {
+	.max_size = CRASH_MAX_RESERVED_RANGES,
+	.ranges = crash_reserved_ranges,
+};
+
 static struct crash_elf_info elf_info = {
 	.class		= ELFCLASS32,
 	.data		= ELFDATANATIVE,
@@ -133,44 +141,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 }
 
 /**
- * crash_exclude_range() - excludes memory region reserved for crashkernel
- *
- * Function locates where crashkernel reserved memory is and removes that region
- * from the available memory regions.
- */
-static void crash_exclude_range(void)
-{
-	const struct memory_range *range = &crash_kernel_mem;
-	int i;
-
-	for (i = 0; i < usablemem_rgns.size; i++) {
-		struct memory_range *r = usablemem_rgns.ranges + i;
-
-		/*
-		 * We assume that crash area is fully contained in
-		 * some larger memory area.
-		 */
-		if (r->start <= range->start && r->end >= range->end) {
-			struct memory_range *new;
-			/*
-			 * Let's split this area into 2 smaller ones and
-			 * remove excluded range from between. First create
-			 * new entry for the remaining area.
-			 */
-			new = usablemem_rgns.ranges + usablemem_rgns.size;
-			new->start = range->end + 1;
-			new->end = r->end;
-			usablemem_rgns.size++;
-			/*
-			 * Next update this area to end before excluded range.
-			 */
-			r->end = range->start - 1;
-			break;
-		}
-	}
-}
-
-/**
  * crash_get_memory_ranges() - read system physical memory
  *
  * Function reads through system physical memory and stores found memory regions
@@ -181,16 +151,28 @@ static void crash_exclude_range(void)
  */
 static int crash_get_memory_ranges(void)
 {
+	int i;
+
 	if (usablemem_rgns.size < 1) {
 		errno = EINVAL;
 		return -1;
 	}
 
 	/*
-	 * Exclude memory reserved for crashkernel (this may result a split memory
-	 * region).
+	 * Exclude all reserved memory from the usable memory regions.
+	 * We want to avoid dumping the crashkernel region itself.  Note
+	 * that this may result memory regions in usablemem_rgns being
+	 * split.
 	 */
-	crash_exclude_range();
+	for (i = 0; i < crash_reserved_rgns.size; i++) {
+		if (mem_regions_exclude(&usablemem_rgns,
+					&crash_reserved_rgns.ranges[i])) {
+			fprintf(stderr,
+				"Error: Number of crash memory ranges excedeed the max limit\n");
+			errno = ENOMEM;
+			return -1;
+		}
+	}
 
 	/*
 	 * Make sure that the memory regions are sorted.
@@ -388,6 +370,8 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 		crash_kernel_mem.start = base;
 		crash_kernel_mem.end = base + length - 1;
 		crash_kernel_mem.type = RANGE_RAM;
+		return mem_regions_add(&crash_reserved_rgns,
+				       base, length, RANGE_RAM);
 	}
 	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 		return mem_regions_add(&usablemem_rgns,
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 27/32] arm: add support for multiple reserved regions

[Russell King]

Add support for reserving multiple memory regions rather than just a
single region.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 66 ++++++++++++++++--------------------------
 1 file changed, 25 insertions(+), 41 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 1a6ab88..9113f5e 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -55,6 +55,14 @@ struct memory_ranges usablemem_rgns = {
 /* memory range reserved for crashkernel */
 static struct memory_range crash_kernel_mem;
 
+/* reserved regions */
+#define CRASH_MAX_RESERVED_RANGES 2
+static struct memory_range crash_reserved_ranges[CRASH_MAX_RESERVED_RANGES];
+static struct memory_ranges crash_reserved_rgns = {
+	.max_size = CRASH_MAX_RESERVED_RANGES,
+	.ranges = crash_reserved_ranges,
+};
+
 static struct crash_elf_info elf_info = {
 	.class		= ELFCLASS32,
 	.data		= ELFDATANATIVE,
@@ -133,44 +141,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 }
 
 /**
- * crash_exclude_range() - excludes memory region reserved for crashkernel
- *
- * Function locates where crashkernel reserved memory is and removes that region
- * from the available memory regions.
- */
-static void crash_exclude_range(void)
-{
-	const struct memory_range *range = &crash_kernel_mem;
-	int i;
-
-	for (i = 0; i < usablemem_rgns.size; i++) {
-		struct memory_range *r = usablemem_rgns.ranges + i;
-
-		/*
-		 * We assume that crash area is fully contained in
-		 * some larger memory area.
-		 */
-		if (r->start <= range->start && r->end >= range->end) {
-			struct memory_range *new;
-			/*
-			 * Let's split this area into 2 smaller ones and
-			 * remove excluded range from between. First create
-			 * new entry for the remaining area.
-			 */
-			new = usablemem_rgns.ranges + usablemem_rgns.size;
-			new->start = range->end + 1;
-			new->end = r->end;
-			usablemem_rgns.size++;
-			/*
-			 * Next update this area to end before excluded range.
-			 */
-			r->end = range->start - 1;
-			break;
-		}
-	}
-}
-
-/**
  * crash_get_memory_ranges() - read system physical memory
  *
  * Function reads through system physical memory and stores found memory regions
@@ -181,16 +151,28 @@ static void crash_exclude_range(void)
  */
 static int crash_get_memory_ranges(void)
 {
+	int i;
+
 	if (usablemem_rgns.size < 1) {
 		errno = EINVAL;
 		return -1;
 	}
 
 	/*
-	 * Exclude memory reserved for crashkernel (this may result a split memory
-	 * region).
+	 * Exclude all reserved memory from the usable memory regions.
+	 * We want to avoid dumping the crashkernel region itself.  Note
+	 * that this may result memory regions in usablemem_rgns being
+	 * split.
 	 */
-	crash_exclude_range();
+	for (i = 0; i < crash_reserved_rgns.size; i++) {
+		if (mem_regions_exclude(&usablemem_rgns,
+					&crash_reserved_rgns.ranges[i])) {
+			fprintf(stderr,
+				"Error: Number of crash memory ranges excedeed the max limit\n");
+			errno = ENOMEM;
+			return -1;
+		}
+	}
 
 	/*
 	 * Make sure that the memory regions are sorted.
@@ -388,6 +370,8 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 		crash_kernel_mem.start = base;
 		crash_kernel_mem.end = base + length - 1;
 		crash_kernel_mem.type = RANGE_RAM;
+		return mem_regions_add(&crash_reserved_rgns,
+				       base, length, RANGE_RAM);
 	}
 	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 		return mem_regions_add(&usablemem_rgns,
-- 
1.9.1

Re: [PATCH kexec-tools 27/32] arm: add support for multiple reserved regions

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add support for reserving multiple memory regions rather than just a
> single region.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 66 ++++++++++++++++--------------------------
>  1 file changed, 25 insertions(+), 41 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 1a6ab88..9113f5e 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -55,6 +55,14 @@ struct memory_ranges usablemem_rgns = {
>  /* memory range reserved for crashkernel */
>  static struct memory_range crash_kernel_mem;
>
> +/* reserved regions */
> +#define CRASH_MAX_RESERVED_RANGES 2
> +static struct memory_range crash_reserved_ranges[CRASH_MAX_RESERVED_RANGES];
> +static struct memory_ranges crash_reserved_rgns = {
> +       .max_size = CRASH_MAX_RESERVED_RANGES,
> +       .ranges = crash_reserved_ranges,
> +};
> +
>  static struct crash_elf_info elf_info = {
>         .class          = ELFCLASS32,
>         .data           = ELFDATANATIVE,
> @@ -133,44 +141,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
>  }
>
>  /**
> - * crash_exclude_range() - excludes memory region reserved for crashkernel
> - *
> - * Function locates where crashkernel reserved memory is and removes that region
> - * from the available memory regions.
> - */
> -static void crash_exclude_range(void)
> -{
> -       const struct memory_range *range = &crash_kernel_mem;
> -       int i;
> -
> -       for (i = 0; i < usablemem_rgns.size; i++) {
> -               struct memory_range *r = usablemem_rgns.ranges + i;
> -
> -               /*
> -                * We assume that crash area is fully contained in
> -                * some larger memory area.
> -                */
> -               if (r->start <= range->start && r->end >= range->end) {
> -                       struct memory_range *new;
> -                       /*
> -                        * Let's split this area into 2 smaller ones and
> -                        * remove excluded range from between. First create
> -                        * new entry for the remaining area.
> -                        */
> -                       new = usablemem_rgns.ranges + usablemem_rgns.size;
> -                       new->start = range->end + 1;
> -                       new->end = r->end;
> -                       usablemem_rgns.size++;
> -                       /*
> -                        * Next update this area to end before excluded range.
> -                        */
> -                       r->end = range->start - 1;
> -                       break;
> -               }
> -       }
> -}
> -
> -/**
>   * crash_get_memory_ranges() - read system physical memory
>   *
>   * Function reads through system physical memory and stores found memory regions
> @@ -181,16 +151,28 @@ static void crash_exclude_range(void)
>   */
>  static int crash_get_memory_ranges(void)
>  {
> +       int i;
> +
>         if (usablemem_rgns.size < 1) {
>                 errno = EINVAL;
>                 return -1;
>         }
>
>         /*
> -        * Exclude memory reserved for crashkernel (this may result a split memory
> -        * region).
> +        * Exclude all reserved memory from the usable memory regions.
> +        * We want to avoid dumping the crashkernel region itself.  Note
> +        * that this may result memory regions in usablemem_rgns being
> +        * split.
>          */
> -       crash_exclude_range();
> +       for (i = 0; i < crash_reserved_rgns.size; i++) {
> +               if (mem_regions_exclude(&usablemem_rgns,
> +                                       &crash_reserved_rgns.ranges[i])) {
> +                       fprintf(stderr,
> +                               "Error: Number of crash memory ranges excedeed the max limit\n");
> +                       errno = ENOMEM;
> +                       return -1;
> +               }
> +       }
>
>         /*
>          * Make sure that the memory regions are sorted.
> @@ -388,6 +370,8 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                 crash_kernel_mem.start = base;
>                 crash_kernel_mem.end = base + length - 1;
>                 crash_kernel_mem.type = RANGE_RAM;
> +               return mem_regions_add(&crash_reserved_rgns,
> +                                      base, length, RANGE_RAM);
>         }
>         else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                 return mem_regions_add(&usablemem_rgns,
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 27/32] arm: add support for multiple reserved regions

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add support for reserving multiple memory regions rather than just a
> single region.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 66 ++++++++++++++++--------------------------
>  1 file changed, 25 insertions(+), 41 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 1a6ab88..9113f5e 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -55,6 +55,14 @@ struct memory_ranges usablemem_rgns = {
>  /* memory range reserved for crashkernel */
>  static struct memory_range crash_kernel_mem;
>
> +/* reserved regions */
> +#define CRASH_MAX_RESERVED_RANGES 2
> +static struct memory_range crash_reserved_ranges[CRASH_MAX_RESERVED_RANGES];
> +static struct memory_ranges crash_reserved_rgns = {
> +       .max_size = CRASH_MAX_RESERVED_RANGES,
> +       .ranges = crash_reserved_ranges,
> +};
> +
>  static struct crash_elf_info elf_info = {
>         .class          = ELFCLASS32,
>         .data           = ELFDATANATIVE,
> @@ -133,44 +141,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
>  }
>
>  /**
> - * crash_exclude_range() - excludes memory region reserved for crashkernel
> - *
> - * Function locates where crashkernel reserved memory is and removes that region
> - * from the available memory regions.
> - */
> -static void crash_exclude_range(void)
> -{
> -       const struct memory_range *range = &crash_kernel_mem;
> -       int i;
> -
> -       for (i = 0; i < usablemem_rgns.size; i++) {
> -               struct memory_range *r = usablemem_rgns.ranges + i;
> -
> -               /*
> -                * We assume that crash area is fully contained in
> -                * some larger memory area.
> -                */
> -               if (r->start <= range->start && r->end >= range->end) {
> -                       struct memory_range *new;
> -                       /*
> -                        * Let's split this area into 2 smaller ones and
> -                        * remove excluded range from between. First create
> -                        * new entry for the remaining area.
> -                        */
> -                       new = usablemem_rgns.ranges + usablemem_rgns.size;
> -                       new->start = range->end + 1;
> -                       new->end = r->end;
> -                       usablemem_rgns.size++;
> -                       /*
> -                        * Next update this area to end before excluded range.
> -                        */
> -                       r->end = range->start - 1;
> -                       break;
> -               }
> -       }
> -}
> -
> -/**
>   * crash_get_memory_ranges() - read system physical memory
>   *
>   * Function reads through system physical memory and stores found memory regions
> @@ -181,16 +151,28 @@ static void crash_exclude_range(void)
>   */
>  static int crash_get_memory_ranges(void)
>  {
> +       int i;
> +
>         if (usablemem_rgns.size < 1) {
>                 errno = EINVAL;
>                 return -1;
>         }
>
>         /*
> -        * Exclude memory reserved for crashkernel (this may result a split memory
> -        * region).
> +        * Exclude all reserved memory from the usable memory regions.
> +        * We want to avoid dumping the crashkernel region itself.  Note
> +        * that this may result memory regions in usablemem_rgns being
> +        * split.
>          */
> -       crash_exclude_range();
> +       for (i = 0; i < crash_reserved_rgns.size; i++) {
> +               if (mem_regions_exclude(&usablemem_rgns,
> +                                       &crash_reserved_rgns.ranges[i])) {
> +                       fprintf(stderr,
> +                               "Error: Number of crash memory ranges excedeed the max limit\n");
> +                       errno = ENOMEM;
> +                       return -1;
> +               }
> +       }
>
>         /*
>          * Make sure that the memory regions are sorted.
> @@ -388,6 +370,8 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                 crash_kernel_mem.start = base;
>                 crash_kernel_mem.end = base + length - 1;
>                 crash_kernel_mem.type = RANGE_RAM;
> +               return mem_regions_add(&crash_reserved_rgns,
> +                                      base, length, RANGE_RAM);
>         }
>         else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                 return mem_regions_add(&usablemem_rgns,
> --
> 1.9.1
>

[PATCH kexec-tools 28/32] arm: add support for boot-time crash kernel resource

[Russell King]

Add support for detecting and using the boot-time crash kernel
resource, which is needed for systems which have special boot-time
memory views, such as Keystone 2.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 9113f5e..25fdbe9 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -52,7 +52,7 @@ struct memory_ranges usablemem_rgns = {
 	.ranges = crash_memory_ranges,
 };
 
-/* memory range reserved for crashkernel */
+/* The boot-time physical memory range reserved for crashkernel region */
 static struct memory_range crash_kernel_mem;
 
 /* reserved regions */
@@ -366,13 +366,22 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 				char *str, unsigned long long base,
 				unsigned long long length)
 {
-	if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+	if (strncmp(str, CRASH_KERNEL_BOOT, strlen(CRASH_KERNEL_BOOT)) == 0) {
 		crash_kernel_mem.start = base;
 		crash_kernel_mem.end = base + length - 1;
 		crash_kernel_mem.type = RANGE_RAM;
 		return mem_regions_add(&crash_reserved_rgns,
 				       base, length, RANGE_RAM);
 	}
+	else if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+		if (crash_kernel_mem.start == crash_kernel_mem.end) {
+			crash_kernel_mem.start = base;
+			crash_kernel_mem.end = base + length - 1;
+			crash_kernel_mem.type = RANGE_RAM;
+		}
+		return mem_regions_add(&crash_reserved_rgns,
+				       base, length, RANGE_RAM);
+	}
 	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 		return mem_regions_add(&usablemem_rgns,
 				       base, length, RANGE_RAM);
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 28/32] arm: add support for boot-time crash kernel resource

[Russell King]

Add support for detecting and using the boot-time crash kernel
resource, which is needed for systems which have special boot-time
memory views, such as Keystone 2.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 9113f5e..25fdbe9 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -52,7 +52,7 @@ struct memory_ranges usablemem_rgns = {
 	.ranges = crash_memory_ranges,
 };
 
-/* memory range reserved for crashkernel */
+/* The boot-time physical memory range reserved for crashkernel region */
 static struct memory_range crash_kernel_mem;
 
 /* reserved regions */
@@ -366,13 +366,22 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
 				char *str, unsigned long long base,
 				unsigned long long length)
 {
-	if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+	if (strncmp(str, CRASH_KERNEL_BOOT, strlen(CRASH_KERNEL_BOOT)) == 0) {
 		crash_kernel_mem.start = base;
 		crash_kernel_mem.end = base + length - 1;
 		crash_kernel_mem.type = RANGE_RAM;
 		return mem_regions_add(&crash_reserved_rgns,
 				       base, length, RANGE_RAM);
 	}
+	else if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
+		if (crash_kernel_mem.start == crash_kernel_mem.end) {
+			crash_kernel_mem.start = base;
+			crash_kernel_mem.end = base + length - 1;
+			crash_kernel_mem.type = RANGE_RAM;
+		}
+		return mem_regions_add(&crash_reserved_rgns,
+				       base, length, RANGE_RAM);
+	}
 	else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
 		return mem_regions_add(&usablemem_rgns,
 				       base, length, RANGE_RAM);
-- 
1.9.1

Re: [PATCH kexec-tools 28/32] arm: add support for boot-time crash kernel resource

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add support for detecting and using the boot-time crash kernel
> resource, which is needed for systems which have special boot-time
> memory views, such as Keystone 2.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 9113f5e..25fdbe9 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -52,7 +52,7 @@ struct memory_ranges usablemem_rgns = {
>         .ranges = crash_memory_ranges,
>  };
>
> -/* memory range reserved for crashkernel */
> +/* The boot-time physical memory range reserved for crashkernel region */
>  static struct memory_range crash_kernel_mem;
>
>  /* reserved regions */
> @@ -366,13 +366,22 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 char *str, unsigned long long base,
>                                 unsigned long long length)
>  {
> -       if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> +       if (strncmp(str, CRASH_KERNEL_BOOT, strlen(CRASH_KERNEL_BOOT)) == 0) {
>                 crash_kernel_mem.start = base;
>                 crash_kernel_mem.end = base + length - 1;
>                 crash_kernel_mem.type = RANGE_RAM;
>                 return mem_regions_add(&crash_reserved_rgns,
>                                        base, length, RANGE_RAM);
>         }
> +       else if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> +               if (crash_kernel_mem.start == crash_kernel_mem.end) {
> +                       crash_kernel_mem.start = base;
> +                       crash_kernel_mem.end = base + length - 1;
> +                       crash_kernel_mem.type = RANGE_RAM;
> +               }
> +               return mem_regions_add(&crash_reserved_rgns,
> +                                      base, length, RANGE_RAM);
> +       }
>         else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                 return mem_regions_add(&usablemem_rgns,
>                                        base, length, RANGE_RAM);
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 28/32] arm: add support for boot-time crash kernel resource

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add support for detecting and using the boot-time crash kernel
> resource, which is needed for systems which have special boot-time
> memory views, such as Keystone 2.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 9113f5e..25fdbe9 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -52,7 +52,7 @@ struct memory_ranges usablemem_rgns = {
>         .ranges = crash_memory_ranges,
>  };
>
> -/* memory range reserved for crashkernel */
> +/* The boot-time physical memory range reserved for crashkernel region */
>  static struct memory_range crash_kernel_mem;
>
>  /* reserved regions */
> @@ -366,13 +366,22 @@ static int iomem_range_callback(void *UNUSED(data), int UNUSED(nr),
>                                 char *str, unsigned long long base,
>                                 unsigned long long length)
>  {
> -       if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> +       if (strncmp(str, CRASH_KERNEL_BOOT, strlen(CRASH_KERNEL_BOOT)) == 0) {
>                 crash_kernel_mem.start = base;
>                 crash_kernel_mem.end = base + length - 1;
>                 crash_kernel_mem.type = RANGE_RAM;
>                 return mem_regions_add(&crash_reserved_rgns,
>                                        base, length, RANGE_RAM);
>         }
> +       else if (strncmp(str, CRASH_KERNEL, strlen(CRASH_KERNEL)) == 0) {
> +               if (crash_kernel_mem.start == crash_kernel_mem.end) {
> +                       crash_kernel_mem.start = base;
> +                       crash_kernel_mem.end = base + length - 1;
> +                       crash_kernel_mem.type = RANGE_RAM;
> +               }
> +               return mem_regions_add(&crash_reserved_rgns,
> +                                      base, length, RANGE_RAM);
> +       }
>         else if (strncmp(str, SYSTEM_RAM, strlen(SYSTEM_RAM)) == 0) {
>                 return mem_regions_add(&usablemem_rgns,
>                                        base, length, RANGE_RAM);
> --
> 1.9.1
>

[PATCH kexec-tools 29/32] arm: add debug of reserved and coredump memory ranges

[Russell King]

Add debug of the reserved and coredump memory ranges for validation.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 25fdbe9..2dc8846 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -158,6 +158,10 @@ static int crash_get_memory_ranges(void)
 		return -1;
 	}
 
+	dbgprint_mem_range("Reserved memory ranges",
+			   crash_reserved_rgns.ranges,
+			   crash_reserved_rgns.size);
+
 	/*
 	 * Exclude all reserved memory from the usable memory regions.
 	 * We want to avoid dumping the crashkernel region itself.  Note
@@ -179,6 +183,9 @@ static int crash_get_memory_ranges(void)
 	 */
 	mem_regions_sort(&usablemem_rgns);
 
+	dbgprint_mem_range("Coredump memory ranges",
+			   usablemem_rgns.ranges, usablemem_rgns.size);
+
 	return 0;
 }
 
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 29/32] arm: add debug of reserved and coredump memory ranges

[Russell King]

Add debug of the reserved and coredump memory ranges for validation.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 25fdbe9..2dc8846 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -158,6 +158,10 @@ static int crash_get_memory_ranges(void)
 		return -1;
 	}
 
+	dbgprint_mem_range("Reserved memory ranges",
+			   crash_reserved_rgns.ranges,
+			   crash_reserved_rgns.size);
+
 	/*
 	 * Exclude all reserved memory from the usable memory regions.
 	 * We want to avoid dumping the crashkernel region itself.  Note
@@ -179,6 +183,9 @@ static int crash_get_memory_ranges(void)
 	 */
 	mem_regions_sort(&usablemem_rgns);
 
+	dbgprint_mem_range("Coredump memory ranges",
+			   usablemem_rgns.ranges, usablemem_rgns.size);
+
 	return 0;
 }
 
-- 
1.9.1

Re: [PATCH kexec-tools 29/32] arm: add debug of reserved and coredump memory ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add debug of the reserved and coredump memory ranges for validation.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 25fdbe9..2dc8846 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -158,6 +158,10 @@ static int crash_get_memory_ranges(void)
>                 return -1;
>         }
>
> +       dbgprint_mem_range("Reserved memory ranges",
> +                          crash_reserved_rgns.ranges,
> +                          crash_reserved_rgns.size);
> +
>         /*
>          * Exclude all reserved memory from the usable memory regions.
>          * We want to avoid dumping the crashkernel region itself.  Note
> @@ -179,6 +183,9 @@ static int crash_get_memory_ranges(void)
>          */
>         mem_regions_sort(&usablemem_rgns);
>
> +       dbgprint_mem_range("Coredump memory ranges",
> +                          usablemem_rgns.ranges, usablemem_rgns.size);
> +
>         return 0;
>  }
>
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 29/32] arm: add debug of reserved and coredump memory ranges

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Add debug of the reserved and coredump memory ranges for validation.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 25fdbe9..2dc8846 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -158,6 +158,10 @@ static int crash_get_memory_ranges(void)
>                 return -1;
>         }
>
> +       dbgprint_mem_range("Reserved memory ranges",
> +                          crash_reserved_rgns.ranges,
> +                          crash_reserved_rgns.size);
> +
>         /*
>          * Exclude all reserved memory from the usable memory regions.
>          * We want to avoid dumping the crashkernel region itself.  Note
> @@ -179,6 +183,9 @@ static int crash_get_memory_ranges(void)
>          */
>         mem_regions_sort(&usablemem_rgns);
>
> +       dbgprint_mem_range("Coredump memory ranges",
> +                          usablemem_rgns.ranges, usablemem_rgns.size);
> +
>         return 0;
>  }
>
> --
> 1.9.1
>

[PATCH kexec-tools 30/32] arm: fix type of phys_offset

[Russell King]

Some LPAE systems may have phys_offset above the 4GB mark.  Hence, we
need phys_offset to be a 64-bit integer.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 4 ++--
 kexec/arch/arm/crashdump-arm.h | 1 -
 kexec/arch/arm/phys_to_virt.c  | 4 +++-
 kexec/arch/arm/phys_to_virt.h  | 8 ++++++++
 4 files changed, 13 insertions(+), 4 deletions(-)
 create mode 100644 kexec/arch/arm/phys_to_virt.h

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 2dc8846..2589582 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -33,6 +33,7 @@
 #include "../../mem_regions.h"
 #include "crashdump-arm.h"
 #include "iomem.h"
+#include "phys_to_virt.h"
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #define ELFDATANATIVE ELFDATA2LSB
@@ -70,7 +71,6 @@ static struct crash_elf_info elf_info = {
 	.page_offset	= DEFAULT_PAGE_OFFSET,
 };
 
-unsigned long phys_offset;
 extern unsigned long long user_page_offset;
 
 /* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
@@ -293,7 +293,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * region as PHYS_OFFSET.
 	 */
 	phys_offset = usablemem_rgns.ranges->start;
-	dbgprintf("phys_offset: %#lx\n", phys_offset);
+	dbgprintf("phys_offset: %#llx\n", phys_offset);
 
 	if (get_kernel_page_offset(info, &elf_info))
 		return -1;
diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
index 7314960..6e87b13 100644
--- a/kexec/arch/arm/crashdump-arm.h
+++ b/kexec/arch/arm/crashdump-arm.h
@@ -16,7 +16,6 @@ extern struct memory_ranges usablemem_rgns;
 
 struct kexec_info;
 
-extern unsigned long phys_offset;
 extern int load_crashdump_segments(struct kexec_info *, char *);
 
 #ifdef __cplusplus
diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
index c2fe2ea..46a4f68 100644
--- a/kexec/arch/arm/phys_to_virt.c
+++ b/kexec/arch/arm/phys_to_virt.c
@@ -1,6 +1,8 @@
 #include "../../kexec.h"
 #include "../../crashdump.h"
-#include "crashdump-arm.h"
+#include "phys_to_virt.h"
+
+uint64_t phys_offset;
 
 /**
  * phys_to_virt() - translate physical address to virtual address
diff --git a/kexec/arch/arm/phys_to_virt.h b/kexec/arch/arm/phys_to_virt.h
new file mode 100644
index 0000000..b3147dd
--- /dev/null
+++ b/kexec/arch/arm/phys_to_virt.h
@@ -0,0 +1,8 @@
+#ifndef PHYS_TO_VIRT_H
+#define PHYS_TO_VIRT_H
+
+#include <stdint.h>
+
+extern uint64_t phys_offset;
+
+#endif
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 30/32] arm: fix type of phys_offset

[Russell King]

Some LPAE systems may have phys_offset above the 4GB mark.  Hence, we
need phys_offset to be a 64-bit integer.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 4 ++--
 kexec/arch/arm/crashdump-arm.h | 1 -
 kexec/arch/arm/phys_to_virt.c  | 4 +++-
 kexec/arch/arm/phys_to_virt.h  | 8 ++++++++
 4 files changed, 13 insertions(+), 4 deletions(-)
 create mode 100644 kexec/arch/arm/phys_to_virt.h

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 2dc8846..2589582 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -33,6 +33,7 @@
 #include "../../mem_regions.h"
 #include "crashdump-arm.h"
 #include "iomem.h"
+#include "phys_to_virt.h"
 
 #if __BYTE_ORDER == __LITTLE_ENDIAN
 #define ELFDATANATIVE ELFDATA2LSB
@@ -70,7 +71,6 @@ static struct crash_elf_info elf_info = {
 	.page_offset	= DEFAULT_PAGE_OFFSET,
 };
 
-unsigned long phys_offset;
 extern unsigned long long user_page_offset;
 
 /* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
@@ -293,7 +293,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * region as PHYS_OFFSET.
 	 */
 	phys_offset = usablemem_rgns.ranges->start;
-	dbgprintf("phys_offset: %#lx\n", phys_offset);
+	dbgprintf("phys_offset: %#llx\n", phys_offset);
 
 	if (get_kernel_page_offset(info, &elf_info))
 		return -1;
diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
index 7314960..6e87b13 100644
--- a/kexec/arch/arm/crashdump-arm.h
+++ b/kexec/arch/arm/crashdump-arm.h
@@ -16,7 +16,6 @@ extern struct memory_ranges usablemem_rgns;
 
 struct kexec_info;
 
-extern unsigned long phys_offset;
 extern int load_crashdump_segments(struct kexec_info *, char *);
 
 #ifdef __cplusplus
diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
index c2fe2ea..46a4f68 100644
--- a/kexec/arch/arm/phys_to_virt.c
+++ b/kexec/arch/arm/phys_to_virt.c
@@ -1,6 +1,8 @@
 #include "../../kexec.h"
 #include "../../crashdump.h"
-#include "crashdump-arm.h"
+#include "phys_to_virt.h"
+
+uint64_t phys_offset;
 
 /**
  * phys_to_virt() - translate physical address to virtual address
diff --git a/kexec/arch/arm/phys_to_virt.h b/kexec/arch/arm/phys_to_virt.h
new file mode 100644
index 0000000..b3147dd
--- /dev/null
+++ b/kexec/arch/arm/phys_to_virt.h
@@ -0,0 +1,8 @@
+#ifndef PHYS_TO_VIRT_H
+#define PHYS_TO_VIRT_H
+
+#include <stdint.h>
+
+extern uint64_t phys_offset;
+
+#endif
-- 
1.9.1

Re: [PATCH kexec-tools 30/32] arm: fix type of phys_offset

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Some LPAE systems may have phys_offset above the 4GB mark.  Hence, we
> need phys_offset to be a 64-bit integer.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 4 ++--
>  kexec/arch/arm/crashdump-arm.h | 1 -
>  kexec/arch/arm/phys_to_virt.c  | 4 +++-
>  kexec/arch/arm/phys_to_virt.h  | 8 ++++++++
>  4 files changed, 13 insertions(+), 4 deletions(-)
>  create mode 100644 kexec/arch/arm/phys_to_virt.h
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 2dc8846..2589582 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -33,6 +33,7 @@
>  #include "../../mem_regions.h"
>  #include "crashdump-arm.h"
>  #include "iomem.h"
> +#include "phys_to_virt.h"
>
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  #define ELFDATANATIVE ELFDATA2LSB
> @@ -70,7 +71,6 @@ static struct crash_elf_info elf_info = {
>         .page_offset    = DEFAULT_PAGE_OFFSET,
>  };
>
> -unsigned long phys_offset;
>  extern unsigned long long user_page_offset;
>
>  /* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
> @@ -293,7 +293,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * region as PHYS_OFFSET.
>          */
>         phys_offset = usablemem_rgns.ranges->start;
> -       dbgprintf("phys_offset: %#lx\n", phys_offset);
> +       dbgprintf("phys_offset: %#llx\n", phys_offset);
>
>         if (get_kernel_page_offset(info, &elf_info))
>                 return -1;
> diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
> index 7314960..6e87b13 100644
> --- a/kexec/arch/arm/crashdump-arm.h
> +++ b/kexec/arch/arm/crashdump-arm.h
> @@ -16,7 +16,6 @@ extern struct memory_ranges usablemem_rgns;
>
>  struct kexec_info;
>
> -extern unsigned long phys_offset;
>  extern int load_crashdump_segments(struct kexec_info *, char *);
>
>  #ifdef __cplusplus
> diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
> index c2fe2ea..46a4f68 100644
> --- a/kexec/arch/arm/phys_to_virt.c
> +++ b/kexec/arch/arm/phys_to_virt.c
> @@ -1,6 +1,8 @@
>  #include "../../kexec.h"
>  #include "../../crashdump.h"
> -#include "crashdump-arm.h"
> +#include "phys_to_virt.h"
> +
> +uint64_t phys_offset;
>
>  /**
>   * phys_to_virt() - translate physical address to virtual address
> diff --git a/kexec/arch/arm/phys_to_virt.h b/kexec/arch/arm/phys_to_virt.h
> new file mode 100644
> index 0000000..b3147dd
> --- /dev/null
> +++ b/kexec/arch/arm/phys_to_virt.h
> @@ -0,0 +1,8 @@
> +#ifndef PHYS_TO_VIRT_H
> +#define PHYS_TO_VIRT_H
> +
> +#include <stdint.h>
> +
> +extern uint64_t phys_offset;
> +
> +#endif
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 30/32] arm: fix type of phys_offset

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Some LPAE systems may have phys_offset above the 4GB mark.  Hence, we
> need phys_offset to be a 64-bit integer.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 4 ++--
>  kexec/arch/arm/crashdump-arm.h | 1 -
>  kexec/arch/arm/phys_to_virt.c  | 4 +++-
>  kexec/arch/arm/phys_to_virt.h  | 8 ++++++++
>  4 files changed, 13 insertions(+), 4 deletions(-)
>  create mode 100644 kexec/arch/arm/phys_to_virt.h
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 2dc8846..2589582 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -33,6 +33,7 @@
>  #include "../../mem_regions.h"
>  #include "crashdump-arm.h"
>  #include "iomem.h"
> +#include "phys_to_virt.h"
>
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  #define ELFDATANATIVE ELFDATA2LSB
> @@ -70,7 +71,6 @@ static struct crash_elf_info elf_info = {
>         .page_offset    = DEFAULT_PAGE_OFFSET,
>  };
>
> -unsigned long phys_offset;
>  extern unsigned long long user_page_offset;
>
>  /* Retrieve kernel _stext symbol virtual address from /proc/kallsyms */
> @@ -293,7 +293,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * region as PHYS_OFFSET.
>          */
>         phys_offset = usablemem_rgns.ranges->start;
> -       dbgprintf("phys_offset: %#lx\n", phys_offset);
> +       dbgprintf("phys_offset: %#llx\n", phys_offset);
>
>         if (get_kernel_page_offset(info, &elf_info))
>                 return -1;
> diff --git a/kexec/arch/arm/crashdump-arm.h b/kexec/arch/arm/crashdump-arm.h
> index 7314960..6e87b13 100644
> --- a/kexec/arch/arm/crashdump-arm.h
> +++ b/kexec/arch/arm/crashdump-arm.h
> @@ -16,7 +16,6 @@ extern struct memory_ranges usablemem_rgns;
>
>  struct kexec_info;
>
> -extern unsigned long phys_offset;
>  extern int load_crashdump_segments(struct kexec_info *, char *);
>
>  #ifdef __cplusplus
> diff --git a/kexec/arch/arm/phys_to_virt.c b/kexec/arch/arm/phys_to_virt.c
> index c2fe2ea..46a4f68 100644
> --- a/kexec/arch/arm/phys_to_virt.c
> +++ b/kexec/arch/arm/phys_to_virt.c
> @@ -1,6 +1,8 @@
>  #include "../../kexec.h"
>  #include "../../crashdump.h"
> -#include "crashdump-arm.h"
> +#include "phys_to_virt.h"
> +
> +uint64_t phys_offset;
>
>  /**
>   * phys_to_virt() - translate physical address to virtual address
> diff --git a/kexec/arch/arm/phys_to_virt.h b/kexec/arch/arm/phys_to_virt.h
> new file mode 100644
> index 0000000..b3147dd
> --- /dev/null
> +++ b/kexec/arch/arm/phys_to_virt.h
> @@ -0,0 +1,8 @@
> +#ifndef PHYS_TO_VIRT_H
> +#define PHYS_TO_VIRT_H
> +
> +#include <stdint.h>
> +
> +extern uint64_t phys_offset;
> +
> +#endif
> --
> 1.9.1
>

[PATCH kexec-tools 31/32] arm: clean up phys/page offset debug

[Russell King]

Clean up the physical and page offset debug prints.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 2589582..3b71267 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -136,7 +136,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 				user_page_offset);
 	}
 	elf_info->page_offset = stext_sym_addr & (~KVBASE_MASK);
-	dbgprintf("page_offset is set to %llx\n", elf_info->page_offset);
 	return 0;
 }
 
@@ -293,11 +292,13 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * region as PHYS_OFFSET.
 	 */
 	phys_offset = usablemem_rgns.ranges->start;
-	dbgprintf("phys_offset: %#llx\n", phys_offset);
 
 	if (get_kernel_page_offset(info, &elf_info))
 		return -1;
 
+	dbgprintf("phys offset = %#llx, page offset = %llx\n",
+		  phys_offset, elf_info.page_offset);
+
 	/*
 	 * Ensure that the crash kernel memory range is sane. The crash kernel
 	 * must be located within memory which is visible during booting.
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 31/32] arm: clean up phys/page offset debug

[Russell King]

Clean up the physical and page offset debug prints.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 2589582..3b71267 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -136,7 +136,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
 				user_page_offset);
 	}
 	elf_info->page_offset = stext_sym_addr & (~KVBASE_MASK);
-	dbgprintf("page_offset is set to %llx\n", elf_info->page_offset);
 	return 0;
 }
 
@@ -293,11 +292,13 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 	 * region as PHYS_OFFSET.
 	 */
 	phys_offset = usablemem_rgns.ranges->start;
-	dbgprintf("phys_offset: %#llx\n", phys_offset);
 
 	if (get_kernel_page_offset(info, &elf_info))
 		return -1;
 
+	dbgprintf("phys offset = %#llx, page offset = %llx\n",
+		  phys_offset, elf_info.page_offset);
+
 	/*
 	 * Ensure that the crash kernel memory range is sane. The crash kernel
 	 * must be located within memory which is visible during booting.
-- 
1.9.1

Re: [PATCH kexec-tools 31/32] arm: clean up phys/page offset debug

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Clean up the physical and page offset debug prints.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 2589582..3b71267 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -136,7 +136,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
>                                 user_page_offset);
>         }
>         elf_info->page_offset = stext_sym_addr & (~KVBASE_MASK);
> -       dbgprintf("page_offset is set to %llx\n", elf_info->page_offset);
>         return 0;
>  }
>
> @@ -293,11 +292,13 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * region as PHYS_OFFSET.
>          */
>         phys_offset = usablemem_rgns.ranges->start;
> -       dbgprintf("phys_offset: %#llx\n", phys_offset);
>
>         if (get_kernel_page_offset(info, &elf_info))
>                 return -1;
>
> +       dbgprintf("phys offset = %#llx, page offset = %llx\n",
> +                 phys_offset, elf_info.page_offset);
> +
>         /*
>          * Ensure that the crash kernel memory range is sane. The crash kernel
>          * must be located within memory which is visible during booting.
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 31/32] arm: clean up phys/page offset debug

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Clean up the physical and page offset debug prints.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 2589582..3b71267 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -136,7 +136,6 @@ static int get_kernel_page_offset(struct kexec_info *info,
>                                 user_page_offset);
>         }
>         elf_info->page_offset = stext_sym_addr & (~KVBASE_MASK);
> -       dbgprintf("page_offset is set to %llx\n", elf_info->page_offset);
>         return 0;
>  }
>
> @@ -293,11 +292,13 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>          * region as PHYS_OFFSET.
>          */
>         phys_offset = usablemem_rgns.ranges->start;
> -       dbgprintf("phys_offset: %#llx\n", phys_offset);
>
>         if (get_kernel_page_offset(info, &elf_info))
>                 return -1;
>
> +       dbgprintf("phys offset = %#llx, page offset = %llx\n",
> +                 phys_offset, elf_info.page_offset);
> +
>         /*
>          * Ensure that the crash kernel memory range is sane. The crash kernel
>          * must be located within memory which is visible during booting.
> --
> 1.9.1
>

[PATCH kexec-tools 32/32] arm: report which ELF core format we will use

[Russell King]

Report which ELF core format will be used to create the template ELF
core dump in the debug information.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 3b71267..4a89b5e 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -315,6 +315,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 		last_ranges = 0;
 
 	if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
+		dbgprintf("Using 64-bit ELF core format\n");
+
 		/* for support LPAE enabled kernel*/
 		elf_info.class = ELFCLASS64;
 
@@ -323,6 +325,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 					 usablemem_rgns.size, &buf, &bufsz,
 					 ELF_CORE_HEADER_ALIGN);
 	} else {
+		dbgprintf("Using 32-bit ELF core format\n");
 		err = crash_create_elf32_headers(info, &elf_info,
 					 usablemem_rgns.ranges,
 					 usablemem_rgns.size, &buf, &bufsz,
-- 
1.9.1


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 32/32] arm: report which ELF core format we will use

[Russell King]

Report which ELF core format will be used to create the template ELF
core dump in the debug information.

Signed-off-by: Russell King <rmk@arm.linux.org.uk>
---
 kexec/arch/arm/crashdump-arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
index 3b71267..4a89b5e 100644
--- a/kexec/arch/arm/crashdump-arm.c
+++ b/kexec/arch/arm/crashdump-arm.c
@@ -315,6 +315,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 		last_ranges = 0;
 
 	if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
+		dbgprintf("Using 64-bit ELF core format\n");
+
 		/* for support LPAE enabled kernel*/
 		elf_info.class = ELFCLASS64;
 
@@ -323,6 +325,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
 					 usablemem_rgns.size, &buf, &bufsz,
 					 ELF_CORE_HEADER_ALIGN);
 	} else {
+		dbgprintf("Using 32-bit ELF core format\n");
 		err = crash_create_elf32_headers(info, &elf_info,
 					 usablemem_rgns.ranges,
 					 usablemem_rgns.size, &buf, &bufsz,
-- 
1.9.1

Re: [PATCH kexec-tools 32/32] arm: report which ELF core format we will use

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Report which ELF core format will be used to create the template ELF
> core dump in the debug information.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 3b71267..4a89b5e 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -315,6 +315,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>                 last_ranges = 0;
>
>         if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
> +               dbgprintf("Using 64-bit ELF core format\n");
> +
>                 /* for support LPAE enabled kernel*/
>                 elf_info.class = ELFCLASS64;
>
> @@ -323,6 +325,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>                                          usablemem_rgns.size, &buf, &bufsz,
>                                          ELF_CORE_HEADER_ALIGN);
>         } else {
> +               dbgprintf("Using 32-bit ELF core format\n");
>                 err = crash_create_elf32_headers(info, &elf_info,
>                                          usablemem_rgns.ranges,
>                                          usablemem_rgns.size, &buf, &bufsz,
> --
> 1.9.1
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH kexec-tools 32/32] arm: report which ELF core format we will use

[Pratyush Anand]

On Tue, May 3, 2016 at 3:53 PM, Russell King <rmk@arm.linux.org.uk> wrote:
> Report which ELF core format will be used to create the template ELF
> core dump in the debug information.
>
> Signed-off-by: Russell King <rmk@arm.linux.org.uk>

Reviewed-by: Pratyush Anand <panand@redhat.com>

> ---
>  kexec/arch/arm/crashdump-arm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kexec/arch/arm/crashdump-arm.c b/kexec/arch/arm/crashdump-arm.c
> index 3b71267..4a89b5e 100644
> --- a/kexec/arch/arm/crashdump-arm.c
> +++ b/kexec/arch/arm/crashdump-arm.c
> @@ -315,6 +315,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>                 last_ranges = 0;
>
>         if (crash_memory_ranges[last_ranges].end > UINT32_MAX) {
> +               dbgprintf("Using 64-bit ELF core format\n");
> +
>                 /* for support LPAE enabled kernel*/
>                 elf_info.class = ELFCLASS64;
>
> @@ -323,6 +325,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline)
>                                          usablemem_rgns.size, &buf, &bufsz,
>                                          ELF_CORE_HEADER_ALIGN);
>         } else {
> +               dbgprintf("Using 32-bit ELF core format\n");
>                 err = crash_create_elf32_headers(info, &elf_info,
>                                          usablemem_rgns.ranges,
>                                          usablemem_rgns.size, &buf, &bufsz,
> --
> 1.9.1
>

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Can you please also share git tree path of corresponding kexec-tools changes?

On their way as a 32-patch series.  I've found the userspace tools to be
in particularly poor shape, so some of the patches are fixing that up.
I can't believe that anyone uses these userspace tools, because there
are some fundamental bugs present in this code which go back years.
However, the repository does seem to be maintained, with the latest
commit within the last two months (or day when I started working on
this.)

They're based upon 2.0.12-rc1 (93d3a617) of the

	git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

repository, which was the latest commit when I started working on this
back in March.  Things may have moved forwards since then - I've not
been able to check yet.  However, this set of changes should be
sufficient to get an idea of what's required on the userspace side.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Can you please also share git tree path of corresponding kexec-tools changes?

On their way as a 32-patch series.  I've found the userspace tools to be
in particularly poor shape, so some of the patches are fixing that up.
I can't believe that anyone uses these userspace tools, because there
are some fundamental bugs present in this code which go back years.
However, the repository does seem to be maintained, with the latest
commit within the last two months (or day when I started working on
this.)

They're based upon 2.0.12-rc1 (93d3a617) of the

	git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

repository, which was the latest commit when I started working on this
back in March.  Things may have moved forwards since then - I've not
been able to check yet.  However, this set of changes should be
sufficient to get an idea of what's required on the userspace side.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Can you please also share git tree path of corresponding kexec-tools changes?

On their way as a 32-patch series.  I've found the userspace tools to be
in particularly poor shape, so some of the patches are fixing that up.
I can't believe that anyone uses these userspace tools, because there
are some fundamental bugs present in this code which go back years.
However, the repository does seem to be maintained, with the latest
commit within the last two months (or day when I started working on
this.)

They're based upon 2.0.12-rc1 (93d3a617) of the

	git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

repository, which was the latest commit when I started working on this
back in March.  Things may have moved forwards since then - I've not
been able to check yet.  However, this set of changes should be
sufficient to get an idea of what's required on the userspace side.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Can you please also share git tree path of corresponding kexec-tools changes?

On their way as a 32-patch series.  I've found the userspace tools to be
in particularly poor shape, so some of the patches are fixing that up.
I can't believe that anyone uses these userspace tools, because there
are some fundamental bugs present in this code which go back years.
However, the repository does seem to be maintained, with the latest
commit within the last two months (or day when I started working on
this.)

They're based upon 2.0.12-rc1 (93d3a617) of the

	git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

repository, which was the latest commit when I started working on this
back in March.  Things may have moved forwards since then - I've not
been able to check yet.  However, this set of changes should be
sufficient to get an idea of what's required on the userspace side.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 07/12] ARM: keystone: dts: add psci command definition

[Russell King]

From: Vitaly Andrianov <vitalya@ti.com>

This commit adds definition for cpu_on, cpu_off and cpu_suspend commands.
These definitions must match the corresponding PSCI definitions in
boot monitor.

Having those command and corresponding PSCI support in boot monitor allows
run time CPU hot plugin.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---

This patch is already queued by Santosh, and only exists as part of this
series for completeness.

 arch/arm/boot/dts/keystone.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 3f272826f537..007648971744 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -59,6 +59,14 @@
 			     <GIC_SPI 23 IRQ_TYPE_EDGE_RISING>;
 	};
 
+	psci {
+		compatible	= "arm,psci";
+		method		= "smc";
+		cpu_suspend	= <0x84000001>;
+		cpu_off		= <0x84000002>;
+		cpu_on		= <0x84000003>;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 07/12] ARM: keystone: dts: add psci command definition

[Russell King]

From: Vitaly Andrianov <vitalya@ti.com>

This commit adds definition for cpu_on, cpu_off and cpu_suspend commands.
These definitions must match the corresponding PSCI definitions in
boot monitor.

Having those command and corresponding PSCI support in boot monitor allows
run time CPU hot plugin.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---

This patch is already queued by Santosh, and only exists as part of this
series for completeness.

 arch/arm/boot/dts/keystone.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 3f272826f537..007648971744 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -59,6 +59,14 @@
 			     <GIC_SPI 23 IRQ_TYPE_EDGE_RISING>;
 	};
 
+	psci {
+		compatible	= "arm,psci";
+		method		= "smc";
+		cpu_suspend	= <0x84000001>;
+		cpu_off		= <0x84000002>;
+		cpu_on		= <0x84000003>;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
2.1.0

[PATCH 07/12] ARM: keystone: dts: add psci command definition

[Russell King]

From: Vitaly Andrianov <vitalya@ti.com>

This commit adds definition for cpu_on, cpu_off and cpu_suspend commands.
These definitions must match the corresponding PSCI definitions in
boot monitor.

Having those command and corresponding PSCI support in boot monitor allows
run time CPU hot plugin.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---

This patch is already queued by Santosh, and only exists as part of this
series for completeness.

 arch/arm/boot/dts/keystone.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 3f272826f537..007648971744 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -59,6 +59,14 @@
 			     <GIC_SPI 23 IRQ_TYPE_EDGE_RISING>;
 	};
 
+	psci {
+		compatible	= "arm,psci";
+		method		= "smc";
+		cpu_suspend	= <0x84000001>;
+		cpu_off		= <0x84000002>;
+		cpu_on		= <0x84000003>;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
2.1.0

[PATCH 07/12] ARM: keystone: dts: add psci command definition

[Russell King]

From: Vitaly Andrianov <vitalya@ti.com>

This commit adds definition for cpu_on, cpu_off and cpu_suspend commands.
These definitions must match the corresponding PSCI definitions in
boot monitor.

Having those command and corresponding PSCI support in boot monitor allows
run time CPU hot plugin.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---

This patch is already queued by Santosh, and only exists as part of this
series for completeness.

 arch/arm/boot/dts/keystone.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 3f272826f537..007648971744 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -59,6 +59,14 @@
 			     <GIC_SPI 23 IRQ_TYPE_EDGE_RISING>;
 	};
 
+	psci {
+		compatible	= "arm,psci";
+		method		= "smc";
+		cpu_suspend	= <0x84000001>;
+		cpu_off		= <0x84000002>;
+		cpu_on		= <0x84000003>;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
2.1.0

[PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Russell King]

If we are unable to find a suitable page when allocating the control
page, do not invoke the OOM-killer: killing processes probably isn't
going to help.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 2cc643c6e870..1b32ab587f66 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -41,7 +41,7 @@
 #endif
 
 #ifndef KEXEC_CONTROL_MEMORY_GFP
-#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
+#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
 #endif
 
 #ifndef KEXEC_CONTROL_PAGE_SIZE
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Russell King]

If we are unable to find a suitable page when allocating the control
page, do not invoke the OOM-killer: killing processes probably isn't
going to help.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 2cc643c6e870..1b32ab587f66 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -41,7 +41,7 @@
 #endif
 
 #ifndef KEXEC_CONTROL_MEMORY_GFP
-#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
+#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
 #endif
 
 #ifndef KEXEC_CONTROL_PAGE_SIZE
-- 
2.1.0

[PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Russell King]

If we are unable to find a suitable page when allocating the control
page, do not invoke the OOM-killer: killing processes probably isn't
going to help.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 2cc643c6e870..1b32ab587f66 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -41,7 +41,7 @@
 #endif
 
 #ifndef KEXEC_CONTROL_MEMORY_GFP
-#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
+#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
 #endif
 
 #ifndef KEXEC_CONTROL_PAGE_SIZE
-- 
2.1.0

[PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Russell King]

If we are unable to find a suitable page when allocating the control
page, do not invoke the OOM-killer: killing processes probably isn't
going to help.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 2cc643c6e870..1b32ab587f66 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -41,7 +41,7 @@
 #endif
 
 #ifndef KEXEC_CONTROL_MEMORY_GFP
-#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
+#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
 #endif
 
 #ifndef KEXEC_CONTROL_PAGE_SIZE
-- 
2.1.0

Re: [PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> If we are unable to find a suitable page when allocating the control
> page, do not invoke the OOM-killer: killing processes probably isn't
> going to help.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 2cc643c6e870..1b32ab587f66 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -41,7 +41,7 @@
>  #endif
>
>  #ifndef KEXEC_CONTROL_MEMORY_GFP
> -#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
> +#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
>  #endif
>
>  #ifndef KEXEC_CONTROL_PAGE_SIZE

Reviewed-by: Pratyush Anand <panand@redhat.com>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> If we are unable to find a suitable page when allocating the control
> page, do not invoke the OOM-killer: killing processes probably isn't
> going to help.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 2cc643c6e870..1b32ab587f66 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -41,7 +41,7 @@
>  #endif
>
>  #ifndef KEXEC_CONTROL_MEMORY_GFP
> -#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
> +#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
>  #endif
>
>  #ifndef KEXEC_CONTROL_PAGE_SIZE

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> If we are unable to find a suitable page when allocating the control
> page, do not invoke the OOM-killer: killing processes probably isn't
> going to help.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 2cc643c6e870..1b32ab587f66 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -41,7 +41,7 @@
>  #endif
>
>  #ifndef KEXEC_CONTROL_MEMORY_GFP
> -#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
> +#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
>  #endif
>
>  #ifndef KEXEC_CONTROL_PAGE_SIZE

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 08/12] kexec: don't invoke OOM-killer for control page allocation

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> If we are unable to find a suitable page when allocating the control
> page, do not invoke the OOM-killer: killing processes probably isn't
> going to help.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 2cc643c6e870..1b32ab587f66 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -41,7 +41,7 @@
>  #endif
>
>  #ifndef KEXEC_CONTROL_MEMORY_GFP
> -#define KEXEC_CONTROL_MEMORY_GFP GFP_KERNEL
> +#define KEXEC_CONTROL_MEMORY_GFP (GFP_KERNEL | __GFP_NORETRY)
>  #endif
>
>  #ifndef KEXEC_CONTROL_PAGE_SIZE

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Russell King]

Ensure that user memory sizes do not wrap around when validating the
user input, which can lead to the following input validation working
incorrectly.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8d34308ea449..d719a4d0ef55 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
 
 		mstart = image->segment[i].mem;
 		mend   = mstart + image->segment[i].memsz;
+		if (mstart > mend)
+			return result;
 		if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
 			return result;
 		if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Russell King]

Ensure that user memory sizes do not wrap around when validating the
user input, which can lead to the following input validation working
incorrectly.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8d34308ea449..d719a4d0ef55 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
 
 		mstart = image->segment[i].mem;
 		mend   = mstart + image->segment[i].memsz;
+		if (mstart > mend)
+			return result;
 		if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
 			return result;
 		if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)
-- 
2.1.0

[PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Russell King]

Ensure that user memory sizes do not wrap around when validating the
user input, which can lead to the following input validation working
incorrectly.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8d34308ea449..d719a4d0ef55 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
 
 		mstart = image->segment[i].mem;
 		mend   = mstart + image->segment[i].memsz;
+		if (mstart > mend)
+			return result;
 		if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
 			return result;
 		if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)
-- 
2.1.0

[PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Russell King]

Ensure that user memory sizes do not wrap around when validating the
user input, which can lead to the following input validation working
incorrectly.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 kernel/kexec_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8d34308ea449..d719a4d0ef55 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
 
 		mstart = image->segment[i].mem;
 		mend   = mstart + image->segment[i].memsz;
+		if (mstart > mend)
+			return result;
 		if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
 			return result;
 		if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)
-- 
2.1.0

Re: [PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Ensure that user memory sizes do not wrap around when validating the
> user input, which can lead to the following input validation working
> incorrectly.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  kernel/kexec_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 8d34308ea449..d719a4d0ef55 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
>
>                 mstart = image->segment[i].mem;
>                 mend   = mstart + image->segment[i].memsz;
> +               if (mstart > mend)
> +                       return result;
>                 if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
>                         return result;
>                 if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)

Reviewed-by: Pratyush Anand <panand@redhat.com>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Ensure that user memory sizes do not wrap around when validating the
> user input, which can lead to the following input validation working
> incorrectly.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  kernel/kexec_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 8d34308ea449..d719a4d0ef55 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
>
>                 mstart = image->segment[i].mem;
>                 mend   = mstart + image->segment[i].memsz;
> +               if (mstart > mend)
> +                       return result;
>                 if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
>                         return result;
>                 if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> Ensure that user memory sizes do not wrap around when validating the
> user input, which can lead to the following input validation working
> incorrectly.
>
> Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> ---
>  kernel/kexec_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 8d34308ea449..d719a4d0ef55 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
>
>                 mstart = image->segment[i].mem;
>                 mend   = mstart + image->segment[i].memsz;
> +               if (mstart > mend)
> +                       return result;
>                 if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
>                         return result;
>                 if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)

Reviewed-by: Pratyush Anand <panand-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/12] kexec: ensure user memory sizes do not wrap

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> Ensure that user memory sizes do not wrap around when validating the
> user input, which can lead to the following input validation working
> incorrectly.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  kernel/kexec_core.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 8d34308ea449..d719a4d0ef55 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -169,6 +169,8 @@ int sanity_check_segment_list(struct kimage *image)
>
>                 mstart = image->segment[i].mem;
>                 mend   = mstart + image->segment[i].memsz;
> +               if (mstart > mend)
> +                       return result;
>                 if ((mstart & ~PAGE_MASK) || (mend & ~PAGE_MASK))
>                         return result;
>                 if (mend >= KEXEC_DESTINATION_MEMORY_LIMIT)

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King]

On PAE systems (eg, ARM LPAE) the vmcore note may be located above
4GB physical on 32-bit architectures, so we need a wider type than
"unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
a phys_addr_t, thereby allowing it to be located above 4GB.

This makes no difference for kexec-tools, as they already assume a
64-bit type when reading from this file.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/ia64/kernel/machine_kexec.c | 2 +-
 include/linux/kexec.h            | 2 +-
 kernel/kexec_core.c              | 2 +-
 kernel/ksysfs.c                  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index b72cd7a07222..599507bcec91 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
 #endif
 }
 
-unsigned long paddr_vmcoreinfo_note(void)
+phys_addr_t paddr_vmcoreinfo_note(void)
 {
 	return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 1b32ab587f66..52a3a221bcb2 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
 void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
-unsigned long paddr_vmcoreinfo_note(void);
+phys_addr_t paddr_vmcoreinfo_note(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
 	vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index d719a4d0ef55..f9847e5822e6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 void __weak arch_crash_save_vmcoreinfo(void)
 {}
 
-unsigned long __weak paddr_vmcoreinfo_note(void)
+phys_addr_t __weak paddr_vmcoreinfo_note(void)
 {
 	return __pa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 152da4a48867..9f1920d2d0c6 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
 static ssize_t vmcoreinfo_show(struct kobject *kobj,
 			       struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%lx %x\n",
-		       paddr_vmcoreinfo_note(),
+	phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
+	return sprintf(buf, "%pa %x\n", &vmcore_base,
 		       (unsigned int)sizeof(vmcoreinfo_note));
 }
 KERNEL_ATTR_RO(vmcoreinfo);
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King]

On PAE systems (eg, ARM LPAE) the vmcore note may be located above
4GB physical on 32-bit architectures, so we need a wider type than
"unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
a phys_addr_t, thereby allowing it to be located above 4GB.

This makes no difference for kexec-tools, as they already assume a
64-bit type when reading from this file.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/ia64/kernel/machine_kexec.c | 2 +-
 include/linux/kexec.h            | 2 +-
 kernel/kexec_core.c              | 2 +-
 kernel/ksysfs.c                  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index b72cd7a07222..599507bcec91 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
 #endif
 }
 
-unsigned long paddr_vmcoreinfo_note(void)
+phys_addr_t paddr_vmcoreinfo_note(void)
 {
 	return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 1b32ab587f66..52a3a221bcb2 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
 void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
-unsigned long paddr_vmcoreinfo_note(void);
+phys_addr_t paddr_vmcoreinfo_note(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
 	vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index d719a4d0ef55..f9847e5822e6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 void __weak arch_crash_save_vmcoreinfo(void)
 {}
 
-unsigned long __weak paddr_vmcoreinfo_note(void)
+phys_addr_t __weak paddr_vmcoreinfo_note(void)
 {
 	return __pa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 152da4a48867..9f1920d2d0c6 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
 static ssize_t vmcoreinfo_show(struct kobject *kobj,
 			       struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%lx %x\n",
-		       paddr_vmcoreinfo_note(),
+	phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
+	return sprintf(buf, "%pa %x\n", &vmcore_base,
 		       (unsigned int)sizeof(vmcoreinfo_note));
 }
 KERNEL_ATTR_RO(vmcoreinfo);
-- 
2.1.0

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King]

On PAE systems (eg, ARM LPAE) the vmcore note may be located above
4GB physical on 32-bit architectures, so we need a wider type than
"unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
a phys_addr_t, thereby allowing it to be located above 4GB.

This makes no difference for kexec-tools, as they already assume a
64-bit type when reading from this file.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/ia64/kernel/machine_kexec.c | 2 +-
 include/linux/kexec.h            | 2 +-
 kernel/kexec_core.c              | 2 +-
 kernel/ksysfs.c                  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index b72cd7a07222..599507bcec91 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
 #endif
 }
 
-unsigned long paddr_vmcoreinfo_note(void)
+phys_addr_t paddr_vmcoreinfo_note(void)
 {
 	return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 1b32ab587f66..52a3a221bcb2 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
 void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
-unsigned long paddr_vmcoreinfo_note(void);
+phys_addr_t paddr_vmcoreinfo_note(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
 	vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index d719a4d0ef55..f9847e5822e6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 void __weak arch_crash_save_vmcoreinfo(void)
 {}
 
-unsigned long __weak paddr_vmcoreinfo_note(void)
+phys_addr_t __weak paddr_vmcoreinfo_note(void)
 {
 	return __pa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 152da4a48867..9f1920d2d0c6 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
 static ssize_t vmcoreinfo_show(struct kobject *kobj,
 			       struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%lx %x\n",
-		       paddr_vmcoreinfo_note(),
+	phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
+	return sprintf(buf, "%pa %x\n", &vmcore_base,
 		       (unsigned int)sizeof(vmcoreinfo_note));
 }
 KERNEL_ATTR_RO(vmcoreinfo);
-- 
2.1.0

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King]

On PAE systems (eg, ARM LPAE) the vmcore note may be located above
4GB physical on 32-bit architectures, so we need a wider type than
"unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
a phys_addr_t, thereby allowing it to be located above 4GB.

This makes no difference for kexec-tools, as they already assume a
64-bit type when reading from this file.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/ia64/kernel/machine_kexec.c | 2 +-
 include/linux/kexec.h            | 2 +-
 kernel/kexec_core.c              | 2 +-
 kernel/ksysfs.c                  | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index b72cd7a07222..599507bcec91 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
 #endif
 }
 
-unsigned long paddr_vmcoreinfo_note(void)
+phys_addr_t paddr_vmcoreinfo_note(void)
 {
 	return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 1b32ab587f66..52a3a221bcb2 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
 void arch_crash_save_vmcoreinfo(void);
 __printf(1, 2)
 void vmcoreinfo_append_str(const char *fmt, ...);
-unsigned long paddr_vmcoreinfo_note(void);
+phys_addr_t paddr_vmcoreinfo_note(void);
 
 #define VMCOREINFO_OSRELEASE(value) \
 	vmcoreinfo_append_str("OSRELEASE=%s\n", value)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index d719a4d0ef55..f9847e5822e6 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
 void __weak arch_crash_save_vmcoreinfo(void)
 {}
 
-unsigned long __weak paddr_vmcoreinfo_note(void)
+phys_addr_t __weak paddr_vmcoreinfo_note(void)
 {
 	return __pa((unsigned long)(char *)&vmcoreinfo_note);
 }
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 152da4a48867..9f1920d2d0c6 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
 static ssize_t vmcoreinfo_show(struct kobject *kobj,
 			       struct kobj_attribute *attr, char *buf)
 {
-	return sprintf(buf, "%lx %x\n",
-		       paddr_vmcoreinfo_note(),
+	phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
+	return sprintf(buf, "%pa %x\n", &vmcore_base,
 		       (unsigned int)sizeof(vmcoreinfo_note));
 }
 KERNEL_ATTR_RO(vmcoreinfo);
-- 
2.1.0

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> 4GB physical on 32-bit architectures, so we need a wider type than
> "unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
> a phys_addr_t, thereby allowing it to be located above 4GB.
>
> This makes no difference for kexec-tools, as they already assume a
> 64-bit type when reading from this file.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/ia64/kernel/machine_kexec.c | 2 +-
>  include/linux/kexec.h            | 2 +-
>  kernel/kexec_core.c              | 2 +-
>  kernel/ksysfs.c                  | 4 ++--
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
> index b72cd7a07222..599507bcec91 100644
> --- a/arch/ia64/kernel/machine_kexec.c
> +++ b/arch/ia64/kernel/machine_kexec.c
> @@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
>  #endif
>  }
>
> -unsigned long paddr_vmcoreinfo_note(void)
> +phys_addr_t paddr_vmcoreinfo_note(void)
>  {
>         return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 1b32ab587f66..52a3a221bcb2 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
>  void arch_crash_save_vmcoreinfo(void);
>  __printf(1, 2)
>  void vmcoreinfo_append_str(const char *fmt, ...);
> -unsigned long paddr_vmcoreinfo_note(void);
> +phys_addr_t paddr_vmcoreinfo_note(void);
>
>  #define VMCOREINFO_OSRELEASE(value) \
>         vmcoreinfo_append_str("OSRELEASE=%s\n", value)
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index d719a4d0ef55..f9847e5822e6 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
>  void __weak arch_crash_save_vmcoreinfo(void)
>  {}
>
> -unsigned long __weak paddr_vmcoreinfo_note(void)
> +phys_addr_t __weak paddr_vmcoreinfo_note(void)
>  {
>         return __pa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 152da4a48867..9f1920d2d0c6 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>                                struct kobj_attribute *attr, char *buf)
>  {
> -       return sprintf(buf, "%lx %x\n",
> -                      paddr_vmcoreinfo_note(),
> +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> +       return sprintf(buf, "%pa %x\n", &vmcore_base,

Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> 4GB physical on 32-bit architectures, so we need a wider type than
> "unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
> a phys_addr_t, thereby allowing it to be located above 4GB.
>
> This makes no difference for kexec-tools, as they already assume a
> 64-bit type when reading from this file.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/ia64/kernel/machine_kexec.c | 2 +-
>  include/linux/kexec.h            | 2 +-
>  kernel/kexec_core.c              | 2 +-
>  kernel/ksysfs.c                  | 4 ++--
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
> index b72cd7a07222..599507bcec91 100644
> --- a/arch/ia64/kernel/machine_kexec.c
> +++ b/arch/ia64/kernel/machine_kexec.c
> @@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
>  #endif
>  }
>
> -unsigned long paddr_vmcoreinfo_note(void)
> +phys_addr_t paddr_vmcoreinfo_note(void)
>  {
>         return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 1b32ab587f66..52a3a221bcb2 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
>  void arch_crash_save_vmcoreinfo(void);
>  __printf(1, 2)
>  void vmcoreinfo_append_str(const char *fmt, ...);
> -unsigned long paddr_vmcoreinfo_note(void);
> +phys_addr_t paddr_vmcoreinfo_note(void);
>
>  #define VMCOREINFO_OSRELEASE(value) \
>         vmcoreinfo_append_str("OSRELEASE=%s\n", value)
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index d719a4d0ef55..f9847e5822e6 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
>  void __weak arch_crash_save_vmcoreinfo(void)
>  {}
>
> -unsigned long __weak paddr_vmcoreinfo_note(void)
> +phys_addr_t __weak paddr_vmcoreinfo_note(void)
>  {
>         return __pa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 152da4a48867..9f1920d2d0c6 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>                                struct kobj_attribute *attr, char *buf)
>  {
> -       return sprintf(buf, "%lx %x\n",
> -                      paddr_vmcoreinfo_note(),
> +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> +       return sprintf(buf, "%pa %x\n", &vmcore_base,

Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

~Pratyush

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> 4GB physical on 32-bit architectures, so we need a wider type than
> "unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
> a phys_addr_t, thereby allowing it to be located above 4GB.
>
> This makes no difference for kexec-tools, as they already assume a
> 64-bit type when reading from this file.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/ia64/kernel/machine_kexec.c | 2 +-
>  include/linux/kexec.h            | 2 +-
>  kernel/kexec_core.c              | 2 +-
>  kernel/ksysfs.c                  | 4 ++--
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
> index b72cd7a07222..599507bcec91 100644
> --- a/arch/ia64/kernel/machine_kexec.c
> +++ b/arch/ia64/kernel/machine_kexec.c
> @@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
>  #endif
>  }
>
> -unsigned long paddr_vmcoreinfo_note(void)
> +phys_addr_t paddr_vmcoreinfo_note(void)
>  {
>         return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 1b32ab587f66..52a3a221bcb2 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
>  void arch_crash_save_vmcoreinfo(void);
>  __printf(1, 2)
>  void vmcoreinfo_append_str(const char *fmt, ...);
> -unsigned long paddr_vmcoreinfo_note(void);
> +phys_addr_t paddr_vmcoreinfo_note(void);
>
>  #define VMCOREINFO_OSRELEASE(value) \
>         vmcoreinfo_append_str("OSRELEASE=%s\n", value)
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index d719a4d0ef55..f9847e5822e6 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
>  void __weak arch_crash_save_vmcoreinfo(void)
>  {}
>
> -unsigned long __weak paddr_vmcoreinfo_note(void)
> +phys_addr_t __weak paddr_vmcoreinfo_note(void)
>  {
>         return __pa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 152da4a48867..9f1920d2d0c6 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>                                struct kobj_attribute *attr, char *buf)
>  {
> -       return sprintf(buf, "%lx %x\n",
> -                      paddr_vmcoreinfo_note(),
> +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> +       return sprintf(buf, "%pa %x\n", &vmcore_base,

Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

~Pratyush

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> 4GB physical on 32-bit architectures, so we need a wider type than
> "unsigned long" here.  Arrange for paddr_vmcoreinfo_note() to return
> a phys_addr_t, thereby allowing it to be located above 4GB.
>
> This makes no difference for kexec-tools, as they already assume a
> 64-bit type when reading from this file.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/ia64/kernel/machine_kexec.c | 2 +-
>  include/linux/kexec.h            | 2 +-
>  kernel/kexec_core.c              | 2 +-
>  kernel/ksysfs.c                  | 4 ++--
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
> index b72cd7a07222..599507bcec91 100644
> --- a/arch/ia64/kernel/machine_kexec.c
> +++ b/arch/ia64/kernel/machine_kexec.c
> @@ -163,7 +163,7 @@ void arch_crash_save_vmcoreinfo(void)
>  #endif
>  }
>
> -unsigned long paddr_vmcoreinfo_note(void)
> +phys_addr_t paddr_vmcoreinfo_note(void)
>  {
>         return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 1b32ab587f66..52a3a221bcb2 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -235,7 +235,7 @@ void crash_unmap_reserved_pages(void);
>  void arch_crash_save_vmcoreinfo(void);
>  __printf(1, 2)
>  void vmcoreinfo_append_str(const char *fmt, ...);
> -unsigned long paddr_vmcoreinfo_note(void);
> +phys_addr_t paddr_vmcoreinfo_note(void);
>
>  #define VMCOREINFO_OSRELEASE(value) \
>         vmcoreinfo_append_str("OSRELEASE=%s\n", value)
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index d719a4d0ef55..f9847e5822e6 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1377,7 +1377,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
>  void __weak arch_crash_save_vmcoreinfo(void)
>  {}
>
> -unsigned long __weak paddr_vmcoreinfo_note(void)
> +phys_addr_t __weak paddr_vmcoreinfo_note(void)
>  {
>         return __pa((unsigned long)(char *)&vmcoreinfo_note);
>  }
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 152da4a48867..9f1920d2d0c6 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>                                struct kobj_attribute *attr, char *buf)
>  {
> -       return sprintf(buf, "%lx %x\n",
> -                      paddr_vmcoreinfo_note(),
> +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> +       return sprintf(buf, "%pa %x\n", &vmcore_base,

Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

~Pratyush

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Mark Rutland]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

The %pa* printk format specifiers take the value by reference (as
phys_addr_t and friends are not necessarily the same width as a
pointer). Per Documentation/printk-formats.txt:

Physical addresses types phys_addr_t:

        %pa[p]  0x01234567 or 0x0123456789abcdef

        For printing a phys_addr_t type (and its derivatives, such as
        resource_size_t) which can vary based on build options, regardless of
        the width of the CPU data path. Passed by reference.

So the above prints the value of vmcore_base as expected.

Mark.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Mark Rutland]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

The %pa* printk format specifiers take the value by reference (as
phys_addr_t and friends are not necessarily the same width as a
pointer). Per Documentation/printk-formats.txt:

Physical addresses types phys_addr_t:

        %pa[p]  0x01234567 or 0x0123456789abcdef

        For printing a phys_addr_t type (and its derivatives, such as
        resource_size_t) which can vary based on build options, regardless of
        the width of the CPU data path. Passed by reference.

So the above prints the value of vmcore_base as expected.

Mark.

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Mark Rutland]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

The %pa* printk format specifiers take the value by reference (as
phys_addr_t and friends are not necessarily the same width as a
pointer). Per Documentation/printk-formats.txt:

Physical addresses types phys_addr_t:

        %pa[p]  0x01234567 or 0x0123456789abcdef

        For printing a phys_addr_t type (and its derivatives, such as
        resource_size_t) which can vary based on build options, regardless of
        the width of the CPU data path. Passed by reference.

So the above prints the value of vmcore_base as expected.

Mark.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Mark Rutland]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

The %pa* printk format specifiers take the value by reference (as
phys_addr_t and friends are not necessarily the same width as a
pointer). Per Documentation/printk-formats.txt:

Physical addresses types phys_addr_t:

        %pa[p]  0x01234567 or 0x0123456789abcdef

        For printing a phys_addr_t type (and its derivatives, such as
        resource_size_t) which can vary based on build options, regardless of
        the width of the CPU data path. Passed by reference.

So the above prints the value of vmcore_base as expected.

Mark.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> The %pa* printk format specifiers take the value by reference (as
> phys_addr_t and friends are not necessarily the same width as a
> pointer). Per Documentation/printk-formats.txt:
>
> Physical addresses types phys_addr_t:
>
>         %pa[p]  0x01234567 or 0x0123456789abcdef
>
>         For printing a phys_addr_t type (and its derivatives, such as
>         resource_size_t) which can vary based on build options, regardless of
>         the width of the CPU data path. Passed by reference.
>
> So the above prints the value of vmcore_base as expected.

Thanks a lot Mark for explaining :-)

Reviewed-by: Pratyush Anand <panand@redhat.com>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> The %pa* printk format specifiers take the value by reference (as
> phys_addr_t and friends are not necessarily the same width as a
> pointer). Per Documentation/printk-formats.txt:
>
> Physical addresses types phys_addr_t:
>
>         %pa[p]  0x01234567 or 0x0123456789abcdef
>
>         For printing a phys_addr_t type (and its derivatives, such as
>         resource_size_t) which can vary based on build options, regardless of
>         the width of the CPU data path. Passed by reference.
>
> So the above prints the value of vmcore_base as expected.

Thanks a lot Mark for explaining :-)

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> The %pa* printk format specifiers take the value by reference (as
> phys_addr_t and friends are not necessarily the same width as a
> pointer). Per Documentation/printk-formats.txt:
>
> Physical addresses types phys_addr_t:
>
>         %pa[p]  0x01234567 or 0x0123456789abcdef
>
>         For printing a phys_addr_t type (and its derivatives, such as
>         resource_size_t) which can vary based on build options, regardless of
>         the width of the CPU data path. Passed by reference.
>
> So the above prints the value of vmcore_base as expected.

Thanks a lot Mark for explaining :-)

Reviewed-by: Pratyush Anand <panand@redhat.com>

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> The %pa* printk format specifiers take the value by reference (as
> phys_addr_t and friends are not necessarily the same width as a
> pointer). Per Documentation/printk-formats.txt:
>
> Physical addresses types phys_addr_t:
>
>         %pa[p]  0x01234567 or 0x0123456789abcdef
>
>         For printing a phys_addr_t type (and its derivatives, such as
>         resource_size_t) which can vary based on build options, regardless of
>         the width of the CPU data path. Passed by reference.
>
> So the above prints the value of vmcore_base as expected.

Thanks a lot Mark for explaining :-)

Reviewed-by: Pratyush Anand <panand@redhat.com>

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

This patch is clearly related to kdump. The prefix of subject should be
changed to kdump. Kexec doesn't need to handle vmcore things. 

And patches realted to kexec/kdump should be CCed to Andrew, he usually
picks up and add them into akpm tree.

Hi Pratyush,

Could you please help tell why arm PAE kernel can be put above 4G?
Since the change is related to common code, I am curious about how
it's so different with other ARCHs.

Thanks
Baoquan


On 04/29/16 at 09:17pm, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> >> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> >> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> >>
> >> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
> >
> > The %pa* printk format specifiers take the value by reference (as
> > phys_addr_t and friends are not necessarily the same width as a
> > pointer). Per Documentation/printk-formats.txt:
> >
> > Physical addresses types phys_addr_t:
> >
> >         %pa[p]  0x01234567 or 0x0123456789abcdef
> >
> >         For printing a phys_addr_t type (and its derivatives, such as
> >         resource_size_t) which can vary based on build options, regardless of
> >         the width of the CPU data path. Passed by reference.
> >
> > So the above prints the value of vmcore_base as expected.
> 
> Thanks a lot Mark for explaining :-)
> 
> Reviewed-by: Pratyush Anand <panand@redhat.com>
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

This patch is clearly related to kdump. The prefix of subject should be
changed to kdump. Kexec doesn't need to handle vmcore things. 

And patches realted to kexec/kdump should be CCed to Andrew, he usually
picks up and add them into akpm tree.

Hi Pratyush,

Could you please help tell why arm PAE kernel can be put above 4G?
Since the change is related to common code, I am curious about how
it's so different with other ARCHs.

Thanks
Baoquan


On 04/29/16 at 09:17pm, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> >> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> >> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> >>
> >> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
> >
> > The %pa* printk format specifiers take the value by reference (as
> > phys_addr_t and friends are not necessarily the same width as a
> > pointer). Per Documentation/printk-formats.txt:
> >
> > Physical addresses types phys_addr_t:
> >
> >         %pa[p]  0x01234567 or 0x0123456789abcdef
> >
> >         For printing a phys_addr_t type (and its derivatives, such as
> >         resource_size_t) which can vary based on build options, regardless of
> >         the width of the CPU data path. Passed by reference.
> >
> > So the above prints the value of vmcore_base as expected.
> 
> Thanks a lot Mark for explaining :-)
> 
> Reviewed-by: Pratyush Anand <panand@redhat.com>
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

This patch is clearly related to kdump. The prefix of subject should be
changed to kdump. Kexec doesn't need to handle vmcore things. 

And patches realted to kexec/kdump should be CCed to Andrew, he usually
picks up and add them into akpm tree.

Hi Pratyush,

Could you please help tell why arm PAE kernel can be put above 4G?
Since the change is related to common code, I am curious about how
it's so different with other ARCHs.

Thanks
Baoquan


On 04/29/16 at 09:17pm, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> >> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> >> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> >>
> >> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
> >
> > The %pa* printk format specifiers take the value by reference (as
> > phys_addr_t and friends are not necessarily the same width as a
> > pointer). Per Documentation/printk-formats.txt:
> >
> > Physical addresses types phys_addr_t:
> >
> >         %pa[p]  0x01234567 or 0x0123456789abcdef
> >
> >         For printing a phys_addr_t type (and its derivatives, such as
> >         resource_size_t) which can vary based on build options, regardless of
> >         the width of the CPU data path. Passed by reference.
> >
> > So the above prints the value of vmcore_base as expected.
> 
> Thanks a lot Mark for explaining :-)
> 
> Reviewed-by: Pratyush Anand <panand@redhat.com>
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

This patch is clearly related to kdump. The prefix of subject should be
changed to kdump. Kexec doesn't need to handle vmcore things. 

And patches realted to kexec/kdump should be CCed to Andrew, he usually
picks up and add them into akpm tree.

Hi Pratyush,

Could you please help tell why arm PAE kernel can be put above 4G?
Since the change is related to common code, I am curious about how
it's so different with other ARCHs.

Thanks
Baoquan


On 04/29/16 at 09:17pm, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> >> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> >> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> >>
> >> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
> >
> > The %pa* printk format specifiers take the value by reference (as
> > phys_addr_t and friends are not necessarily the same width as a
> > pointer). Per Documentation/printk-formats.txt:
> >
> > Physical addresses types phys_addr_t:
> >
> >         %pa[p]  0x01234567 or 0x0123456789abcdef
> >
> >         For printing a phys_addr_t type (and its derivatives, such as
> >         resource_size_t) which can vary based on build options, regardless of
> >         the width of the CPU data path. Passed by reference.
> >
> > So the above prints the value of vmcore_base as expected.
> 
> Thanks a lot Mark for explaining :-)
> 
> Reviewed-by: Pratyush Anand <panand@redhat.com>
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

Hi Baoquan,

On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> Hi Pratyush,
> 
> Could you please help tell why arm PAE kernel can be put above 4G?

PAE system can have physical addresses above 4G. So, if a CPU is supporting the
LPAE page table format then we should be able to access physical addresses
beyond 4G.

> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
seems most appropriate. So, kernel variable may land into above 4G locations,
even with the platform in other architecture (with PAE support), if start of RAM
is located very high,

So, in my opinion it would be safer to have these changes for other ARCHs as
well.

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

Hi Baoquan,

On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> Hi Pratyush,
> 
> Could you please help tell why arm PAE kernel can be put above 4G?

PAE system can have physical addresses above 4G. So, if a CPU is supporting the
LPAE page table format then we should be able to access physical addresses
beyond 4G.

> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
seems most appropriate. So, kernel variable may land into above 4G locations,
even with the platform in other architecture (with PAE support), if start of RAM
is located very high,

So, in my opinion it would be safer to have these changes for other ARCHs as
well.

~Pratyush

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

Hi Baoquan,

On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> Hi Pratyush,
> 
> Could you please help tell why arm PAE kernel can be put above 4G?

PAE system can have physical addresses above 4G. So, if a CPU is supporting the
LPAE page table format then we should be able to access physical addresses
beyond 4G.

> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
seems most appropriate. So, kernel variable may land into above 4G locations,
even with the platform in other architecture (with PAE support), if start of RAM
is located very high,

So, in my opinion it would be safer to have these changes for other ARCHs as
well.

~Pratyush

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

Hi Baoquan,

On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> Hi Pratyush,
> 
> Could you please help tell why arm PAE kernel can be put above 4G?

PAE system can have physical addresses above 4G. So, if a CPU is supporting the
LPAE page table format then we should be able to access physical addresses
beyond 4G.

> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
seems most appropriate. So, kernel variable may land into above 4G locations,
even with the platform in other architecture (with PAE support), if start of RAM
is located very high,

So, in my opinion it would be safer to have these changes for other ARCHs as
well.

~Pratyush

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:23am, Pratyush Anand wrote:
> Hi Baoquan,
> 
> On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> > Hi Pratyush,
> > 
> > Could you please help tell why arm PAE kernel can be put above 4G?
> 
> PAE system can have physical addresses above 4G. So, if a CPU is supporting the
> LPAE page table format then we should be able to access physical addresses
> beyond 4G.

OK, after patient explanation from Pratush on irc, I finally understand on
arm LPAE there's PHYS_OFFSET which indicats the physical address of main
memory since arm could map some amount of device memory to cpu address space
below 4G. Then physical ram has to be started from above 4G form cpu
point of view. That's why kernel need be put above 4G. It's fair enough to
fix it in this patch. Certainly if this explanation is also added into
patch log, non arm developer will understand the change better.

Thanks
Baoquan

> 
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
> seems most appropriate. So, kernel variable may land into above 4G locations,
> even with the platform in other architecture (with PAE support), if start of RAM
> is located very high,
> 
> So, in my opinion it would be safer to have these changes for other ARCHs as
> well.
> 
> ~Pratyush
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:23am, Pratyush Anand wrote:
> Hi Baoquan,
> 
> On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> > Hi Pratyush,
> > 
> > Could you please help tell why arm PAE kernel can be put above 4G?
> 
> PAE system can have physical addresses above 4G. So, if a CPU is supporting the
> LPAE page table format then we should be able to access physical addresses
> beyond 4G.

OK, after patient explanation from Pratush on irc, I finally understand on
arm LPAE there's PHYS_OFFSET which indicats the physical address of main
memory since arm could map some amount of device memory to cpu address space
below 4G. Then physical ram has to be started from above 4G form cpu
point of view. That's why kernel need be put above 4G. It's fair enough to
fix it in this patch. Certainly if this explanation is also added into
patch log, non arm developer will understand the change better.

Thanks
Baoquan

> 
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
> seems most appropriate. So, kernel variable may land into above 4G locations,
> even with the platform in other architecture (with PAE support), if start of RAM
> is located very high,
> 
> So, in my opinion it would be safer to have these changes for other ARCHs as
> well.
> 
> ~Pratyush
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:23am, Pratyush Anand wrote:
> Hi Baoquan,
> 
> On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> > Hi Pratyush,
> > 
> > Could you please help tell why arm PAE kernel can be put above 4G?
> 
> PAE system can have physical addresses above 4G. So, if a CPU is supporting the
> LPAE page table format then we should be able to access physical addresses
> beyond 4G.

OK, after patient explanation from Pratush on irc, I finally understand on
arm LPAE there's PHYS_OFFSET which indicats the physical address of main
memory since arm could map some amount of device memory to cpu address space
below 4G. Then physical ram has to be started from above 4G form cpu
point of view. That's why kernel need be put above 4G. It's fair enough to
fix it in this patch. Certainly if this explanation is also added into
patch log, non arm developer will understand the change better.

Thanks
Baoquan

> 
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
> seems most appropriate. So, kernel variable may land into above 4G locations,
> even with the platform in other architecture (with PAE support), if start of RAM
> is located very high,
> 
> So, in my opinion it would be safer to have these changes for other ARCHs as
> well.
> 
> ~Pratyush
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:23am, Pratyush Anand wrote:
> Hi Baoquan,
> 
> On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> > Hi Pratyush,
> > 
> > Could you please help tell why arm PAE kernel can be put above 4G?
> 
> PAE system can have physical addresses above 4G. So, if a CPU is supporting the
> LPAE page table format then we should be able to access physical addresses
> beyond 4G.

OK, after patient explanation from Pratush on irc, I finally understand on
arm LPAE there's PHYS_OFFSET which indicats the physical address of main
memory since arm could map some amount of device memory to cpu address space
below 4G. Then physical ram has to be started from above 4G form cpu
point of view. That's why kernel need be put above 4G. It's fair enough to
fix it in this patch. Certainly if this explanation is also added into
patch log, non arm developer will understand the change better.

Thanks
Baoquan

> 
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
> seems most appropriate. So, kernel variable may land into above 4G locations,
> even with the platform in other architecture (with PAE support), if start of RAM
> is located very high,
> 
> So, in my opinion it would be safer to have these changes for other ARCHs as
> well.
> 
> ~Pratyush
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> Could you please help tell why arm PAE kernel can be put above 4G?
> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

This is explained in the covering email to the series.

The explanation given by Pratyush was incomplete.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> Could you please help tell why arm PAE kernel can be put above 4G?
> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

This is explained in the covering email to the series.

The explanation given by Pratyush was incomplete.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> Could you please help tell why arm PAE kernel can be put above 4G?
> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

This is explained in the covering email to the series.

The explanation given by Pratyush was incomplete.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> Could you please help tell why arm PAE kernel can be put above 4G?
> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

This is explained in the covering email to the series.

The explanation given by Pratyush was incomplete.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:12am, Russell King - ARM Linux wrote:
> On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> > Could you please help tell why arm PAE kernel can be put above 4G?
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> This is explained in the covering email to the series.
> 
> The explanation given by Pratyush was incomplete.

Yeah, he said non LPAE also has PHYS_OFFSET later to me. In fact this
patch is totally unharmful to other ARCHes, I just can't stand the
curiosity. Sorry about this.

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:12am, Russell King - ARM Linux wrote:
> On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> > Could you please help tell why arm PAE kernel can be put above 4G?
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> This is explained in the covering email to the series.
> 
> The explanation given by Pratyush was incomplete.

Yeah, he said non LPAE also has PHYS_OFFSET later to me. In fact this
patch is totally unharmful to other ARCHes, I just can't stand the
curiosity. Sorry about this.

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:12am, Russell King - ARM Linux wrote:
> On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> > Could you please help tell why arm PAE kernel can be put above 4G?
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> This is explained in the covering email to the series.
> 
> The explanation given by Pratyush was incomplete.

Yeah, he said non LPAE also has PHYS_OFFSET later to me. In fact this
patch is totally unharmful to other ARCHes, I just can't stand the
curiosity. Sorry about this.

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Baoquan He]

On 05/03/16 at 11:12am, Russell King - ARM Linux wrote:
> On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> > Could you please help tell why arm PAE kernel can be put above 4G?
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
> 
> This is explained in the covering email to the series.
> 
> The explanation given by Pratyush was incomplete.

Yeah, he said non LPAE also has PHYS_OFFSET later to me. In fact this
patch is totally unharmful to other ARCHes, I just can't stand the
curiosity. Sorry about this.

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > index 152da4a48867..9f1920d2d0c6 100644
> > --- a/kernel/ksysfs.c
> > +++ b/kernel/ksysfs.c
> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
> >                                struct kobj_attribute *attr, char *buf)
> >  {
> > -       return sprintf(buf, "%lx %x\n",
> > -                      paddr_vmcoreinfo_note(),
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

You seem to not know what the "%pa" format string means.

%p always takes a _pointer_ as per C standard, so the printf argument
must be a pointer.  However, the kernel format strings are extended
with additional suffixes - in this case 'a', which means that we want
to print the contents of a _pointer_ to a phys_addr_t.

Full details in Documentation/printk-formats.txt in the kernel.

The code above is correct.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > index 152da4a48867..9f1920d2d0c6 100644
> > --- a/kernel/ksysfs.c
> > +++ b/kernel/ksysfs.c
> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
> >                                struct kobj_attribute *attr, char *buf)
> >  {
> > -       return sprintf(buf, "%lx %x\n",
> > -                      paddr_vmcoreinfo_note(),
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

You seem to not know what the "%pa" format string means.

%p always takes a _pointer_ as per C standard, so the printf argument
must be a pointer.  However, the kernel format strings are extended
with additional suffixes - in this case 'a', which means that we want
to print the contents of a _pointer_ to a phys_addr_t.

Full details in Documentation/printk-formats.txt in the kernel.

The code above is correct.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > index 152da4a48867..9f1920d2d0c6 100644
> > --- a/kernel/ksysfs.c
> > +++ b/kernel/ksysfs.c
> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
> >                                struct kobj_attribute *attr, char *buf)
> >  {
> > -       return sprintf(buf, "%lx %x\n",
> > -                      paddr_vmcoreinfo_note(),
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

You seem to not know what the "%pa" format string means.

%p always takes a _pointer_ as per C standard, so the printf argument
must be a pointer.  However, the kernel format strings are extended
with additional suffixes - in this case 'a', which means that we want
to print the contents of a _pointer_ to a phys_addr_t.

Full details in Documentation/printk-formats.txt in the kernel.

The code above is correct.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > index 152da4a48867..9f1920d2d0c6 100644
> > --- a/kernel/ksysfs.c
> > +++ b/kernel/ksysfs.c
> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
> >                                struct kobj_attribute *attr, char *buf)
> >  {
> > -       return sprintf(buf, "%lx %x\n",
> > -                      paddr_vmcoreinfo_note(),
> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
> 
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?

You seem to not know what the "%pa" format string means.

%p always takes a _pointer_ as per C standard, so the printf argument
must be a pointer.  However, the kernel format strings are extended
with additional suffixes - in this case 'a', which means that we want
to print the contents of a _pointer_ to a phys_addr_t.

Full details in Documentation/printk-formats.txt in the kernel.

The code above is correct.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:36 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
>> > index 152da4a48867..9f1920d2d0c6 100644
>> > --- a/kernel/ksysfs.c
>> > +++ b/kernel/ksysfs.c
>> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>> >                                struct kobj_attribute *attr, char *buf)
>> >  {
>> > -       return sprintf(buf, "%lx %x\n",
>> > -                      paddr_vmcoreinfo_note(),
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> You seem to not know what the "%pa" format string means.

Apologies, Yes, yes.. it was my negligence.

>
> %p always takes a _pointer_ as per C standard, so the printf argument
> must be a pointer.  However, the kernel format strings are extended
> with additional suffixes - in this case 'a', which means that we want
> to print the contents of a _pointer_ to a phys_addr_t.
>
> Full details in Documentation/printk-formats.txt in the kernel.

Thanks for explaining :-)

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:36 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
>> > index 152da4a48867..9f1920d2d0c6 100644
>> > --- a/kernel/ksysfs.c
>> > +++ b/kernel/ksysfs.c
>> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>> >                                struct kobj_attribute *attr, char *buf)
>> >  {
>> > -       return sprintf(buf, "%lx %x\n",
>> > -                      paddr_vmcoreinfo_note(),
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> You seem to not know what the "%pa" format string means.

Apologies, Yes, yes.. it was my negligence.

>
> %p always takes a _pointer_ as per C standard, so the printf argument
> must be a pointer.  However, the kernel format strings are extended
> with additional suffixes - in this case 'a', which means that we want
> to print the contents of a _pointer_ to a phys_addr_t.
>
> Full details in Documentation/printk-formats.txt in the kernel.

Thanks for explaining :-)

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:36 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
>> > index 152da4a48867..9f1920d2d0c6 100644
>> > --- a/kernel/ksysfs.c
>> > +++ b/kernel/ksysfs.c
>> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>> >                                struct kobj_attribute *attr, char *buf)
>> >  {
>> > -       return sprintf(buf, "%lx %x\n",
>> > -                      paddr_vmcoreinfo_note(),
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> You seem to not know what the "%pa" format string means.

Apologies, Yes, yes.. it was my negligence.

>
> %p always takes a _pointer_ as per C standard, so the printf argument
> must be a pointer.  However, the kernel format strings are extended
> with additional suffixes - in this case 'a', which means that we want
> to print the contents of a _pointer_ to a phys_addr_t.
>
> Full details in Documentation/printk-formats.txt in the kernel.

Thanks for explaining :-)

[PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

[Pratyush Anand]

On Fri, Apr 29, 2016 at 11:36 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> <rmk+kernel@arm.linux.org.uk> wrote:
>> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
>> > index 152da4a48867..9f1920d2d0c6 100644
>> > --- a/kernel/ksysfs.c
>> > +++ b/kernel/ksysfs.c
>> > @@ -128,8 +128,8 @@ KERNEL_ATTR_RW(kexec_crash_size);
>> >  static ssize_t vmcoreinfo_show(struct kobject *kobj,
>> >                                struct kobj_attribute *attr, char *buf)
>> >  {
>> > -       return sprintf(buf, "%lx %x\n",
>> > -                      paddr_vmcoreinfo_note(),
>> > +       phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > +       return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
>
> You seem to not know what the "%pa" format string means.

Apologies, Yes, yes.. it was my negligence.

>
> %p always takes a _pointer_ as per C standard, so the printf argument
> must be a pointer.  However, the kernel format strings are extended
> with additional suffixes - in this case 'a', which means that we want
> to print the contents of a _pointer_ to a phys_addr_t.
>
> Full details in Documentation/printk-formats.txt in the kernel.

Thanks for explaining :-)

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King]

kexec physical addresses are the boot-time view of the system.  For
certain ARM systems (such as Keystone 2), the boot view of the system
does not match the kernel's view of the system: the boot view uses a
special alias in the lower 4GB of the physical address space.

To cater for these kinds of setups, we need to translate between the
boot view physical addresses and the normal kernel view physical
addresses.  This patch extracts the current transation points into
linux/kexec.h, and allows an architecture to override the functions.

Due to the translations required, we unfortunately end up with six
translation functions, which are reduced down to four that the
architecture can override.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
 kernel/kexec.c        |  3 ++-
 kernel/kexec_core.c   | 26 +++++++++++++-------------
 3 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 52a3a221bcb2..99cb9dac7909 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
 int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 					unsigned int relsec);
 
+#ifndef page_to_boot_pfn
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page);
+}
+#endif
+
+#ifndef boot_pfn_to_page
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn);
+}
+#endif
+
+#ifndef phys_to_boot_phys
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys;
+}
+#endif
+
+#ifndef boot_phys_to_phys
+static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
+{
+	return boot_phys;
+}
+#endif
+
+static inline unsigned long virt_to_boot_phys(void *addr)
+{
+	return phys_to_boot_phys(__pa((unsigned long)addr));
+}
+
+static inline void *boot_phys_to_virt(unsigned long entry)
+{
+	return phys_to_virt(boot_phys_to_phys(entry));
+}
+
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
 struct task_struct;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index ee70aef5cd81..dd49d572a5e2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
 
 	if (kexec_on_panic) {
 		/* Verify we have a valid entry point */
-		if ((entry < crashk_res.start) || (entry > crashk_res.end))
+		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+		    (entry > phys_to_boot_phys(crashk_res.end)))
 			return -EADDRNOTAVAIL;
 	}
 
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f9847e5822e6..d04940ccc58d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
 			mstart = image->segment[i].mem;
 			mend = mstart + image->segment[i].memsz - 1;
 			/* Ensure we are within the crash kernel limits */
-			if ((mstart < crashk_res.start) ||
-			    (mend > crashk_res.end))
+			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+			    (mend > phys_to_boot_phys(crashk_res.end)))
 				return result;
 		}
 	}
@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
 		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
 		if (!pages)
 			break;
-		pfn   = page_to_pfn(pages);
+		pfn   = page_to_boot_pfn(pages);
 		epfn  = pfn + count;
 		addr  = pfn << PAGE_SHIFT;
 		eaddr = epfn << PAGE_SHIFT;
@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
 			return -ENOMEM;
 
 		ind_page = page_address(page);
-		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
 		image->entry = ind_page;
 		image->last_entry = ind_page +
 				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
 	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
 		ptr = (entry & IND_INDIRECTION) ? \
-			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
 
 static void kimage_free_entry(kimage_entry_t entry)
 {
 	struct page *page;
 
-	page = pfn_to_page(entry >> PAGE_SHIFT);
+	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
 	kimage_free_pages(page);
 }
 
@@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 	 * have a match.
 	 */
 	list_for_each_entry(page, &image->dest_pages, lru) {
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 		if (addr == destination) {
 			list_del(&page->lru);
 			return page;
@@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
 		if (!page)
 			return NULL;
 		/* If the page cannot be used file it away */
-		if (page_to_pfn(page) >
+		if (page_to_boot_pfn(page) >
 				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
 			list_add(&page->lru, &image->unusable_pages);
 			continue;
 		}
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 
 		/* If it is the destination page we want use it */
 		if (addr == destination)
@@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			struct page *old_page;
 
 			old_addr = *old & PAGE_MASK;
-			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
+			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
 			copy_highpage(page, old_page);
 			*old = addr | (*old & ~PAGE_MASK);
 
@@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
 			result  = -ENOMEM;
 			goto out;
 		}
-		result = kimage_add_page(image, page_to_pfn(page)
+		result = kimage_add_page(image, page_to_boot_pfn(page)
 								<< PAGE_SHIFT);
 		if (result < 0)
 			goto out;
@@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
 		char *ptr;
 		size_t uchunk, mchunk;
 
-		page = pfn_to_page(maddr >> PAGE_SHIFT);
+		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
 		if (!page) {
 			result  = -ENOMEM;
 			goto out;
@@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
 	unsigned long addr;
 
 	for (addr = begin; addr < end; addr += PAGE_SIZE)
-		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
+		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
 }
 
 int crash_shrink_memory(unsigned long new_size)
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King]

kexec physical addresses are the boot-time view of the system.  For
certain ARM systems (such as Keystone 2), the boot view of the system
does not match the kernel's view of the system: the boot view uses a
special alias in the lower 4GB of the physical address space.

To cater for these kinds of setups, we need to translate between the
boot view physical addresses and the normal kernel view physical
addresses.  This patch extracts the current transation points into
linux/kexec.h, and allows an architecture to override the functions.

Due to the translations required, we unfortunately end up with six
translation functions, which are reduced down to four that the
architecture can override.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
 kernel/kexec.c        |  3 ++-
 kernel/kexec_core.c   | 26 +++++++++++++-------------
 3 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 52a3a221bcb2..99cb9dac7909 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
 int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 					unsigned int relsec);
 
+#ifndef page_to_boot_pfn
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page);
+}
+#endif
+
+#ifndef boot_pfn_to_page
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn);
+}
+#endif
+
+#ifndef phys_to_boot_phys
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys;
+}
+#endif
+
+#ifndef boot_phys_to_phys
+static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
+{
+	return boot_phys;
+}
+#endif
+
+static inline unsigned long virt_to_boot_phys(void *addr)
+{
+	return phys_to_boot_phys(__pa((unsigned long)addr));
+}
+
+static inline void *boot_phys_to_virt(unsigned long entry)
+{
+	return phys_to_virt(boot_phys_to_phys(entry));
+}
+
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
 struct task_struct;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index ee70aef5cd81..dd49d572a5e2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
 
 	if (kexec_on_panic) {
 		/* Verify we have a valid entry point */
-		if ((entry < crashk_res.start) || (entry > crashk_res.end))
+		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+		    (entry > phys_to_boot_phys(crashk_res.end)))
 			return -EADDRNOTAVAIL;
 	}
 
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f9847e5822e6..d04940ccc58d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
 			mstart = image->segment[i].mem;
 			mend = mstart + image->segment[i].memsz - 1;
 			/* Ensure we are within the crash kernel limits */
-			if ((mstart < crashk_res.start) ||
-			    (mend > crashk_res.end))
+			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+			    (mend > phys_to_boot_phys(crashk_res.end)))
 				return result;
 		}
 	}
@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
 		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
 		if (!pages)
 			break;
-		pfn   = page_to_pfn(pages);
+		pfn   = page_to_boot_pfn(pages);
 		epfn  = pfn + count;
 		addr  = pfn << PAGE_SHIFT;
 		eaddr = epfn << PAGE_SHIFT;
@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
 			return -ENOMEM;
 
 		ind_page = page_address(page);
-		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
 		image->entry = ind_page;
 		image->last_entry = ind_page +
 				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
 	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
 		ptr = (entry & IND_INDIRECTION) ? \
-			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
 
 static void kimage_free_entry(kimage_entry_t entry)
 {
 	struct page *page;
 
-	page = pfn_to_page(entry >> PAGE_SHIFT);
+	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
 	kimage_free_pages(page);
 }
 
@@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 	 * have a match.
 	 */
 	list_for_each_entry(page, &image->dest_pages, lru) {
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 		if (addr == destination) {
 			list_del(&page->lru);
 			return page;
@@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
 		if (!page)
 			return NULL;
 		/* If the page cannot be used file it away */
-		if (page_to_pfn(page) >
+		if (page_to_boot_pfn(page) >
 				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
 			list_add(&page->lru, &image->unusable_pages);
 			continue;
 		}
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 
 		/* If it is the destination page we want use it */
 		if (addr == destination)
@@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			struct page *old_page;
 
 			old_addr = *old & PAGE_MASK;
-			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
+			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
 			copy_highpage(page, old_page);
 			*old = addr | (*old & ~PAGE_MASK);
 
@@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
 			result  = -ENOMEM;
 			goto out;
 		}
-		result = kimage_add_page(image, page_to_pfn(page)
+		result = kimage_add_page(image, page_to_boot_pfn(page)
 								<< PAGE_SHIFT);
 		if (result < 0)
 			goto out;
@@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
 		char *ptr;
 		size_t uchunk, mchunk;
 
-		page = pfn_to_page(maddr >> PAGE_SHIFT);
+		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
 		if (!page) {
 			result  = -ENOMEM;
 			goto out;
@@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
 	unsigned long addr;
 
 	for (addr = begin; addr < end; addr += PAGE_SIZE)
-		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
+		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
 }
 
 int crash_shrink_memory(unsigned long new_size)
-- 
2.1.0

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King]

kexec physical addresses are the boot-time view of the system.  For
certain ARM systems (such as Keystone 2), the boot view of the system
does not match the kernel's view of the system: the boot view uses a
special alias in the lower 4GB of the physical address space.

To cater for these kinds of setups, we need to translate between the
boot view physical addresses and the normal kernel view physical
addresses.  This patch extracts the current transation points into
linux/kexec.h, and allows an architecture to override the functions.

Due to the translations required, we unfortunately end up with six
translation functions, which are reduced down to four that the
architecture can override.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
 kernel/kexec.c        |  3 ++-
 kernel/kexec_core.c   | 26 +++++++++++++-------------
 3 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 52a3a221bcb2..99cb9dac7909 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
 int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 					unsigned int relsec);
 
+#ifndef page_to_boot_pfn
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page);
+}
+#endif
+
+#ifndef boot_pfn_to_page
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn);
+}
+#endif
+
+#ifndef phys_to_boot_phys
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys;
+}
+#endif
+
+#ifndef boot_phys_to_phys
+static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
+{
+	return boot_phys;
+}
+#endif
+
+static inline unsigned long virt_to_boot_phys(void *addr)
+{
+	return phys_to_boot_phys(__pa((unsigned long)addr));
+}
+
+static inline void *boot_phys_to_virt(unsigned long entry)
+{
+	return phys_to_virt(boot_phys_to_phys(entry));
+}
+
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
 struct task_struct;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index ee70aef5cd81..dd49d572a5e2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
 
 	if (kexec_on_panic) {
 		/* Verify we have a valid entry point */
-		if ((entry < crashk_res.start) || (entry > crashk_res.end))
+		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+		    (entry > phys_to_boot_phys(crashk_res.end)))
 			return -EADDRNOTAVAIL;
 	}
 
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f9847e5822e6..d04940ccc58d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
 			mstart = image->segment[i].mem;
 			mend = mstart + image->segment[i].memsz - 1;
 			/* Ensure we are within the crash kernel limits */
-			if ((mstart < crashk_res.start) ||
-			    (mend > crashk_res.end))
+			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+			    (mend > phys_to_boot_phys(crashk_res.end)))
 				return result;
 		}
 	}
@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
 		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
 		if (!pages)
 			break;
-		pfn   = page_to_pfn(pages);
+		pfn   = page_to_boot_pfn(pages);
 		epfn  = pfn + count;
 		addr  = pfn << PAGE_SHIFT;
 		eaddr = epfn << PAGE_SHIFT;
@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
 			return -ENOMEM;
 
 		ind_page = page_address(page);
-		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
 		image->entry = ind_page;
 		image->last_entry = ind_page +
 				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
 	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
 		ptr = (entry & IND_INDIRECTION) ? \
-			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
 
 static void kimage_free_entry(kimage_entry_t entry)
 {
 	struct page *page;
 
-	page = pfn_to_page(entry >> PAGE_SHIFT);
+	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
 	kimage_free_pages(page);
 }
 
@@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 	 * have a match.
 	 */
 	list_for_each_entry(page, &image->dest_pages, lru) {
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 		if (addr == destination) {
 			list_del(&page->lru);
 			return page;
@@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
 		if (!page)
 			return NULL;
 		/* If the page cannot be used file it away */
-		if (page_to_pfn(page) >
+		if (page_to_boot_pfn(page) >
 				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
 			list_add(&page->lru, &image->unusable_pages);
 			continue;
 		}
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 
 		/* If it is the destination page we want use it */
 		if (addr == destination)
@@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			struct page *old_page;
 
 			old_addr = *old & PAGE_MASK;
-			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
+			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
 			copy_highpage(page, old_page);
 			*old = addr | (*old & ~PAGE_MASK);
 
@@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
 			result  = -ENOMEM;
 			goto out;
 		}
-		result = kimage_add_page(image, page_to_pfn(page)
+		result = kimage_add_page(image, page_to_boot_pfn(page)
 								<< PAGE_SHIFT);
 		if (result < 0)
 			goto out;
@@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
 		char *ptr;
 		size_t uchunk, mchunk;
 
-		page = pfn_to_page(maddr >> PAGE_SHIFT);
+		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
 		if (!page) {
 			result  = -ENOMEM;
 			goto out;
@@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
 	unsigned long addr;
 
 	for (addr = begin; addr < end; addr += PAGE_SIZE)
-		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
+		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
 }
 
 int crash_shrink_memory(unsigned long new_size)
-- 
2.1.0

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King]

kexec physical addresses are the boot-time view of the system.  For
certain ARM systems (such as Keystone 2), the boot view of the system
does not match the kernel's view of the system: the boot view uses a
special alias in the lower 4GB of the physical address space.

To cater for these kinds of setups, we need to translate between the
boot view physical addresses and the normal kernel view physical
addresses.  This patch extracts the current transation points into
linux/kexec.h, and allows an architecture to override the functions.

Due to the translations required, we unfortunately end up with six
translation functions, which are reduced down to four that the
architecture can override.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
 kernel/kexec.c        |  3 ++-
 kernel/kexec_core.c   | 26 +++++++++++++-------------
 3 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 52a3a221bcb2..99cb9dac7909 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
 int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 					unsigned int relsec);
 
+#ifndef page_to_boot_pfn
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page);
+}
+#endif
+
+#ifndef boot_pfn_to_page
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn);
+}
+#endif
+
+#ifndef phys_to_boot_phys
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys;
+}
+#endif
+
+#ifndef boot_phys_to_phys
+static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
+{
+	return boot_phys;
+}
+#endif
+
+static inline unsigned long virt_to_boot_phys(void *addr)
+{
+	return phys_to_boot_phys(__pa((unsigned long)addr));
+}
+
+static inline void *boot_phys_to_virt(unsigned long entry)
+{
+	return phys_to_virt(boot_phys_to_phys(entry));
+}
+
 #else /* !CONFIG_KEXEC_CORE */
 struct pt_regs;
 struct task_struct;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index ee70aef5cd81..dd49d572a5e2 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
 
 	if (kexec_on_panic) {
 		/* Verify we have a valid entry point */
-		if ((entry < crashk_res.start) || (entry > crashk_res.end))
+		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
+		    (entry > phys_to_boot_phys(crashk_res.end)))
 			return -EADDRNOTAVAIL;
 	}
 
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f9847e5822e6..d04940ccc58d 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
 			mstart = image->segment[i].mem;
 			mend = mstart + image->segment[i].memsz - 1;
 			/* Ensure we are within the crash kernel limits */
-			if ((mstart < crashk_res.start) ||
-			    (mend > crashk_res.end))
+			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
+			    (mend > phys_to_boot_phys(crashk_res.end)))
 				return result;
 		}
 	}
@@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
 		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
 		if (!pages)
 			break;
-		pfn   = page_to_pfn(pages);
+		pfn   = page_to_boot_pfn(pages);
 		epfn  = pfn + count;
 		addr  = pfn << PAGE_SHIFT;
 		eaddr = epfn << PAGE_SHIFT;
@@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
 			return -ENOMEM;
 
 		ind_page = page_address(page);
-		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
 		image->entry = ind_page;
 		image->last_entry = ind_page +
 				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
 	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
 		ptr = (entry & IND_INDIRECTION) ? \
-			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
+			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
 
 static void kimage_free_entry(kimage_entry_t entry)
 {
 	struct page *page;
 
-	page = pfn_to_page(entry >> PAGE_SHIFT);
+	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
 	kimage_free_pages(page);
 }
 
@@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 	 * have a match.
 	 */
 	list_for_each_entry(page, &image->dest_pages, lru) {
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 		if (addr = destination) {
 			list_del(&page->lru);
 			return page;
@@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
 		if (!page)
 			return NULL;
 		/* If the page cannot be used file it away */
-		if (page_to_pfn(page) >
+		if (page_to_boot_pfn(page) >
 				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
 			list_add(&page->lru, &image->unusable_pages);
 			continue;
 		}
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
 
 		/* If it is the destination page we want use it */
 		if (addr = destination)
@@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			struct page *old_page;
 
 			old_addr = *old & PAGE_MASK;
-			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
+			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
 			copy_highpage(page, old_page);
 			*old = addr | (*old & ~PAGE_MASK);
 
@@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
 			result  = -ENOMEM;
 			goto out;
 		}
-		result = kimage_add_page(image, page_to_pfn(page)
+		result = kimage_add_page(image, page_to_boot_pfn(page)
 								<< PAGE_SHIFT);
 		if (result < 0)
 			goto out;
@@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
 		char *ptr;
 		size_t uchunk, mchunk;
 
-		page = pfn_to_page(maddr >> PAGE_SHIFT);
+		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
 		if (!page) {
 			result  = -ENOMEM;
 			goto out;
@@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
 	unsigned long addr;
 
 	for (addr = begin; addr < end; addr += PAGE_SIZE)
-		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
+		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
 }
 
 int crash_shrink_memory(unsigned long new_size)
-- 
2.1.0

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
>
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
>
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

I must be missing something when I am thinking that, had we passed
arch_phys_to_idmap_offset to user space, this patch would not have
been needed, and things would have been more simpler. Please help me
to understand why passing arch_phys_to_idmap_offset to user space
would not be a good idea.

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
>
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
>
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

I must be missing something when I am thinking that, had we passed
arch_phys_to_idmap_offset to user space, this patch would not have
been needed, and things would have been more simpler. Please help me
to understand why passing arch_phys_to_idmap_offset to user space
would not be a good idea.

~Pratyush

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
>
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
>
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

I must be missing something when I am thinking that, had we passed
arch_phys_to_idmap_offset to user space, this patch would not have
been needed, and things would have been more simpler. Please help me
to understand why passing arch_phys_to_idmap_offset to user space
would not be a good idea.

~Pratyush

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Pratyush Anand]

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
<rmk+kernel@arm.linux.org.uk> wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
>
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
>
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

I must be missing something when I am thinking that, had we passed
arch_phys_to_idmap_offset to user space, this patch would not have
been needed, and things would have been more simpler. Please help me
to understand why passing arch_phys_to_idmap_offset to user space
would not be a good idea.

~Pratyush

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:44:29PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > kexec physical addresses are the boot-time view of the system.  For
> > certain ARM systems (such as Keystone 2), the boot view of the system
> > does not match the kernel's view of the system: the boot view uses a
> > special alias in the lower 4GB of the physical address space.
> >
> > To cater for these kinds of setups, we need to translate between the
> > boot view physical addresses and the normal kernel view physical
> > addresses.  This patch extracts the current transation points into
> > linux/kexec.h, and allows an architecture to override the functions.
> >
> > Due to the translations required, we unfortunately end up with six
> > translation functions, which are reduced down to four that the
> > architecture can override.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> I must be missing something when I am thinking that, had we passed
> arch_phys_to_idmap_offset to user space, this patch would not have
> been needed, and things would have been more simpler. Please help me
> to understand why passing arch_phys_to_idmap_offset to user space
> would not be a good idea.

Sorry, I disagree.

Even if we thought that passing the offset to userspace would be a
good idea, it does nothing to solve each site in this patch.  This
patch would still be necessary.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:44:29PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > kexec physical addresses are the boot-time view of the system.  For
> > certain ARM systems (such as Keystone 2), the boot view of the system
> > does not match the kernel's view of the system: the boot view uses a
> > special alias in the lower 4GB of the physical address space.
> >
> > To cater for these kinds of setups, we need to translate between the
> > boot view physical addresses and the normal kernel view physical
> > addresses.  This patch extracts the current transation points into
> > linux/kexec.h, and allows an architecture to override the functions.
> >
> > Due to the translations required, we unfortunately end up with six
> > translation functions, which are reduced down to four that the
> > architecture can override.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> I must be missing something when I am thinking that, had we passed
> arch_phys_to_idmap_offset to user space, this patch would not have
> been needed, and things would have been more simpler. Please help me
> to understand why passing arch_phys_to_idmap_offset to user space
> would not be a good idea.

Sorry, I disagree.

Even if we thought that passing the offset to userspace would be a
good idea, it does nothing to solve each site in this patch.  This
patch would still be necessary.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:44:29PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > kexec physical addresses are the boot-time view of the system.  For
> > certain ARM systems (such as Keystone 2), the boot view of the system
> > does not match the kernel's view of the system: the boot view uses a
> > special alias in the lower 4GB of the physical address space.
> >
> > To cater for these kinds of setups, we need to translate between the
> > boot view physical addresses and the normal kernel view physical
> > addresses.  This patch extracts the current transation points into
> > linux/kexec.h, and allows an architecture to override the functions.
> >
> > Due to the translations required, we unfortunately end up with six
> > translation functions, which are reduced down to four that the
> > architecture can override.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> I must be missing something when I am thinking that, had we passed
> arch_phys_to_idmap_offset to user space, this patch would not have
> been needed, and things would have been more simpler. Please help me
> to understand why passing arch_phys_to_idmap_offset to user space
> would not be a good idea.

Sorry, I disagree.

Even if we thought that passing the offset to userspace would be a
good idea, it does nothing to solve each site in this patch.  This
patch would still be necessary.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Fri, Apr 29, 2016 at 08:44:29PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> <rmk+kernel@arm.linux.org.uk> wrote:
> > kexec physical addresses are the boot-time view of the system.  For
> > certain ARM systems (such as Keystone 2), the boot view of the system
> > does not match the kernel's view of the system: the boot view uses a
> > special alias in the lower 4GB of the physical address space.
> >
> > To cater for these kinds of setups, we need to translate between the
> > boot view physical addresses and the normal kernel view physical
> > addresses.  This patch extracts the current transation points into
> > linux/kexec.h, and allows an architecture to override the functions.
> >
> > Due to the translations required, we unfortunately end up with six
> > translation functions, which are reduced down to four that the
> > architecture can override.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> I must be missing something when I am thinking that, had we passed
> arch_phys_to_idmap_offset to user space, this patch would not have
> been needed, and things would have been more simpler. Please help me
> to understand why passing arch_phys_to_idmap_offset to user space
> would not be a good idea.

Sorry, I disagree.

Even if we thought that passing the offset to userspace would be a
good idea, it does nothing to solve each site in this patch.  This
patch would still be necessary.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

I was going to send the patches to Andrew, but then I noticed this
one has received no acks.  What's the situation for this patch?

On Thu, Apr 28, 2016 at 10:28:40AM +0100, Russell King wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
> 
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
> 
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
>  kernel/kexec.c        |  3 ++-
>  kernel/kexec_core.c   | 26 +++++++++++++-------------
>  3 files changed, 53 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif
> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

I was going to send the patches to Andrew, but then I noticed this
one has received no acks.  What's the situation for this patch?

On Thu, Apr 28, 2016 at 10:28:40AM +0100, Russell King wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
> 
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
> 
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
>  kernel/kexec.c        |  3 ++-
>  kernel/kexec_core.c   | 26 +++++++++++++-------------
>  3 files changed, 53 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif
> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

I was going to send the patches to Andrew, but then I noticed this
one has received no acks.  What's the situation for this patch?

On Thu, Apr 28, 2016 at 10:28:40AM +0100, Russell King wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
> 
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
> 
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
>  kernel/kexec.c        |  3 ++-
>  kernel/kexec_core.c   | 26 +++++++++++++-------------
>  3 files changed, 53 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif
> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

I was going to send the patches to Andrew, but then I noticed this
one has received no acks.  What's the situation for this patch?

On Thu, Apr 28, 2016 at 10:28:40AM +0100, Russell King wrote:
> kexec physical addresses are the boot-time view of the system.  For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB of the physical address space.
> 
> To cater for these kinds of setups, we need to translate between the
> boot view physical addresses and the normal kernel view physical
> addresses.  This patch extracts the current transation points into
> linux/kexec.h, and allows an architecture to override the functions.
> 
> Due to the translations required, we unfortunately end up with six
> translation functions, which are reduced down to four that the
> architecture can override.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  include/linux/kexec.h | 38 ++++++++++++++++++++++++++++++++++++++
>  kernel/kexec.c        |  3 ++-
>  kernel/kexec_core.c   | 26 +++++++++++++-------------
>  3 files changed, 53 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif
> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr = destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr = destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Baoquan He]

On 04/28/16 at 10:28am, Russell King wrote:
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif

I am thinking if it's appropriate to introduce a new concept which only
exists in a certain system of a certain ARCH. Is it unavoidable? If have
to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
might not need to know about boot view physical address and kernel view
physical address things when they just want to understand kexec
implementation related to one ARCH except of ARM, even related to ARM
but not Keystone 2.

> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Baoquan He]

On 04/28/16 at 10:28am, Russell King wrote:
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif

I am thinking if it's appropriate to introduce a new concept which only
exists in a certain system of a certain ARCH. Is it unavoidable? If have
to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
might not need to know about boot view physical address and kernel view
physical address things when they just want to understand kexec
implementation related to one ARCH except of ARM, even related to ARM
but not Keystone 2.

> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Baoquan He]

On 04/28/16 at 10:28am, Russell King wrote:
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif

I am thinking if it's appropriate to introduce a new concept which only
exists in a certain system of a certain ARCH. Is it unavoidable? If have
to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
might not need to know about boot view physical address and kernel view
physical address things when they just want to understand kexec
implementation related to one ARCH except of ARM, even related to ARM
but not Keystone 2.

> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Baoquan He]

On 04/28/16 at 10:28am, Russell King wrote:
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 52a3a221bcb2..99cb9dac7909 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
>  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
>  					unsigned int relsec);
>  
> +#ifndef page_to_boot_pfn
> +static inline unsigned long page_to_boot_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +#endif

I am thinking if it's appropriate to introduce a new concept which only
exists in a certain system of a certain ARCH. Is it unavoidable? If have
to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
might not need to know about boot view physical address and kernel view
physical address things when they just want to understand kexec
implementation related to one ARCH except of ARM, even related to ARM
but not Keystone 2.

> +
> +#ifndef boot_pfn_to_page
> +static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
> +{
> +	return pfn_to_page(boot_pfn);
> +}
> +#endif
> +
> +#ifndef phys_to_boot_phys
> +static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
> +{
> +	return phys;
> +}
> +#endif
> +
> +#ifndef boot_phys_to_phys
> +static inline phys_addr_t boot_phys_to_phys(unsigned long boot_phys)
> +{
> +	return boot_phys;
> +}
> +#endif
> +
> +static inline unsigned long virt_to_boot_phys(void *addr)
> +{
> +	return phys_to_boot_phys(__pa((unsigned long)addr));
> +}
> +
> +static inline void *boot_phys_to_virt(unsigned long entry)
> +{
> +	return phys_to_virt(boot_phys_to_phys(entry));
> +}
> +
>  #else /* !CONFIG_KEXEC_CORE */
>  struct pt_regs;
>  struct task_struct;
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index ee70aef5cd81..dd49d572a5e2 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -48,7 +48,8 @@ static int kimage_alloc_init(struct kimage **rimage, unsigned long entry,
>  
>  	if (kexec_on_panic) {
>  		/* Verify we have a valid entry point */
> -		if ((entry < crashk_res.start) || (entry > crashk_res.end))
> +		if ((entry < phys_to_boot_phys(crashk_res.start)) ||
> +		    (entry > phys_to_boot_phys(crashk_res.end)))
>  			return -EADDRNOTAVAIL;
>  	}
>  
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index f9847e5822e6..d04940ccc58d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -229,8 +229,8 @@ int sanity_check_segment_list(struct kimage *image)
>  			mstart = image->segment[i].mem;
>  			mend = mstart + image->segment[i].memsz - 1;
>  			/* Ensure we are within the crash kernel limits */
> -			if ((mstart < crashk_res.start) ||
> -			    (mend > crashk_res.end))
> +			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
> +			    (mend > phys_to_boot_phys(crashk_res.end)))
>  				return result;
>  		}
>  	}
> @@ -354,7 +354,7 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  		pages = kimage_alloc_pages(KEXEC_CONTROL_MEMORY_GFP, order);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = page_to_boot_pfn(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -480,7 +480,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = virt_to_boot_phys(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -535,13 +535,13 @@ void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION) ? \
> -			phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
> +			boot_phys_to_virt((entry & PAGE_MASK)) : ptr + 1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> +	page = boot_pfn_to_page(entry >> PAGE_SHIFT);
>  	kimage_free_pages(page);
>  }
>  
> @@ -635,7 +635,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  		if (addr = destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -650,12 +650,12 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if (page_to_boot_pfn(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unusable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = page_to_boot_pfn(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr = destination)
> @@ -678,7 +678,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = boot_pfn_to_page(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -734,7 +734,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, page_to_boot_pfn(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -795,7 +795,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = boot_pfn_to_page(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -922,7 +922,7 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE)
> -		free_reserved_page(pfn_to_page(addr >> PAGE_SHIFT));
> +		free_reserved_page(boot_pfn_to_page(addr >> PAGE_SHIFT));
>  }
>  
>  int crash_shrink_memory(unsigned long new_size)
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Thu, May 12, 2016 at 02:26:27PM +0800, Baoquan He wrote:
> On 04/28/16 at 10:28am, Russell King wrote:
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index 52a3a221bcb2..99cb9dac7909 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
> >  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
> >  					unsigned int relsec);
> >  
> > +#ifndef page_to_boot_pfn
> > +static inline unsigned long page_to_boot_pfn(struct page *page)
> > +{
> > +	return page_to_pfn(page);
> > +}
> > +#endif
> 
> I am thinking if it's appropriate to introduce a new concept which only
> exists in a certain system of a certain ARCH. Is it unavoidable? If have
> to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
> might not need to know about boot view physical address and kernel view
> physical address things when they just want to understand kexec
> implementation related to one ARCH except of ARM, even related to ARM
> but not Keystone 2.

Well, what do you suggest we do instead?

Eric, please get involved in this discussion, as this was your idea.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Thu, May 12, 2016 at 02:26:27PM +0800, Baoquan He wrote:
> On 04/28/16 at 10:28am, Russell King wrote:
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index 52a3a221bcb2..99cb9dac7909 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
> >  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
> >  					unsigned int relsec);
> >  
> > +#ifndef page_to_boot_pfn
> > +static inline unsigned long page_to_boot_pfn(struct page *page)
> > +{
> > +	return page_to_pfn(page);
> > +}
> > +#endif
> 
> I am thinking if it's appropriate to introduce a new concept which only
> exists in a certain system of a certain ARCH. Is it unavoidable? If have
> to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
> might not need to know about boot view physical address and kernel view
> physical address things when they just want to understand kexec
> implementation related to one ARCH except of ARM, even related to ARM
> but not Keystone 2.

Well, what do you suggest we do instead?

Eric, please get involved in this discussion, as this was your idea.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Thu, May 12, 2016 at 02:26:27PM +0800, Baoquan He wrote:
> On 04/28/16 at 10:28am, Russell King wrote:
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index 52a3a221bcb2..99cb9dac7909 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
> >  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
> >  					unsigned int relsec);
> >  
> > +#ifndef page_to_boot_pfn
> > +static inline unsigned long page_to_boot_pfn(struct page *page)
> > +{
> > +	return page_to_pfn(page);
> > +}
> > +#endif
> 
> I am thinking if it's appropriate to introduce a new concept which only
> exists in a certain system of a certain ARCH. Is it unavoidable? If have
> to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
> might not need to know about boot view physical address and kernel view
> physical address things when they just want to understand kexec
> implementation related to one ARCH except of ARM, even related to ARM
> but not Keystone 2.

Well, what do you suggest we do instead?

Eric, please get involved in this discussion, as this was your idea.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

[Russell King - ARM Linux]

On Thu, May 12, 2016 at 02:26:27PM +0800, Baoquan He wrote:
> On 04/28/16 at 10:28am, Russell King wrote:
> > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > index 52a3a221bcb2..99cb9dac7909 100644
> > --- a/include/linux/kexec.h
> > +++ b/include/linux/kexec.h
> > @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr,
> >  int __weak arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
> >  					unsigned int relsec);
> >  
> > +#ifndef page_to_boot_pfn
> > +static inline unsigned long page_to_boot_pfn(struct page *page)
> > +{
> > +	return page_to_pfn(page);
> > +}
> > +#endif
> 
> I am thinking if it's appropriate to introduce a new concept which only
> exists in a certain system of a certain ARCH. Is it unavoidable? If have
> to can we name it as kexec_page_to_pfn/kexec_pfn_to_page, etc? People
> might not need to know about boot view physical address and kernel view
> physical address things when they just want to understand kexec
> implementation related to one ARCH except of ARM, even related to ARM
> but not Keystone 2.

Well, what do you suggest we do instead?

Eric, please get involved in this discussion, as this was your idea.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 12/12] ARM: kexec: fix kexec for Keystone 2

[Russell King]

Provide kexec with the boot view of memory by overriding the normal
kexec translation functions added in a previous patch.  We also need
to fix a call to memblock in machine_kexec_prepare() so that we
provide it with a running-view physical address rather than a boot-
view physical address.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/kexec.h    | 24 ++++++++++++++++++++++++
 arch/arm/kernel/machine_kexec.c |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
index c2b9b4bdec00..1869af6bac5c 100644
--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -53,6 +53,30 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
 /* Function pointer to optional machine-specific reinitialization */
 extern void (*kexec_reinit)(void);
 
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys_to_idmap(phys);
+}
+#define phys_to_boot_phys phys_to_boot_phys
+
+static inline phys_addr_t boot_phys_to_phys(unsigned long entry)
+{
+	return idmap_to_phys(entry);
+}
+#define boot_phys_to_phys boot_phys_to_phys
+
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page) + (arch_phys_to_idmap_offset >> PAGE_SHIFT);
+}
+#define page_to_boot_pfn page_to_boot_pfn
+
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn - (arch_phys_to_idmap_offset >> PAGE_SHIFT));
+}
+#define boot_pfn_to_page boot_pfn_to_page
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* CONFIG_KEXEC */
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 59fd0e24c56b..b18c1ea56bed 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -57,7 +57,7 @@ int machine_kexec_prepare(struct kimage *image)
 	for (i = 0; i < image->nr_segments; i++) {
 		current_segment = &image->segment[i];
 
-		if (!memblock_is_region_memory(current_segment->mem,
+		if (!memblock_is_region_memory(idmap_to_phys(current_segment->mem),
 					       current_segment->memsz))
 			return -EINVAL;
 
-- 
2.1.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 12/12] ARM: kexec: fix kexec for Keystone 2

[Russell King]

Provide kexec with the boot view of memory by overriding the normal
kexec translation functions added in a previous patch.  We also need
to fix a call to memblock in machine_kexec_prepare() so that we
provide it with a running-view physical address rather than a boot-
view physical address.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/kexec.h    | 24 ++++++++++++++++++++++++
 arch/arm/kernel/machine_kexec.c |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
index c2b9b4bdec00..1869af6bac5c 100644
--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -53,6 +53,30 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
 /* Function pointer to optional machine-specific reinitialization */
 extern void (*kexec_reinit)(void);
 
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys_to_idmap(phys);
+}
+#define phys_to_boot_phys phys_to_boot_phys
+
+static inline phys_addr_t boot_phys_to_phys(unsigned long entry)
+{
+	return idmap_to_phys(entry);
+}
+#define boot_phys_to_phys boot_phys_to_phys
+
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page) + (arch_phys_to_idmap_offset >> PAGE_SHIFT);
+}
+#define page_to_boot_pfn page_to_boot_pfn
+
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn - (arch_phys_to_idmap_offset >> PAGE_SHIFT));
+}
+#define boot_pfn_to_page boot_pfn_to_page
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* CONFIG_KEXEC */
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 59fd0e24c56b..b18c1ea56bed 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -57,7 +57,7 @@ int machine_kexec_prepare(struct kimage *image)
 	for (i = 0; i < image->nr_segments; i++) {
 		current_segment = &image->segment[i];
 
-		if (!memblock_is_region_memory(current_segment->mem,
+		if (!memblock_is_region_memory(idmap_to_phys(current_segment->mem),
 					       current_segment->memsz))
 			return -EINVAL;
 
-- 
2.1.0

[PATCH 12/12] ARM: kexec: fix kexec for Keystone 2

[Russell King]

Provide kexec with the boot view of memory by overriding the normal
kexec translation functions added in a previous patch.  We also need
to fix a call to memblock in machine_kexec_prepare() so that we
provide it with a running-view physical address rather than a boot-
view physical address.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/kexec.h    | 24 ++++++++++++++++++++++++
 arch/arm/kernel/machine_kexec.c |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
index c2b9b4bdec00..1869af6bac5c 100644
--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -53,6 +53,30 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
 /* Function pointer to optional machine-specific reinitialization */
 extern void (*kexec_reinit)(void);
 
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys_to_idmap(phys);
+}
+#define phys_to_boot_phys phys_to_boot_phys
+
+static inline phys_addr_t boot_phys_to_phys(unsigned long entry)
+{
+	return idmap_to_phys(entry);
+}
+#define boot_phys_to_phys boot_phys_to_phys
+
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page) + (arch_phys_to_idmap_offset >> PAGE_SHIFT);
+}
+#define page_to_boot_pfn page_to_boot_pfn
+
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn - (arch_phys_to_idmap_offset >> PAGE_SHIFT));
+}
+#define boot_pfn_to_page boot_pfn_to_page
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* CONFIG_KEXEC */
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 59fd0e24c56b..b18c1ea56bed 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -57,7 +57,7 @@ int machine_kexec_prepare(struct kimage *image)
 	for (i = 0; i < image->nr_segments; i++) {
 		current_segment = &image->segment[i];
 
-		if (!memblock_is_region_memory(current_segment->mem,
+		if (!memblock_is_region_memory(idmap_to_phys(current_segment->mem),
 					       current_segment->memsz))
 			return -EINVAL;
 
-- 
2.1.0

[PATCH 12/12] ARM: kexec: fix kexec for Keystone 2

[Russell King]

Provide kexec with the boot view of memory by overriding the normal
kexec translation functions added in a previous patch.  We also need
to fix a call to memblock in machine_kexec_prepare() so that we
provide it with a running-view physical address rather than a boot-
view physical address.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/include/asm/kexec.h    | 24 ++++++++++++++++++++++++
 arch/arm/kernel/machine_kexec.c |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
index c2b9b4bdec00..1869af6bac5c 100644
--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -53,6 +53,30 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
 /* Function pointer to optional machine-specific reinitialization */
 extern void (*kexec_reinit)(void);
 
+static inline unsigned long phys_to_boot_phys(phys_addr_t phys)
+{
+	return phys_to_idmap(phys);
+}
+#define phys_to_boot_phys phys_to_boot_phys
+
+static inline phys_addr_t boot_phys_to_phys(unsigned long entry)
+{
+	return idmap_to_phys(entry);
+}
+#define boot_phys_to_phys boot_phys_to_phys
+
+static inline unsigned long page_to_boot_pfn(struct page *page)
+{
+	return page_to_pfn(page) + (arch_phys_to_idmap_offset >> PAGE_SHIFT);
+}
+#define page_to_boot_pfn page_to_boot_pfn
+
+static inline struct page *boot_pfn_to_page(unsigned long boot_pfn)
+{
+	return pfn_to_page(boot_pfn - (arch_phys_to_idmap_offset >> PAGE_SHIFT));
+}
+#define boot_pfn_to_page boot_pfn_to_page
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* CONFIG_KEXEC */
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 59fd0e24c56b..b18c1ea56bed 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -57,7 +57,7 @@ int machine_kexec_prepare(struct kimage *image)
 	for (i = 0; i < image->nr_segments; i++) {
 		current_segment = &image->segment[i];
 
-		if (!memblock_is_region_memory(current_segment->mem,
+		if (!memblock_is_region_memory(idmap_to_phys(current_segment->mem),
 					       current_segment->memsz))
 			return -EINVAL;
 
-- 
2.1.0

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Simon Horman]

Hi Russell,

On Thu, Apr 28, 2016 at 10:26:44AM +0100, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.
> 
> The first three patches have been sitting in linux-next for a while.
> I'm going to put the next ARM specific three into linux-next next week.
> 
> I've sent Eric over a month ago all the patches, including the kexec
> tools patches, but I've heard nothing back.  I'm at a loss how to
> make progress on these patches - and as I'm being hassled about this,
> I'm going to be hassling the community about it, possibly with regular
> re-posts until there is some progress.

My experience is that usually Andrew Morton takes kexec patches
and that this has been the situation for many years now.

With regards to any kexec-tools patches that are appropriate for upstream:
please send them to the kexec mailing list with me CCed and I will see
about including them in the next release. If you have done so already then
I apologise for having missed them.

>  Documentation/kdump/kdump.txt     | 13 ++------
>  arch/arm/boot/dts/keystone.dtsi   |  8 +++++
>  arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
>  arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
>  arch/arm/kernel/machine_kexec.c   |  2 +-
>  arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
>  arch/arm/mach-keystone/keystone.c |  7 +----
>  arch/arm/mm/idmap.c               |  2 +-
>  arch/ia64/kernel/machine_kexec.c  |  2 +-
>  include/linux/kexec.h             | 42 +++++++++++++++++++++++--
>  kernel/kexec.c                    |  3 +-
>  kernel/kexec_core.c               | 30 +++++++++---------
>  kernel/ksysfs.c                   |  4 +--
>  13 files changed, 193 insertions(+), 47 deletions(-)
> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Simon Horman]

Hi Russell,

On Thu, Apr 28, 2016 at 10:26:44AM +0100, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.
> 
> The first three patches have been sitting in linux-next for a while.
> I'm going to put the next ARM specific three into linux-next next week.
> 
> I've sent Eric over a month ago all the patches, including the kexec
> tools patches, but I've heard nothing back.  I'm at a loss how to
> make progress on these patches - and as I'm being hassled about this,
> I'm going to be hassling the community about it, possibly with regular
> re-posts until there is some progress.

My experience is that usually Andrew Morton takes kexec patches
and that this has been the situation for many years now.

With regards to any kexec-tools patches that are appropriate for upstream:
please send them to the kexec mailing list with me CCed and I will see
about including them in the next release. If you have done so already then
I apologise for having missed them.

>  Documentation/kdump/kdump.txt     | 13 ++------
>  arch/arm/boot/dts/keystone.dtsi   |  8 +++++
>  arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
>  arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
>  arch/arm/kernel/machine_kexec.c   |  2 +-
>  arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
>  arch/arm/mach-keystone/keystone.c |  7 +----
>  arch/arm/mm/idmap.c               |  2 +-
>  arch/ia64/kernel/machine_kexec.c  |  2 +-
>  include/linux/kexec.h             | 42 +++++++++++++++++++++++--
>  kernel/kexec.c                    |  3 +-
>  kernel/kexec_core.c               | 30 +++++++++---------
>  kernel/ksysfs.c                   |  4 +--
>  13 files changed, 193 insertions(+), 47 deletions(-)
> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

[PATCH 00/12] Fixing TI Keystone2 kexec

[Simon Horman]

Hi Russell,

On Thu, Apr 28, 2016 at 10:26:44AM +0100, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.
> 
> The first three patches have been sitting in linux-next for a while.
> I'm going to put the next ARM specific three into linux-next next week.
> 
> I've sent Eric over a month ago all the patches, including the kexec
> tools patches, but I've heard nothing back.  I'm at a loss how to
> make progress on these patches - and as I'm being hassled about this,
> I'm going to be hassling the community about it, possibly with regular
> re-posts until there is some progress.

My experience is that usually Andrew Morton takes kexec patches
and that this has been the situation for many years now.

With regards to any kexec-tools patches that are appropriate for upstream:
please send them to the kexec mailing list with me CCed and I will see
about including them in the next release. If you have done so already then
I apologise for having missed them.

>  Documentation/kdump/kdump.txt     | 13 ++------
>  arch/arm/boot/dts/keystone.dtsi   |  8 +++++
>  arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
>  arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
>  arch/arm/kernel/machine_kexec.c   |  2 +-
>  arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
>  arch/arm/mach-keystone/keystone.c |  7 +----
>  arch/arm/mm/idmap.c               |  2 +-
>  arch/ia64/kernel/machine_kexec.c  |  2 +-
>  include/linux/kexec.h             | 42 +++++++++++++++++++++++--
>  kernel/kexec.c                    |  3 +-
>  kernel/kexec_core.c               | 30 +++++++++---------
>  kernel/ksysfs.c                   |  4 +--
>  13 files changed, 193 insertions(+), 47 deletions(-)
> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Simon Horman]

Hi Russell,

On Thu, Apr 28, 2016 at 10:26:44AM +0100, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.
> 
> The first three patches have been sitting in linux-next for a while.
> I'm going to put the next ARM specific three into linux-next next week.
> 
> I've sent Eric over a month ago all the patches, including the kexec
> tools patches, but I've heard nothing back.  I'm at a loss how to
> make progress on these patches - and as I'm being hassled about this,
> I'm going to be hassling the community about it, possibly with regular
> re-posts until there is some progress.

My experience is that usually Andrew Morton takes kexec patches
and that this has been the situation for many years now.

With regards to any kexec-tools patches that are appropriate for upstream:
please send them to the kexec mailing list with me CCed and I will see
about including them in the next release. If you have done so already then
I apologise for having missed them.

>  Documentation/kdump/kdump.txt     | 13 ++------
>  arch/arm/boot/dts/keystone.dtsi   |  8 +++++
>  arch/arm/include/asm/kexec.h      | 24 +++++++++++++++
>  arch/arm/include/asm/memory.h     | 38 ++++++++++++++++++-----
>  arch/arm/kernel/machine_kexec.c   |  2 +-
>  arch/arm/kernel/setup.c           | 65 +++++++++++++++++++++++++++++++++++++--
>  arch/arm/mach-keystone/keystone.c |  7 +----
>  arch/arm/mm/idmap.c               |  2 +-
>  arch/ia64/kernel/machine_kexec.c  |  2 +-
>  include/linux/kexec.h             | 42 +++++++++++++++++++++++--
>  kernel/kexec.c                    |  3 +-
>  kernel/kexec_core.c               | 30 +++++++++---------
>  kernel/ksysfs.c                   |  4 +--
>  13 files changed, 193 insertions(+), 47 deletions(-)
> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

Hi, Russell

On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.

I think getting memory ranges from device tree will be better than
adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
you can refer to the patchset.

Thanks
Dave

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

Hi, Russell

On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.

I think getting memory ranges from device tree will be better than
adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
you can refer to the patchset.

Thanks
Dave

[PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

Hi, Russell

On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.

I think getting memory ranges from device tree will be better than
adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
you can refer to the patchset.

Thanks
Dave

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

Hi, Russell

On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> These changes are required for TI Keystone2 kexec to be functional.  TI
> Keystone2 has the run-time view of physical memory above 4GiB, but with
> a boot time alias below 4GiB which can only be used during the early
> boot.
> 
> This means we need to translate run-time physical addresses (which the
> kernel uses) to boot-time physical addresses, which, having discussed
> with Eric, is what the kexec tools and kexec kernel API requires.
> 
> We publish a special set of boot time resources in /proc/iomem, which
> the (modified) kexec tools look for in preference to the normal resources.
> Hence, if these are found, the kexec tools make use of these resources,
> and thus kexec tools use the boot-time view of physical memory.

I think getting memory ranges from device tree will be better than
adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
you can refer to the patchset.

Thanks
Dave

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> Hi, Russell
> 
> On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > These changes are required for TI Keystone2 kexec to be functional.  TI
> > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > a boot time alias below 4GiB which can only be used during the early
> > boot.
> > 
> > This means we need to translate run-time physical addresses (which the
> > kernel uses) to boot-time physical addresses, which, having discussed
> > with Eric, is what the kexec tools and kexec kernel API requires.
> > 
> > We publish a special set of boot time resources in /proc/iomem, which
> > the (modified) kexec tools look for in preference to the normal resources.
> > Hence, if these are found, the kexec tools make use of these resources,
> > and thus kexec tools use the boot-time view of physical memory.
> 
> I think getting memory ranges from device tree will be better than
> adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> you can refer to the patchset.

I think you're confusing things.  DT doesn't contain the boot alias
memory ranges - it's not a separate chunk of memory.  It's an alias
of the same physical address space found higher in the physical
address range.

If we put it in DT, then we need a way to also describe that it is an
alias of some other bit of physical memory.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> Hi, Russell
> 
> On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > These changes are required for TI Keystone2 kexec to be functional.  TI
> > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > a boot time alias below 4GiB which can only be used during the early
> > boot.
> > 
> > This means we need to translate run-time physical addresses (which the
> > kernel uses) to boot-time physical addresses, which, having discussed
> > with Eric, is what the kexec tools and kexec kernel API requires.
> > 
> > We publish a special set of boot time resources in /proc/iomem, which
> > the (modified) kexec tools look for in preference to the normal resources.
> > Hence, if these are found, the kexec tools make use of these resources,
> > and thus kexec tools use the boot-time view of physical memory.
> 
> I think getting memory ranges from device tree will be better than
> adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> you can refer to the patchset.

I think you're confusing things.  DT doesn't contain the boot alias
memory ranges - it's not a separate chunk of memory.  It's an alias
of the same physical address space found higher in the physical
address range.

If we put it in DT, then we need a way to also describe that it is an
alias of some other bit of physical memory.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> Hi, Russell
> 
> On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > These changes are required for TI Keystone2 kexec to be functional.  TI
> > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > a boot time alias below 4GiB which can only be used during the early
> > boot.
> > 
> > This means we need to translate run-time physical addresses (which the
> > kernel uses) to boot-time physical addresses, which, having discussed
> > with Eric, is what the kexec tools and kexec kernel API requires.
> > 
> > We publish a special set of boot time resources in /proc/iomem, which
> > the (modified) kexec tools look for in preference to the normal resources.
> > Hence, if these are found, the kexec tools make use of these resources,
> > and thus kexec tools use the boot-time view of physical memory.
> 
> I think getting memory ranges from device tree will be better than
> adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> you can refer to the patchset.

I think you're confusing things.  DT doesn't contain the boot alias
memory ranges - it's not a separate chunk of memory.  It's an alias
of the same physical address space found higher in the physical
address range.

If we put it in DT, then we need a way to also describe that it is an
alias of some other bit of physical memory.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> Hi, Russell
> 
> On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > These changes are required for TI Keystone2 kexec to be functional.  TI
> > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > a boot time alias below 4GiB which can only be used during the early
> > boot.
> > 
> > This means we need to translate run-time physical addresses (which the
> > kernel uses) to boot-time physical addresses, which, having discussed
> > with Eric, is what the kexec tools and kexec kernel API requires.
> > 
> > We publish a special set of boot time resources in /proc/iomem, which
> > the (modified) kexec tools look for in preference to the normal resources.
> > Hence, if these are found, the kexec tools make use of these resources,
> > and thus kexec tools use the boot-time view of physical memory.
> 
> I think getting memory ranges from device tree will be better than
> adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> you can refer to the patchset.

I think you're confusing things.  DT doesn't contain the boot alias
memory ranges - it's not a separate chunk of memory.  It's an alias
of the same physical address space found higher in the physical
address range.

If we put it in DT, then we need a way to also describe that it is an
alias of some other bit of physical memory.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> > Hi, Russell
> > 
> > On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > > These changes are required for TI Keystone2 kexec to be functional.  TI
> > > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > > a boot time alias below 4GiB which can only be used during the early
> > > boot.
> > > 
> > > This means we need to translate run-time physical addresses (which the
> > > kernel uses) to boot-time physical addresses, which, having discussed
> > > with Eric, is what the kexec tools and kexec kernel API requires.
> > > 
> > > We publish a special set of boot time resources in /proc/iomem, which
> > > the (modified) kexec tools look for in preference to the normal resources.
> > > Hence, if these are found, the kexec tools make use of these resources,
> > > and thus kexec tools use the boot-time view of physical memory.
> > 
> > I think getting memory ranges from device tree will be better than
> > adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> > you can refer to the patchset.
> 
> I think you're confusing things.  DT doesn't contain the boot alias
> memory ranges - it's not a separate chunk of memory.  It's an alias
> of the same physical address space found higher in the physical
> address range.

Hmm, if we forget about kexec how does the 1st kernel get boot memory?
not from DT?

> 
> If we put it in DT, then we need a way to also describe that it is an
> alias of some other bit of physical memory.

I may missed the background, I just want kexec to get infomation just like
the normal kernel.

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Thanks
Dave

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> > Hi, Russell
> > 
> > On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > > These changes are required for TI Keystone2 kexec to be functional.  TI
> > > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > > a boot time alias below 4GiB which can only be used during the early
> > > boot.
> > > 
> > > This means we need to translate run-time physical addresses (which the
> > > kernel uses) to boot-time physical addresses, which, having discussed
> > > with Eric, is what the kexec tools and kexec kernel API requires.
> > > 
> > > We publish a special set of boot time resources in /proc/iomem, which
> > > the (modified) kexec tools look for in preference to the normal resources.
> > > Hence, if these are found, the kexec tools make use of these resources,
> > > and thus kexec tools use the boot-time view of physical memory.
> > 
> > I think getting memory ranges from device tree will be better than
> > adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> > you can refer to the patchset.
> 
> I think you're confusing things.  DT doesn't contain the boot alias
> memory ranges - it's not a separate chunk of memory.  It's an alias
> of the same physical address space found higher in the physical
> address range.

Hmm, if we forget about kexec how does the 1st kernel get boot memory?
not from DT?

> 
> If we put it in DT, then we need a way to also describe that it is an
> alias of some other bit of physical memory.

I may missed the background, I just want kexec to get infomation just like
the normal kernel.

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Thanks
Dave

[PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> > Hi, Russell
> > 
> > On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > > These changes are required for TI Keystone2 kexec to be functional.  TI
> > > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > > a boot time alias below 4GiB which can only be used during the early
> > > boot.
> > > 
> > > This means we need to translate run-time physical addresses (which the
> > > kernel uses) to boot-time physical addresses, which, having discussed
> > > with Eric, is what the kexec tools and kexec kernel API requires.
> > > 
> > > We publish a special set of boot time resources in /proc/iomem, which
> > > the (modified) kexec tools look for in preference to the normal resources.
> > > Hence, if these are found, the kexec tools make use of these resources,
> > > and thus kexec tools use the boot-time view of physical memory.
> > 
> > I think getting memory ranges from device tree will be better than
> > adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> > you can refer to the patchset.
> 
> I think you're confusing things.  DT doesn't contain the boot alias
> memory ranges - it's not a separate chunk of memory.  It's an alias
> of the same physical address space found higher in the physical
> address range.

Hmm, if we forget about kexec how does the 1st kernel get boot memory?
not from DT?

> 
> If we put it in DT, then we need a way to also describe that it is an
> alias of some other bit of physical memory.

I may missed the background, I just want kexec to get infomation just like
the normal kernel.

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Thanks
Dave

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 04:29:23PM +0800, Dave Young wrote:
> > Hi, Russell
> > 
> > On 04/28/16 at 10:26am, Russell King - ARM Linux wrote:
> > > These changes are required for TI Keystone2 kexec to be functional.  TI
> > > Keystone2 has the run-time view of physical memory above 4GiB, but with
> > > a boot time alias below 4GiB which can only be used during the early
> > > boot.
> > > 
> > > This means we need to translate run-time physical addresses (which the
> > > kernel uses) to boot-time physical addresses, which, having discussed
> > > with Eric, is what the kexec tools and kexec kernel API requires.
> > > 
> > > We publish a special set of boot time resources in /proc/iomem, which
> > > the (modified) kexec tools look for in preference to the normal resources.
> > > Hence, if these are found, the kexec tools make use of these resources,
> > > and thus kexec tools use the boot-time view of physical memory.
> > 
> > I think getting memory ranges from device tree will be better than
> > adding more stuff to /proc/iomem. Geoff's arm64 kexec patches is using dtb
> > you can refer to the patchset.
> 
> I think you're confusing things.  DT doesn't contain the boot alias
> memory ranges - it's not a separate chunk of memory.  It's an alias
> of the same physical address space found higher in the physical
> address range.

Hmm, if we forget about kexec how does the 1st kernel get boot memory?
not from DT?

> 
> If we put it in DT, then we need a way to also describe that it is an
> alias of some other bit of physical memory.

I may missed the background, I just want kexec to get infomation just like
the normal kernel.

> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Thanks
Dave

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > I think you're confusing things.  DT doesn't contain the boot alias
> > memory ranges - it's not a separate chunk of memory.  It's an alias
> > of the same physical address space found higher in the physical
> > address range.
> 
> Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> not from DT?

Just like any other ARM system, it pulls itself up by its shoe laces.

The kernel assumes that it has been placed into RAM with at least 32KiB
of writable memory below it, which it uses for the initial page tables.
It "guesses" that the executing address, rounded down to I-forget-what-
boundary gives the base address of physical memory.

It sets the page table up using that assumption.  The kernel gets going
with C code, and only _then_ parses the DTB.

If we then find that we're running on TI Keystone 2, part of the early
platform initialisation specifies to the ARM core code that the kernel
is to switch a high physical address space > 4GiB, and this provokes
a "dance" where we tear the MMU back down, run some more assembly code
to fix up the page tables, and re-initialise the MMU before returning
to the kernel C code, this time running in the high physical address
space.  This break-modify-make is an architecture requirement.  We
also record the physical address delta between the original physical
address space and the high physical address space so that we can reverse
the translation for code which needs identity mapping (eg, SMP bringup.)

The DTB only contains the high physical address space memory information,
and the kernel now parses the DTB, and sets the page tables up properly
for the running system.

> > If we put it in DT, then we need a way to also describe that it is an
> > alias of some other bit of physical memory.
> 
> I may missed the background, I just want kexec to get infomation just like
> the normal kernel.

See above.  What you're asking for isn't really possible.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > I think you're confusing things.  DT doesn't contain the boot alias
> > memory ranges - it's not a separate chunk of memory.  It's an alias
> > of the same physical address space found higher in the physical
> > address range.
> 
> Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> not from DT?

Just like any other ARM system, it pulls itself up by its shoe laces.

The kernel assumes that it has been placed into RAM with at least 32KiB
of writable memory below it, which it uses for the initial page tables.
It "guesses" that the executing address, rounded down to I-forget-what-
boundary gives the base address of physical memory.

It sets the page table up using that assumption.  The kernel gets going
with C code, and only _then_ parses the DTB.

If we then find that we're running on TI Keystone 2, part of the early
platform initialisation specifies to the ARM core code that the kernel
is to switch a high physical address space > 4GiB, and this provokes
a "dance" where we tear the MMU back down, run some more assembly code
to fix up the page tables, and re-initialise the MMU before returning
to the kernel C code, this time running in the high physical address
space.  This break-modify-make is an architecture requirement.  We
also record the physical address delta between the original physical
address space and the high physical address space so that we can reverse
the translation for code which needs identity mapping (eg, SMP bringup.)

The DTB only contains the high physical address space memory information,
and the kernel now parses the DTB, and sets the page tables up properly
for the running system.

> > If we put it in DT, then we need a way to also describe that it is an
> > alias of some other bit of physical memory.
> 
> I may missed the background, I just want kexec to get infomation just like
> the normal kernel.

See above.  What you're asking for isn't really possible.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > I think you're confusing things.  DT doesn't contain the boot alias
> > memory ranges - it's not a separate chunk of memory.  It's an alias
> > of the same physical address space found higher in the physical
> > address range.
> 
> Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> not from DT?

Just like any other ARM system, it pulls itself up by its shoe laces.

The kernel assumes that it has been placed into RAM with at least 32KiB
of writable memory below it, which it uses for the initial page tables.
It "guesses" that the executing address, rounded down to I-forget-what-
boundary gives the base address of physical memory.

It sets the page table up using that assumption.  The kernel gets going
with C code, and only _then_ parses the DTB.

If we then find that we're running on TI Keystone 2, part of the early
platform initialisation specifies to the ARM core code that the kernel
is to switch a high physical address space > 4GiB, and this provokes
a "dance" where we tear the MMU back down, run some more assembly code
to fix up the page tables, and re-initialise the MMU before returning
to the kernel C code, this time running in the high physical address
space.  This break-modify-make is an architecture requirement.  We
also record the physical address delta between the original physical
address space and the high physical address space so that we can reverse
the translation for code which needs identity mapping (eg, SMP bringup.)

The DTB only contains the high physical address space memory information,
and the kernel now parses the DTB, and sets the page tables up properly
for the running system.

> > If we put it in DT, then we need a way to also describe that it is an
> > alias of some other bit of physical memory.
> 
> I may missed the background, I just want kexec to get infomation just like
> the normal kernel.

See above.  What you're asking for isn't really possible.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Russell King - ARM Linux]

On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > I think you're confusing things.  DT doesn't contain the boot alias
> > memory ranges - it's not a separate chunk of memory.  It's an alias
> > of the same physical address space found higher in the physical
> > address range.
> 
> Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> not from DT?

Just like any other ARM system, it pulls itself up by its shoe laces.

The kernel assumes that it has been placed into RAM with at least 32KiB
of writable memory below it, which it uses for the initial page tables.
It "guesses" that the executing address, rounded down to I-forget-what-
boundary gives the base address of physical memory.

It sets the page table up using that assumption.  The kernel gets going
with C code, and only _then_ parses the DTB.

If we then find that we're running on TI Keystone 2, part of the early
platform initialisation specifies to the ARM core code that the kernel
is to switch a high physical address space > 4GiB, and this provokes
a "dance" where we tear the MMU back down, run some more assembly code
to fix up the page tables, and re-initialise the MMU before returning
to the kernel C code, this time running in the high physical address
space.  This break-modify-make is an architecture requirement.  We
also record the physical address delta between the original physical
address space and the high physical address space so that we can reverse
the translation for code which needs identity mapping (eg, SMP bringup.)

The DTB only contains the high physical address space memory information,
and the kernel now parses the DTB, and sets the page tables up properly
for the running system.

> > If we put it in DT, then we need a way to also describe that it is an
> > alias of some other bit of physical memory.
> 
> I may missed the background, I just want kexec to get infomation just like
> the normal kernel.

See above.  What you're asking for isn't really possible.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 10:32am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > > I think you're confusing things.  DT doesn't contain the boot alias
> > > memory ranges - it's not a separate chunk of memory.  It's an alias
> > > of the same physical address space found higher in the physical
> > > address range.
> > 
> > Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> > not from DT?
> 
> Just like any other ARM system, it pulls itself up by its shoe laces.
> 
> The kernel assumes that it has been placed into RAM with at least 32KiB
> of writable memory below it, which it uses for the initial page tables.
> It "guesses" that the executing address, rounded down to I-forget-what-
> boundary gives the base address of physical memory.
> 
> It sets the page table up using that assumption.  The kernel gets going
> with C code, and only _then_ parses the DTB.
> 
> If we then find that we're running on TI Keystone 2, part of the early
> platform initialisation specifies to the ARM core code that the kernel
> is to switch a high physical address space > 4GiB, and this provokes
> a "dance" where we tear the MMU back down, run some more assembly code
> to fix up the page tables, and re-initialise the MMU before returning
> to the kernel C code, this time running in the high physical address
> space.  This break-modify-make is an architecture requirement.  We
> also record the physical address delta between the original physical
> address space and the high physical address space so that we can reverse
> the translation for code which needs identity mapping (eg, SMP bringup.)
> 
> The DTB only contains the high physical address space memory information,
> and the kernel now parses the DTB, and sets the page tables up properly
> for the running system.

Thanks for the explanation, so the DTB does not contain the delta info
Please ignore the noise then.

> 
> > > If we put it in DT, then we need a way to also describe that it is an
> > > alias of some other bit of physical memory.
> > 
> > I may missed the background, I just want kexec to get infomation just like
> > the normal kernel.
> 
> See above.  What you're asking for isn't really possible.



_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 10:32am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > > I think you're confusing things.  DT doesn't contain the boot alias
> > > memory ranges - it's not a separate chunk of memory.  It's an alias
> > > of the same physical address space found higher in the physical
> > > address range.
> > 
> > Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> > not from DT?
> 
> Just like any other ARM system, it pulls itself up by its shoe laces.
> 
> The kernel assumes that it has been placed into RAM with at least 32KiB
> of writable memory below it, which it uses for the initial page tables.
> It "guesses" that the executing address, rounded down to I-forget-what-
> boundary gives the base address of physical memory.
> 
> It sets the page table up using that assumption.  The kernel gets going
> with C code, and only _then_ parses the DTB.
> 
> If we then find that we're running on TI Keystone 2, part of the early
> platform initialisation specifies to the ARM core code that the kernel
> is to switch a high physical address space > 4GiB, and this provokes
> a "dance" where we tear the MMU back down, run some more assembly code
> to fix up the page tables, and re-initialise the MMU before returning
> to the kernel C code, this time running in the high physical address
> space.  This break-modify-make is an architecture requirement.  We
> also record the physical address delta between the original physical
> address space and the high physical address space so that we can reverse
> the translation for code which needs identity mapping (eg, SMP bringup.)
> 
> The DTB only contains the high physical address space memory information,
> and the kernel now parses the DTB, and sets the page tables up properly
> for the running system.

Thanks for the explanation, so the DTB does not contain the delta info
Please ignore the noise then.

> 
> > > If we put it in DT, then we need a way to also describe that it is an
> > > alias of some other bit of physical memory.
> > 
> > I may missed the background, I just want kexec to get infomation just like
> > the normal kernel.
> 
> See above.  What you're asking for isn't really possible.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 10:32am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > > I think you're confusing things.  DT doesn't contain the boot alias
> > > memory ranges - it's not a separate chunk of memory.  It's an alias
> > > of the same physical address space found higher in the physical
> > > address range.
> > 
> > Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> > not from DT?
> 
> Just like any other ARM system, it pulls itself up by its shoe laces.
> 
> The kernel assumes that it has been placed into RAM with at least 32KiB
> of writable memory below it, which it uses for the initial page tables.
> It "guesses" that the executing address, rounded down to I-forget-what-
> boundary gives the base address of physical memory.
> 
> It sets the page table up using that assumption.  The kernel gets going
> with C code, and only _then_ parses the DTB.
> 
> If we then find that we're running on TI Keystone 2, part of the early
> platform initialisation specifies to the ARM core code that the kernel
> is to switch a high physical address space > 4GiB, and this provokes
> a "dance" where we tear the MMU back down, run some more assembly code
> to fix up the page tables, and re-initialise the MMU before returning
> to the kernel C code, this time running in the high physical address
> space.  This break-modify-make is an architecture requirement.  We
> also record the physical address delta between the original physical
> address space and the high physical address space so that we can reverse
> the translation for code which needs identity mapping (eg, SMP bringup.)
> 
> The DTB only contains the high physical address space memory information,
> and the kernel now parses the DTB, and sets the page tables up properly
> for the running system.

Thanks for the explanation, so the DTB does not contain the delta info
Please ignore the noise then.

> 
> > > If we put it in DT, then we need a way to also describe that it is an
> > > alias of some other bit of physical memory.
> > 
> > I may missed the background, I just want kexec to get infomation just like
> > the normal kernel.
> 
> See above.  What you're asking for isn't really possible.

Re: [PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 10:32am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > > I think you're confusing things.  DT doesn't contain the boot alias
> > > memory ranges - it's not a separate chunk of memory.  It's an alias
> > > of the same physical address space found higher in the physical
> > > address range.
> > 
> > Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> > not from DT?
> 
> Just like any other ARM system, it pulls itself up by its shoe laces.
> 
> The kernel assumes that it has been placed into RAM with at least 32KiB
> of writable memory below it, which it uses for the initial page tables.
> It "guesses" that the executing address, rounded down to I-forget-what-
> boundary gives the base address of physical memory.
> 
> It sets the page table up using that assumption.  The kernel gets going
> with C code, and only _then_ parses the DTB.
> 
> If we then find that we're running on TI Keystone 2, part of the early
> platform initialisation specifies to the ARM core code that the kernel
> is to switch a high physical address space > 4GiB, and this provokes
> a "dance" where we tear the MMU back down, run some more assembly code
> to fix up the page tables, and re-initialise the MMU before returning
> to the kernel C code, this time running in the high physical address
> space.  This break-modify-make is an architecture requirement.  We
> also record the physical address delta between the original physical
> address space and the high physical address space so that we can reverse
> the translation for code which needs identity mapping (eg, SMP bringup.)
> 
> The DTB only contains the high physical address space memory information,
> and the kernel now parses the DTB, and sets the page tables up properly
> for the running system.

Thanks for the explanation, so the DTB does not contain the delta info
Please ignore the noise then.

> 
> > > If we put it in DT, then we need a way to also describe that it is an
> > > alias of some other bit of physical memory.
> > 
> > I may missed the background, I just want kexec to get infomation just like
> > the normal kernel.
> 
> See above.  What you're asking for isn't really possible.