From: "H. Peter Anvin" <hpa@zytor.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: kexec@lists.infradead.org, ebiederm@xmission.com
Subject: Re: Question regardin intel64 arch and page table setup
Date: Wed, 11 Aug 2010 13:02:10 -0700 [thread overview]
Message-ID: <4C6301C2.5020808@zytor.com> (raw)
In-Reply-To: <20100811194734.GD23317@hmsreliant.think-freely.org>
On 08/11/2010 12:47 PM, Neil Horman wrote:
> Hey all-
> I've got a question regarding x86_64 and how linux uses the paging
> hardware. I'm tinkering with ways to get kexec to boot a new kernel on panic
> without leaving long mode. The idea being that if we can do that, then we don't
> need to store the new kdump kernel below the 4G physical limit for 32 bit
> systems. In doing this though, I figured I would have to re-initalize the page
> table with an identity mapped set of page tables to cover all of ram and load
> that into cr3. My question is, is it safe to do so while paging is enabled.
> The docs I've read are unclear on that and if I have to disable paging that
> automatically drops me out of long mode, which is bad. I would think its safe
> to do, since I imagined we had to do on context switches in the scheduler, but
> the __switch_to implementation for x86_64 sems to do nothing but update the task
> register. Intel vol 3a says we need to update cr3, but I don't see where that
> happens, so I'm not sure if theres some automated bit that does a cr3 update
> safely when we write tr.
>
> Anywho, any guidance, clarification would be appreciated. Thanks!
> Neil
>
It is definitely safe to load a new CR3 while paging is done; it is done
all the time. The currently executing page needs to be mapped to the
same physical and virtual address in most kernels.
However, there are a *LOT* of issues with having a kernel that is
completely above 4 GiB. For one thing, a lot of device drivers simply
will not work if there is no memory below 4 GiB awavilable to the
kernel. As such, I don't think you will be successful in this project.
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2010-08-11 20:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-11 19:47 Question regardin intel64 arch and page table setup Neil Horman
2010-08-11 20:02 ` H. Peter Anvin [this message]
2010-08-11 21:51 ` Eric W. Biederman
2010-08-11 21:54 ` Eric W. Biederman
2010-08-11 22:02 ` H. Peter Anvin
2010-08-12 0:22 ` Eric W. Biederman
2010-08-12 1:05 ` Neil Horman
2010-08-12 1:46 ` H. Peter Anvin
2010-08-12 1:53 ` H. Peter Anvin
2010-08-12 3:21 ` Eric W. Biederman
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=4C6301C2.5020808@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=nhorman@tuxdriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.