From: Ian Campbell <Ian.Campbell@XenSource.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: Horms <horms@verge.net.au>, Vivek Goyal <vgoyal@in.ibm.com>,
fastboot@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
Date: Fri, 16 Mar 2007 07:28:17 +0000 [thread overview]
Message-ID: <1174030097.28658.37.camel@localhost.localdomain> (raw)
In-Reply-To: <aec7e5c30703151940x7447abbey80cb6e47250cca58@mail.gmail.com>
On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> Right. And maybe it's a good idea to make sure that this feature is
> actually supported by kexec-tools before adding code to the kernel?
I sent patches to the fastboot list at the same time I sent these ones
to support differences in the underlying hypervisor architecture in the
tools.
They haven't appeared in the archives yet so I fear they have gone
astray. I'll resend when I get to the office in a bit.
The tools already have support for introducing a SHIM when kexecing
between different architectures (at least in the 64->32 direction if I
understand kexec-tools-testing/purgatory/arch/i386/compat_x86_64.S and
k-t-t.../kexec/arch/i386/compat_x86_64.S correctly). This is really just
an extension of that.
> My gut feeling about this is that you are begging for trouble. The
> kexec/kdump solution is fragile just by itself, and trying to go
> between architectures is just going to be painful.
It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
originally I'm not so convinced it makes sense in the native case but I
see no reason to outlaw it (people get to keep both pieces etc...)
Ian.
next prev parent reply other threads:[~2007-03-16 7:28 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
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 [this message]
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=1174030097.28658.37.camel@localhost.localdomain \
--to=ian.campbell@xensource.com \
--cc=fastboot@lists.osdl.org \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=vgoyal@in.ibm.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.