From: Zachary Amsden <zach@vmware.com>
To: norman@thebacks.co.uk,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Yinghai Lu" <yhlu.kernel@gmail.com>, mingo <mingo@elte.hu>,
"Greg KH" <gregkh@suse.de>,
"Alok Kataria" <alokkataria1@gmail.com>,
"Bruno Prémont" <"bruno .premont"@restena.lu>,
xl@xlsigned.net, dsd@gentoo.org
Subject: [PATCH] Fix VMI crash on boot in 2.6.27+ kernels
Date: Tue, 09 Dec 2008 16:50:21 -0800 [thread overview]
Message-ID: <1228870222.8766.15.camel@bodhitayantram.eng.vmware.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
Patches backported into 2.6.27.4 caused a regression with VMI kernels
running on VMware which ends in a page fault during boot. I have a fix
which still allows DMI checks to be done early.
VMI initialiation can relocate the fixmap, causing early_ioremap
to malfunction if it is initialized before the relocation. The
ioremap area is low enough in virtual address space that no actual
collision occurs, however, because the pagetables for it were not
allocated under VMI mode, the pagetable updates are dropped by
the hypervisor as irrelevant, resulting in a crash on boot.
The best fix is perhaps to move early_ioremap_init() after vmi_init().
The only things done before VMI init are basic memory access, things
like collating the memory map, collecting boot CPUID capabilities, and
parsing the early command line options... which vmi_init needs.
Since this went back into 2.6.27, it needs to go to both 2.6.28 and
eventually to stable. I didn't add any comments or anything as there
could be some debate what the proper ordering should be. In case that
becomes an interesting discussion, there are two relevant facts in git
today:
1) no clients of early_ioremap occur before DMI.
2) VMI requires access to early boot params.
If any can suggest a better ordering, I am certainly open to that as
well.
Thanks,
Zach
[-- Attachment #2: x86-vmi-boot-ioremap-fix.patch --]
[-- Type: text/x-patch, Size: 1002 bytes --]
VMI initialiation can relocate the fixmap, causing early_ioremap
to malfunction if it is initialized before the relocation. The
ioremap area is low enough in virtual address space that no actual
collision occurs, however, because the pagetables for it were not
allocated under VMI mode, the pagetable updates are dropped by
the hypervisor as irrelevant, resulting in a crash on boot.
Signed-off-by: Zachary Amsden <zach@vmware.com>
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9d5674f..9627753 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -795,7 +795,6 @@ void __init setup_arch(char **cmdline_p)
#endif
early_cpu_init();
- early_ioremap_init();
ROOT_DEV = old_decode_dev(boot_params.hdr.root_dev);
screen_info = boot_params.screen_info;
@@ -888,6 +887,8 @@ void __init setup_arch(char **cmdline_p)
vmi_init();
#endif
+ early_ioremap_init();
+
/* after early param, so could get panic from serial */
reserve_early_setup_data();
next reply other threads:[~2008-12-09 23:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-10 0:50 Zachary Amsden [this message]
2008-12-10 0:44 ` Greg KH
2008-12-10 7:30 ` Zachary Amsden
2008-12-10 1:15 ` Yinghai Lu
2008-12-10 1:48 ` H. Peter Anvin
2008-12-10 7:31 ` Zachary Amsden
2008-12-10 9:05 ` H. Peter Anvin
2008-12-10 7:36 ` Zachary Amsden
2008-12-11 0:06 ` Zachary Amsden
2008-12-11 0:20 ` Yinghai Lu
2008-12-11 3:31 ` Greg KH
2008-12-11 22:23 ` [PATCH] Fix VMI crash on boot in 2.6.27, 2.6.28 kernels Zachary Amsden
2008-12-11 21:45 ` Greg KH
2008-12-11 23:37 ` H. Peter Anvin
2008-12-12 5:37 ` Zachary Amsden
2008-12-11 5:44 ` [PATCH] Fix VMI crash on boot in 2.6.27+ kernels Zachary Amsden
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=1228870222.8766.15.camel@bodhitayantram.eng.vmware.com \
--to=zach@vmware.com \
--cc="bruno .premont"@restena.lu \
--cc=alokkataria1@gmail.com \
--cc=dsd@gentoo.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=norman@thebacks.co.uk \
--cc=torvalds@linux-foundation.org \
--cc=xl@xlsigned.net \
--cc=yhlu.kernel@gmail.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