Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: bob.montgomery@hp.com
Cc: "Heber, Troy" <troy.heber@hp.com>,
	"Loftin, Terry" <terry.loftin@hp.com>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: Trying to test my gart/iommu vmcore problem on RH
Date: Fri, 22 Aug 2008 16:48:10 -0700	[thread overview]
Message-ID: <m18wuofw79.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <1219442751.3361.459.camel@amd.troyhebe> (Bob Montgomery's message of "Fri, 22 Aug 2008 16:05:51 -0600")


Hmm.  Thinking about this we actually have 2 problems.
- Communication about what is going on.
- How to handle an iommu in the event of a crash dump scenario.

The current solution is to ignore the iommu, and use swiotlb.  This
solution does not look like it will work for future iommus.

The original plan (and it still sounds like a good one) was to reserve
a section of the iommu (as we do for the physical memory).  So we
could have addresses that are only used for the crash dump kernel.  Then
have the crash dump kernel just use that section of the iommu.

Either we need to do that or we need to disable the iommu, before we
use swiotlb.

The problem is we can not reliably kill on-going DMA transactions 
at the time of a kernel panic, and likely doing so would greatly
decrease our kernel reliability.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2008-08-22 23:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1218138156.3361.386.camel@amd.troyhebe>
     [not found] ` <20080808014024.GB3911@redhat.com>
     [not found]   ` <1218750773.3361.425.camel@amd.troyhebe>
     [not found]     ` <20080815131359.GA10208@redhat.com>
     [not found]       ` <1219081942.3361.436.camel@amd.troyhebe>
2008-08-19 13:47         ` Trying to test my gart/iommu vmcore problem on RH Vivek Goyal
2008-08-21  4:50           ` Eric W. Biederman
2008-08-22 22:05             ` Bob Montgomery
2008-08-22 23:48               ` Eric W. Biederman [this message]
2008-08-25 13:16                 ` Vivek Goyal
2008-08-25 13:46                   ` Eric W. Biederman
2008-09-04 23:28                     ` Bob Montgomery
2008-09-05  1:46                       ` Eric W. Biederman
2008-09-05 15:12                       ` Vivek Goyal
2008-09-09 21:12                         ` Bob Montgomery
2008-09-22 23:31                           ` Bob Montgomery
2008-09-23  2:29                             ` Eric W. Biederman
2008-09-23 19:12                               ` Bob Montgomery
2008-08-25 13:02               ` Vivek Goyal

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=m18wuofw79.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=bob.montgomery@hp.com \
    --cc=kexec@lists.infradead.org \
    --cc=terry.loftin@hp.com \
    --cc=troy.heber@hp.com \
    --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