mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: vgoyal@in.ibm.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jurriaan <thunder7@xs4all.nl>,
	Helge Hafting <helgehaf@aitel.hist.no>,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Date: Mon, 02 Apr 2007 02:43:56 -0600	[thread overview]
Message-ID: <m1abxrf9o3.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20070402074159.GA13704@in.ibm.com> (Vivek Goyal's message of "Mon, 2 Apr 2007 13:11:59 +0530")

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Sat, Mar 31, 2007 at 11:29:57PM -0700, Andrew Morton wrote:
>> On Sun, 01 Apr 2007 00:15:51 -0600 ebiederm@xmission.com (Eric W. Biederman)
> wrote:
>> 
>> > Does anyone know how to express the constraint of a 2M aligned number in
> Kconfig?
>> 
>> Nope, but we could make CONFIG_PHYSICAL_START be in units of 2MB, which
>> would be a bit hard to use.
>> 
>> Adding a BUILD_BUG_ON which checks this constraint might help.  Plus a
>> useful comment right at the BUILD_BUG_ON site explaining what to do about
>> it.
>
> How about attached patch?

Looks like that will work.

Vivek.  If I can get the x86_64 vmlinux to have type ET_DYN (to mark
it as relocatable) is there any reason to keep CONFIG_PHYSICAL_START?
I think I can switch the vmlinux header type in about 100 lines or so
of code.  Assuming I can ever get 30 minutes with the appropriate
kernel.

> Thanks
> Vivek
>
>
>
> o X86_64 kernel should run from 2MB aligned address for two reasons.
> 	- Performance.
> 	- For relocatable kernels, page tables are updated based on difference
> 	  between compile time address and load time physical address.
> 	  This difference should be multiple of 2MB as kernel text and data
> 	  is mapped using 2MB pages and PMD should be pointing to a 2MB
> 	  aligned address. Life is simpler if both compile time and load time
> 	  kernel addresses are 2MB aligned.
>
> o Flag the error at compile time if one is trying to build a kernel which
>   does not meet alignment restrictions.
>
> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
> ---
>
>  arch/x86_64/kernel/head64.c |    8 ++++++++
>  include/asm-x86_64/page.h   |    1 +
>  2 files changed, 9 insertions(+)
>
> diff -puN
> arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M
> arch/x86_64/kernel/head64.c
> ---
> linux-2.6.21-rc5-mm3-vanilla/arch/x86_64/kernel/head64.c~x86_64-check-for-config-physical-start-aligned-2M
> 2007-04-02 20:46:43.000000000 +0530
> +++ linux-2.6.21-rc5-mm3-vanilla-root/arch/x86_64/kernel/head64.c 2007-04-02
> 21:20:45.000000000 +0530
> @@ -62,6 +62,14 @@ void __init x86_64_start_kernel(char * r
>  {
>  	int i;
>  
> +	/*
> +	 * Make sure kernel is aligned to 2MB address. Catching it at compile
> +	 * time is better. Change your config file and compile the kernel
> +	 * for a 2MB aligned address (CONFIG_PHYSICAL_START)
> +	 */
> +	BUILD_BUG_ON(ALIGN(CONFIG_PHYSICAL_START, __KERNEL_ALIGN)
> +			!= CONFIG_PHYSICAL_START);

Just as a nit.
     	BUILD_BUG_ON(CONFIG_PHYSICAL_START & (__KERNEL_ALIGN - 1))
is a little shorter...   Although maybe not quite as readable.
> +
>  	/* clear bss before set_intr_gate with early_idt_handler */
>  	clear_bss();
>  
> diff -puN
> include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M
> include/asm-x86_64/page.h
> ---
> linux-2.6.21-rc5-mm3-vanilla/include/asm-x86_64/page.h~x86_64-check-for-config-physical-start-aligned-2M
> 2007-04-02 20:50:55.000000000 +0530
> +++ linux-2.6.21-rc5-mm3-vanilla-root/include/asm-x86_64/page.h 2007-04-02
> 20:51:34.000000000 +0530
> @@ -79,6 +79,7 @@ extern unsigned long phys_base;
>  #endif /* !__ASSEMBLY__ */
>  
>  #define __PHYSICAL_START	CONFIG_PHYSICAL_START
> +#define __KERNEL_ALIGN		0x200000
>  #define __START_KERNEL		(__START_KERNEL_map + __PHYSICAL_START)
>  #define __START_KERNEL_map	0xffffffff80000000
>  #define __PAGE_OFFSET           0xffff810000000000

Do we want to use the __KERNEL_ALIGN directive in the test in misc.c?

Eric

  reply	other threads:[~2007-04-02  8:44 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-30  8:05 2.6.21-rc5-mm3 Andrew Morton
2007-03-30 11:00 ` 2.6.21-rc5-mm3 Rafael J. Wysocki
2007-03-30 16:31 ` 2.6.21-rc5-mm3 Michal Piotrowski
2007-03-30 16:55   ` 2.6.21-rc5-mm3 Ingo Molnar
2007-03-30 17:19     ` 2.6.21-rc5-mm3 Michal Piotrowski
2007-03-30 16:38 ` 2.6.21-rc5-mm3 Dmitry Torokhov
2007-03-30 16:59   ` 2.6.21-rc5-mm3 Andrew Morton
2007-03-30 17:23 ` 2.6.21-rc5-mm3 Valdis.Kletnieks
2007-03-30 18:58   ` 2.6.21-rc5-mm3 Johannes Berg
2007-03-31  7:12 ` 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" Helge Hafting
2007-03-31  7:53   ` Andrew Morton
2007-03-31  8:14     ` Eric W. Biederman
2007-04-09 22:09       ` Helge Hafting
2007-04-10  4:48         ` Helge Hafting
2007-04-01  5:29     ` thunder7
2007-04-01  6:15       ` Eric W. Biederman
2007-04-01  6:29         ` Andrew Morton
2007-04-02  7:41           ` Vivek Goyal
2007-04-02  8:43             ` Eric W. Biederman [this message]
2007-04-02  9:45               ` Vivek Goyal
2007-04-02 17:26                 ` Eric W. Biederman
2007-04-03  4:01                   ` Vivek Goyal
2007-04-03  5:23                     ` Eric W. Biederman
2007-04-03 10:03                       ` Vivek Goyal
2007-04-23  5:12                         ` [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Eric W. Biederman
2007-04-23  5:15                           ` [PATCH 2/2] x86_64: Remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE Eric W. Biederman
2007-04-23  6:07                             ` Vivek Goyal
2007-04-23  6:17                               ` Eric W. Biederman
2007-04-23  6:25                                 ` Vivek Goyal
2007-04-24  6:31                           ` [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Vivek Goyal
2007-04-24  7:21                             ` Eric W. Biederman
2007-04-02 11:17             ` 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" thunder7
2007-04-02 11:36               ` Vivek Goyal
2007-04-02 14:49                 ` thunder7
2007-04-02 14:59                   ` thunder7
2007-04-03  4:05                     ` Vivek Goyal
2007-03-31  8:05 ` 2.6.21-rc5-mm3 - cpuidle, acpi, and C-states Valdis.Kletnieks
2007-03-31 19:25 ` 2.6.21-rc5-mm3: Why was my vioc cleanup patch dropped? Adrian Bunk
2007-03-31 20:48 ` [-mm patch] make drivers/ata/pata_ali.c:ali_tf_load() static Adrian Bunk
2007-04-01 16:21   ` Tejun Heo
2007-03-31 20:55 ` [2.6 patch] remove the config option for the cs5530a_warm_reset() quirk Adrian Bunk
2007-03-31 21:05   ` Jeremy Fitzhardinge
2007-03-31 21:11     ` Adrian Bunk
2007-03-31 21:17       ` Jeremy Fitzhardinge
2007-03-31 20:55 ` [-mm patch] make drivers/net/qla3xxx.c:PHY_DEVICES[] static Adrian Bunk
2007-04-04  2:34   ` Jeff Garzik
2007-03-31 20:55 ` [-mm patch] make struct proc_fdinfo_file_operations static Adrian Bunk
2007-04-01 16:00 ` 2.6.21-rc5-mm3 Michal Piotrowski
2007-04-01 19:03   ` 2.6.21-rc5-mm3 Andrew Morton
2007-04-01 20:39     ` 2.6.21-rc5-mm3 Rafael J. Wysocki
2007-04-01 20:56       ` 2.6.21-rc5-mm3 Rafael J. Wysocki
2007-04-01 21:59       ` 2.6.21-rc5-mm3 Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1abxrf9o3.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thunder7@xs4all.nl \
    --cc=vgoyal@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome