Linux MIPS Architecture development
 help / color / mirror / Atom feed
* [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