From: Vivek Goyal <vgoyal@in.ibm.com>
To: Ian Campbell <Ian.Campbell@xensource.com>
Cc: Horms <horms@verge.net.au>,
hbabu@us.ibm.com, fastboot@lists.osdl.org,
linux-kernel@vger.kernel.org, Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
Date: Thu, 15 Mar 2007 18:56:16 +0530 [thread overview]
Message-ID: <20070315132616.GH6766@in.ibm.com> (raw)
In-Reply-To: <1173961378.8591.63.camel@localhost.localdomain>
On Thu, Mar 15, 2007 at 12:22:57PM +0000, Ian Campbell wrote:
> On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > But I think changing this macro might run into issues. It is
> > > > being used at few places in kernel, for example while loading
> > > > module. This will essentially mean that we allow loading 64bit
> > > > x86_64 modules on 32bit i386 systems?
>
> Yes, not sure how I missed that fact...
>
> > Kexec will also not allow loading an x86_64 kernel on a 32bit machine.
>
> For crash kernel only or for regular kexec too?
>
I think for both. One of the possible reasons I think is that one never
knows is underlying machine has got 64bit extensions or not. So even if
we load the kernel it will never boot. Secondly, we might not be able to
handle 64bit address in 32bit kernel/user space?
> > So how about something like vmcore_elf_allowed_cross_arch()? Vmcore
> > code can continue to check elf_check_arch() and if that fails it can
> > invoke vmcore_elf_allowed_cross_arch() to find out what cross arch are
> > allowed for vmcore.
>
> Something like this?
>
> Ian.
>
> ---
>
> Allow i386 crash kernels to handle x86_64 dumps.
>
> The specific case I am encountering is kdump under Xen with a 64 bit
> hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit
> due to the hypervisor but the dump kernel is 32 bit in for maximum
> compatibility.
>
> It's possibly less likely to be useful in a purely native scenario but
> I see no reason to disallow it.
>
> Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
>
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index d960507..523e109 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
> /* Do some basic Verification. */
> if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
> (ehdr.e_type != ET_CORE) ||
> - !elf_check_arch(&ehdr) ||
> + !vmcore_elf_check_arch(&ehdr) ||
> ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
> ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
> ehdr.e_version != EV_CURRENT ||
> diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
> index 4dfc9f5..c76737e 100644
> --- a/include/asm-i386/kexec.h
> +++ b/include/asm-i386/kexec.h
> @@ -47,6 +47,9 @@
> /* The native architecture */
> #define KEXEC_ARCH KEXEC_ARCH_386
>
> +/* We can also handle crash dumps from 64 bit kernel. */
> +#define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
> +
Ideal place for this probably should have been arch dependent crash_dump.h
file. But we don't have one and no point introducing one just for this
macro.
This change looks good to me.
Thanks
Vivek
next prev parent reply other threads:[~2007-03-15 13:26 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-14 17:00 [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps Ian Campbell
2007-03-15 1:46 ` Horms
2007-03-15 4:55 ` Vivek Goyal
2007-03-15 5:07 ` Horms
2007-03-15 5:47 ` Vivek Goyal
2007-03-15 8:00 ` Horms
2007-03-15 12:22 ` Ian Campbell
2007-03-15 13:26 ` Vivek Goyal [this message]
2007-03-15 13:42 ` Ian Campbell
2007-03-15 23:46 ` Horms
2007-03-16 2:27 ` Vivek Goyal
2007-03-15 23:48 ` Horms
2007-03-16 2:40 ` [Fastboot] " Magnus Damm
2007-03-16 3:22 ` Vivek Goyal
2007-03-16 7:10 ` Horms
2007-03-16 7:50 ` Magnus Damm
2007-03-16 7:28 ` Ian Campbell
2007-03-16 7:59 ` Magnus Damm
2007-03-16 8:50 ` Ian Campbell
2007-03-16 9:20 ` Magnus Damm
2007-03-16 9:35 ` Vivek Goyal
2007-03-16 10:05 ` Magnus Damm
2007-03-16 11:38 ` Vivek Goyal
2007-03-16 11:40 ` Ian Campbell
2007-03-16 12:25 ` Vivek Goyal
2007-03-16 12:31 ` Vivek Goyal
2007-03-16 9:26 ` Vivek Goyal
2007-03-16 2:42 ` Vivek Goyal
2007-03-16 7:31 ` Ian Campbell
2007-03-16 7:17 ` Ian Campbell
2007-03-16 7:30 ` Horms
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=20070315132616.GH6766@in.ibm.com \
--to=vgoyal@in.ibm.com \
--cc=Ian.Campbell@xensource.com \
--cc=fastboot@lists.osdl.org \
--cc=hbabu@us.ibm.com \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@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