From: Muli Ben-Yehuda <muli@il.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Simon Horman <horms@verge.net.au>,
Andrew Morton <akpm@linux-foundation.org>,
Chandru <chandru@in.ibm.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Vivek Goyal <vgoyal@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Terry Loftin <terry.loftin@hp.com>,
Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr'
Date: Mon, 28 Jul 2008 09:24:46 +0300 [thread overview]
Message-ID: <20080728062446.GC12655@il.ibm.com> (raw)
In-Reply-To: <m1tzeamust.fsf@frodo.ebiederm.org>
On Sun, Jul 27, 2008 at 10:39:30PM -0700, Eric W. Biederman wrote:
> Simon Horman <horms@verge.net.au> writes:
>
> > There has long been a strong aversion to providing the second
> > kernel with flags like im_in_kexec or im_in_kdump, as its felt
> > that this kind of problem is better handled by making sure that
> > the hardware is in a sensible state before leaving the
> > first-kernel. But this is arguably more reasonable in the kexec
> > case than the kdump case.
>
> That and because we can generally solve the specific problem with a
> general feature. Something we can enable/disable on the command
> line if needed. Right now this is especially interesting as on
> several architectures distros are not building special kdump kernels
> but have a single kernel binary that works in both cases.
>
> Skimming through your patches this is a case we really do need to
> implement and handle cleanly.
>
> Currently we leave DMA running in the kexec on panic case. We avoid
> problems by only running out of a reserved area of memory.
>
> As as general strategy that is fine. However we have not
> implemented that strategy in the case of IOMMUs. And we are having
> trouble with IOMMUs.
>
> My hunch is that we should implement options to reserve a section of
> the iommu and to tell to the iommu to use the previously reserved
> section. Although turning iommus off altogether and simply using
> swiotlb may be acceptable. In which case we should just force usage
> of the swiotlb on the command line in /sbin/kexec.
With an isolation-capable IOMMU (such as Calgary, VT-d and AMD's
IOMMU) on the I/O path, as long as we want to keep DMAs running and
going through to memory, we need to keep the IOMMU running, with the
same set of permissions and translation tables. If we don't mind DMAs
failing, we need to gracefully handle IOMMU DMA faults (where
possible---Calgary can't do it at the moment). What we do instead with
Calgary (c.f., the patch that instigated this discussion) is a hack,
we "reinitialize" the IOMMU with the old IOMMU's translation tables so
that DMAs continue working.
My preference would be to have stopped all DMAs in the old kernel,
which would've made this nastiness go away. Can you explain in simple
words why we can't or won't do that?
Cheers,
Muli
next prev parent reply other threads:[~2008-07-28 6:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-26 9:25 [patch] crashdump: fix undefined reference to `elfcorehdr_addr' Ingo Molnar
2008-07-26 10:10 ` Andrew Morton
2008-07-27 23:45 ` Simon Horman
2008-07-28 1:51 ` Simon Horman
2008-07-28 2:45 ` Simon Horman
2008-07-28 3:40 ` Simon Horman
2008-07-28 12:48 ` Ingo Molnar
2008-07-29 0:35 ` Simon Horman
2008-07-28 21:10 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Vivek Goyal
2008-07-28 21:11 ` [PATCH 2/5] x86: Define elfcorehdr_addr in arch dependent section Vivek Goyal
2008-07-28 21:13 ` [PATCH 3/5] ia64: " Vivek Goyal
2008-07-28 21:14 ` [PATCH 4/5] powerpc: " Vivek Goyal
2008-07-28 21:15 ` [PATCH 5/5] sh: " Vivek Goyal
2008-07-29 14:18 ` Paul Mundt
2008-07-29 4:42 ` [PATCH 3/5] ia64: " Simon Horman
2008-07-29 13:53 ` Vivek Goyal
2008-07-31 15:29 ` [PATCH 2/5] x86: " Ingo Molnar
2008-07-28 22:37 ` [PATCH 1/5] Move elfcorehdr_addr out of vmcore.c (Was: Re: [patch] crashdump: fix undefined reference to `elfcorehdr_addr') Eric W. Biederman
2008-07-28 22:47 ` Eric W. Biederman
2008-07-29 1:22 ` Simon Horman
2008-07-29 2:28 ` Vivek Goyal
2008-07-29 3:26 ` Simon Horman
2008-07-28 5:39 ` [patch] crashdump: fix undefined reference to `elfcorehdr_addr' Eric W. Biederman
2008-07-28 6:24 ` Muli Ben-Yehuda [this message]
2008-07-28 13:44 ` Vivek Goyal
2008-07-28 19:12 ` Eric W. Biederman
2008-07-28 13:31 ` Vivek Goyal
2008-07-29 0:33 ` Simon Horman
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=20080728062446.GC12655@il.ibm.com \
--to=muli@il.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=chandru@in.ibm.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=terry.loftin@hp.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.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