mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org, Yinghai Lu <yinghai@kernel.org>
Subject: [PATCH v5 12/13] x86, 64bit: Print init kernel lowmap correctly
Date: Tue, 27 Nov 2012 23:50:41 -0800	[thread overview]
Message-ID: <1354089042-10023-13-git-send-email-yinghai@kernel.org> (raw)
In-Reply-To: <1354089042-10023-1-git-send-email-yinghai@kernel.org>

When we get x86_64_start_kernel from arch/x86/kernel/head_64.S,

We have
1. kernel highmap 512M (KERNEL_IMAGE_SIZE) from kernel loaded address.
2. kernel lowmap: [0, 1024M), and size (_end - _text) from kernel
   loaded address.

for example, if the kernel bzImage is loaded high from 8G, will get:
1. kernel highmap:  [8G, 8G+512M)
2. kernel lowmap: [0, 1024M), and  [8G, 8G +_end - _text)

So max_pfn_mapped that is for low map pfn recording is not that
simple to 512M for 64 bit.

Try to print out two ranges, when kernel is loaded high.

Also need to use KERNEL_IMAGE_SIZE directly for highmap cleanup.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
 arch/x86/kernel/head64.c |    2 --
 arch/x86/kernel/setup.c  |   23 +++++++++++++++++++++--
 arch/x86/mm/init_64.c    |    6 +++++-
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 8ea1bc9..8d426b4 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -97,8 +97,6 @@ void __init x86_64_start_kernel(char * real_mode_data)
 	/* Make NULL pointers segfault */
 	zap_identity_mappings();
 
-	max_pfn_mapped = KERNEL_IMAGE_SIZE >> PAGE_SHIFT;
-
 	for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
 #ifdef CONFIG_EARLY_PRINTK
 		set_intr_gate(i, &early_idt_handlers[i]);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 2dbe2ce..87473fc 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -681,6 +681,26 @@ static int __init parse_reservelow(char *p)
 
 early_param("reservelow", parse_reservelow);
 
+static __init void print_init_mem_mapped(void)
+{
+#ifdef CONFIG_X86_32
+	printk(KERN_DEBUG "initial memory mapped: [mem 0x00000000-%#010lx]\n",
+			(max_pfn_mapped<<PAGE_SHIFT) - 1);
+#else
+	unsigned long text = __pa_symbol(&_text);
+	unsigned long end = round_up(__pa_symbol(_end) - 1, PMD_SIZE);
+
+	if (end <= PUD_SIZE)
+		printk(KERN_DEBUG "initial memory mapped: [mem 0x00000000-%#010lx]\n",
+			PUD_SIZE - 1);
+	else if (text <= PUD_SIZE)
+		printk(KERN_DEBUG "initial memory mapped: [mem 0x00000000-%#010lx]\n",
+			end - 1);
+	else
+		printk(KERN_DEBUG "initial memory mapped: [mem 0x00000000-%#010lx] [mem %#010lx-%#010lx]\n",
+			PUD_SIZE - 1, text, end - 1);
+#endif
+}
 /*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been
  * passed the efi memmap, systab, etc., so we should use these data structures
@@ -949,8 +969,7 @@ void __init setup_arch(char **cmdline_p)
 	setup_bios_corruption_check();
 #endif
 
-	printk(KERN_DEBUG "initial memory mapped: [mem 0x00000000-%#010lx]\n",
-			(max_pfn_mapped<<PAGE_SHIFT) - 1);
+	print_init_mem_mapped();
 
 	setup_real_mode();
 
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 4178530..30f6190 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -304,10 +304,14 @@ void __init init_extra_mapping_uc(unsigned long phys, unsigned long size)
 void __init cleanup_highmap(void)
 {
 	unsigned long vaddr = __START_KERNEL_map;
-	unsigned long vaddr_end = __START_KERNEL_map + (max_pfn_mapped << PAGE_SHIFT);
+	unsigned long vaddr_end = __START_KERNEL_map + KERNEL_IMAGE_SIZE;
 	unsigned long end = roundup((unsigned long)_brk_end, PMD_SIZE) - 1;
 	pmd_t *pmd = level2_kernel_pgt;
 
+	/* Xen has its own end somehow with abused max_pfn_mapped */
+	if (max_pfn_mapped)
+		vaddr_end = __START_KERNEL_map + (max_pfn_mapped << PAGE_SHIFT);
+
 	for (; vaddr + PMD_SIZE - 1 < vaddr_end; pmd++, vaddr += PMD_SIZE) {
 		if (pmd_none(*pmd))
 			continue;
-- 
1.7.7


  parent reply	other threads:[~2012-11-28  7:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-28  7:50 [PATCH v5 00/13] x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 01/13] x86, boot: move verify_cpu.S after 0x200 Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 02/13] x86, boot: Move lldt/ltr out of 64bit code section Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 03/13] x86, 64bit: Set extra ident mapping for whole kernel range Yinghai Lu
2012-12-21 22:28   ` Konrad Rzeszutek Wilk
2012-12-21 22:35     ` Yinghai Lu
2012-12-21 22:39       ` H. Peter Anvin
2012-12-21 22:51         ` Yinghai Lu
2012-12-21 22:54           ` H. Peter Anvin
2012-12-21 23:40       ` Konrad Rzeszutek Wilk
2012-11-28  7:50 ` [PATCH v5 04/13] x86: Merge early_reserve_initrd for 32bit and 64bit Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 05/13] x86: add get_ramdisk_image/size() Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 06/13] x86, boot: add get_cmd_line_ptr() Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 07/13] x86, boot: move checking of cmd_line_ptr out of common path Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 08/13] x86, boot: update cmd_line_ptr to unsigned long Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 09/13] x86: use io_remap to access real_mode_data Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 10/13] x86, boot: add fields to support load bzImage and ramdisk above 4G Yinghai Lu
2012-11-28  7:50 ` [PATCH v5 11/13] x86: remove 1024G limitation for kexec buffer on 64bit Yinghai Lu
2012-11-28  7:50 ` Yinghai Lu [this message]
2012-12-21 22:26   ` [PATCH v5 12/13] x86, 64bit: Print init kernel lowmap correctly Konrad Rzeszutek Wilk
2012-12-21 22:44     ` Yinghai Lu
2012-12-21 23:39       ` Konrad Rzeszutek Wilk
2012-12-21 23:52         ` Yinghai Lu
2012-12-22  2:14           ` Konrad Rzeszutek Wilk
2012-11-28  7:50 ` [PATCH v5 13/13] x86, mm: Fix page table early allocation offset checking Yinghai Lu

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=1354089042-10023-13-git-send-email-yinghai@kernel.org \
    --to=yinghai@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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