* [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit
@ 2018-03-26 18:11 Maciej W. Rozycki
2018-03-26 18:11 ` Maciej W. Rozycki
2018-03-27 9:24 ` James Hogan
0 siblings, 2 replies; 5+ messages in thread
From: Maciej W. Rozycki @ 2018-03-26 18:11 UTC (permalink / raw)
To: James Hogan; +Cc: Ralf Baechle, Maxim Uvarov, linux-mips, stable
Make the default for PHYSICAL_START always 64-bit, ensuring that a
correct sign-extended value is used if a 32-bit image is loaded by a
64-bit system, and matching how the load address is set in platform
Makefile fragments (arch/mips/*/Platform) in the absence of the
PHYSICAL_START configuration option.
Of course PHYSICAL_START itself is a misnomer as the load address is
virtual rather than physical (or otherwise sign-extension would not
apply).
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
Fixes: 7aa1c8f47e7e ("MIPS: kdump: Add support")
Cc: stable@vger.kernel.org # 3.8+
---
Hi James,
As discussed in the context of commit 27c524d17430 ("MIPS: Use the entry
point from the ELF file header"). This may require verifying by someone
who actually uses this feature. I have cc-ed Maxim, the original author,
in case he has anything to add.
I'm not sure if we want to do anything about the physical vs virtual load
address confusion.
Please consider.
Maciej
---
arch/mips/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
linux-mips-physical-start.diff
Index: linux-jhogan-test/arch/mips/Kconfig
===================================================================
--- linux-jhogan-test.orig/arch/mips/Kconfig 2018-03-21 17:22:12.000000000 +0000
+++ linux-jhogan-test/arch/mips/Kconfig 2018-03-23 09:19:25.049100000 +0000
@@ -2849,8 +2849,7 @@ config CRASH_DUMP
config PHYSICAL_START
hex "Physical address where the kernel is loaded"
- default "0xffffffff84000000" if 64BIT
- default "0x84000000" if 32BIT
+ default "0xffffffff84000000"
depends on CRASH_DUMP
help
This gives the CKSEG0 or KSEG0 address where the kernel is loaded.
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit
2018-03-26 18:11 [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit Maciej W. Rozycki
@ 2018-03-26 18:11 ` Maciej W. Rozycki
2018-03-27 9:24 ` James Hogan
1 sibling, 0 replies; 5+ messages in thread
From: Maciej W. Rozycki @ 2018-03-26 18:11 UTC (permalink / raw)
To: James Hogan; +Cc: Ralf Baechle, Maxim Uvarov, linux-mips, stable
Make the default for PHYSICAL_START always 64-bit, ensuring that a
correct sign-extended value is used if a 32-bit image is loaded by a
64-bit system, and matching how the load address is set in platform
Makefile fragments (arch/mips/*/Platform) in the absence of the
PHYSICAL_START configuration option.
Of course PHYSICAL_START itself is a misnomer as the load address is
virtual rather than physical (or otherwise sign-extension would not
apply).
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
Fixes: 7aa1c8f47e7e ("MIPS: kdump: Add support")
Cc: stable@vger.kernel.org # 3.8+
---
Hi James,
As discussed in the context of commit 27c524d17430 ("MIPS: Use the entry
point from the ELF file header"). This may require verifying by someone
who actually uses this feature. I have cc-ed Maxim, the original author,
in case he has anything to add.
I'm not sure if we want to do anything about the physical vs virtual load
address confusion.
Please consider.
Maciej
---
arch/mips/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
linux-mips-physical-start.diff
Index: linux-jhogan-test/arch/mips/Kconfig
===================================================================
--- linux-jhogan-test.orig/arch/mips/Kconfig 2018-03-21 17:22:12.000000000 +0000
+++ linux-jhogan-test/arch/mips/Kconfig 2018-03-23 09:19:25.049100000 +0000
@@ -2849,8 +2849,7 @@ config CRASH_DUMP
config PHYSICAL_START
hex "Physical address where the kernel is loaded"
- default "0xffffffff84000000" if 64BIT
- default "0x84000000" if 32BIT
+ default "0xffffffff84000000"
depends on CRASH_DUMP
help
This gives the CKSEG0 or KSEG0 address where the kernel is loaded.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit
2018-03-26 18:11 [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit Maciej W. Rozycki
2018-03-26 18:11 ` Maciej W. Rozycki
@ 2018-03-27 9:24 ` James Hogan
2018-03-27 11:07 ` Maciej W. Rozycki
1 sibling, 1 reply; 5+ messages in thread
From: James Hogan @ 2018-03-27 9:24 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, Maxim Uvarov, linux-mips, stable
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Mon, Mar 26, 2018 at 07:11:51PM +0100, Maciej W. Rozycki wrote:
> Make the default for PHYSICAL_START always 64-bit, ensuring that a
> correct sign-extended value is used if a 32-bit image is loaded by a
> 64-bit system, and matching how the load address is set in platform
> Makefile fragments (arch/mips/*/Platform) in the absence of the
> PHYSICAL_START configuration option.
This looks correct given the defaults in the Makefile fragments. However
I presume a 32BIT kernel will produce a 32-bit ELF, in which case the
result will be indistinguishable? For other kernel image formats which
always use 64-bit pointers perhaps it matters more (if they can be
loaded by kexec-tools). uImage is 32-bit ISTR, and our ITB stuff seems
to only use 32bit addresses for CONFIG_32BIT. I don't now about other
formats.
So unless I hear otherwise I'll probably drop the stable tag and apply
for 4.17.
Thanks
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit
2018-03-27 9:24 ` James Hogan
@ 2018-03-27 11:07 ` Maciej W. Rozycki
2018-03-27 11:07 ` Maciej W. Rozycki
0 siblings, 1 reply; 5+ messages in thread
From: Maciej W. Rozycki @ 2018-03-27 11:07 UTC (permalink / raw)
To: James Hogan; +Cc: Ralf Baechle, Maxim Uvarov, linux-mips, stable
On Tue, 27 Mar 2018, James Hogan wrote:
> > Make the default for PHYSICAL_START always 64-bit, ensuring that a
> > correct sign-extended value is used if a 32-bit image is loaded by a
> > 64-bit system, and matching how the load address is set in platform
> > Makefile fragments (arch/mips/*/Platform) in the absence of the
> > PHYSICAL_START configuration option.
>
> This looks correct given the defaults in the Makefile fragments. However
> I presume a 32BIT kernel will produce a 32-bit ELF, in which case the
> result will be indistinguishable? For other kernel image formats which
> always use 64-bit pointers perhaps it matters more (if they can be
> loaded by kexec-tools). uImage is 32-bit ISTR, and our ITB stuff seems
> to only use 32bit addresses for CONFIG_32BIT. I don't now about other
> formats.
For ELF it does not matter, but as you say $VMLINUX_LOAD_ADDRESS and
$VMLINUX_ENTRY_ADDRESS is needed for software which does not interpret ELF
files. However my interpretation is based solely on source examination
and the commit description and not actual use of these features. I assume
platform Makefile fragments do use 64-bit representation for a reason
though.
> So unless I hear otherwise I'll probably drop the stable tag and apply
> for 4.17.
I won't insist on backporting. After all it's the default only and the
value can be entered manually if the default does not work.
Maciej
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit
2018-03-27 11:07 ` Maciej W. Rozycki
@ 2018-03-27 11:07 ` Maciej W. Rozycki
0 siblings, 0 replies; 5+ messages in thread
From: Maciej W. Rozycki @ 2018-03-27 11:07 UTC (permalink / raw)
To: James Hogan; +Cc: Ralf Baechle, Maxim Uvarov, linux-mips, stable
On Tue, 27 Mar 2018, James Hogan wrote:
> > Make the default for PHYSICAL_START always 64-bit, ensuring that a
> > correct sign-extended value is used if a 32-bit image is loaded by a
> > 64-bit system, and matching how the load address is set in platform
> > Makefile fragments (arch/mips/*/Platform) in the absence of the
> > PHYSICAL_START configuration option.
>
> This looks correct given the defaults in the Makefile fragments. However
> I presume a 32BIT kernel will produce a 32-bit ELF, in which case the
> result will be indistinguishable? For other kernel image formats which
> always use 64-bit pointers perhaps it matters more (if they can be
> loaded by kexec-tools). uImage is 32-bit ISTR, and our ITB stuff seems
> to only use 32bit addresses for CONFIG_32BIT. I don't now about other
> formats.
For ELF it does not matter, but as you say $VMLINUX_LOAD_ADDRESS and
$VMLINUX_ENTRY_ADDRESS is needed for software which does not interpret ELF
files. However my interpretation is based solely on source examination
and the commit description and not actual use of these features. I assume
platform Makefile fragments do use 64-bit representation for a reason
though.
> So unless I hear otherwise I'll probably drop the stable tag and apply
> for 4.17.
I won't insist on backporting. After all it's the default only and the
value can be entered manually if the default does not work.
Maciej
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-03-27 11:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-26 18:11 [PATCH] MIPS: Make the default for PHYSICAL_START always 64-bit Maciej W. Rozycki
2018-03-26 18:11 ` Maciej W. Rozycki
2018-03-27 9:24 ` James Hogan
2018-03-27 11:07 ` Maciej W. Rozycki
2018-03-27 11:07 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox