Linux IA64 platform development
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] /proc/efi_memmap
Date: Tue, 13 Sep 2005 19:30:07 +0000	[thread overview]
Message-ID: <20050913193007.GB6299@agluck-lia64.sc.intel.com> (raw)
In-Reply-To: <200509092346.j89NkDdo001318@agluck-lia64.sc.intel.com>

On Tue, Sep 13, 2005 at 10:05:03AM -0600, Khalid Aziz wrote:
> The userspace kexec tools looks at the memory map to verify a new kernel
> being loaded in memory will be loaded in memory that is normally
> available for it. Same goes for initial ramdisk as well. kexec
> opens /proc/iomem on x86 for this. I had sent a patch in July (subject
> "[PATCH] /proc/iomem update") that provides same info in /proc/iomem as
> x86 does and that will take care of kexec needs. I have already tested
> kexec tool for ia64 with that patch and it works fine.

I should dust that off and take a look at it.  /proc/iomem seems a curious
name for a file that contains this information.

So what is the current state of kexec for ia64?  I think that there
are two modes of operation:

1) Fast reboot (bypasses f/w ... which takes a significant amount of
   the reboot time).

2) A means to getting a running kernel to take a crash dump.

In case 1, the system is still running ... so kexec can load the new
kernel from disk, and arrange for an orderly transfer of control from
the old kernel to the new.

In case 2, we need to plan ahead, and have the new kernel pre-loaded
into some reserved memory so when the panic hits (or the INIT button
is pressed) we don't need to do any I/O or memory allocation.  We just
leap to the new kernel.  For this case ia64 would appear to have an
advantage over other architectures ... we don't need to locate the new
kernel at any particular address, so we can leave the original kernel
untouched while we boot just using the reserved block of memory.

What's working?  What's still being developed?  Can we get this into
shape for 2.6.15?

-Tony

  parent reply	other threads:[~2005-09-13 19:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09 23:46 [RFC] /proc/efi_memmap Luck, Tony
2005-09-12  3:29 ` KAMEZAWA Hiroyuki
2005-09-12  4:34 ` Luck, Tony
2005-09-12 15:17 ` Bjorn Helgaas
2005-09-13 16:05 ` Khalid Aziz
2005-09-13 19:30 ` Luck, Tony [this message]
2005-09-13 19:56 ` Grant Grundler
2005-09-13 22:47 ` Khalid Aziz
2005-09-13 22:52 ` Khalid Aziz

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=20050913193007.GB6299@agluck-lia64.sc.intel.com \
    --to=tony.luck@intel.com \
    --cc=linux-ia64@vger.kernel.org \
    /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