All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: nhorman@redhat.com, nhorman@tuxdriver.com,
	Joerg Roedel <joerg.roedel@amd.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Chris Wright <chrisw@sous-sol.org>,
	hbabu@us.ibm.com, iommu@lists.linux-foundation.org,
	vgoyal@redhat.com
Subject: Re: [PATCH 3/4] Revert "x86: disable IOMMUs on kernel crash"
Date: Sun, 4 Apr 2010 10:44:36 +0200	[thread overview]
Message-ID: <20100404084435.GT24846@8bytes.org> (raw)
In-Reply-To: <m18w94l9c9.fsf@fess.ebiederm.org>

On Sat, Apr 03, 2010 at 10:44:22AM -0700, Eric W. Biederman wrote:
> Joerg Roedel <joro@8bytes.org> writes:

> > Hmm, I think for this we need to change the gart code too and disable
> > the gart before its initialization runs to not re-introduce issues fixed
> > in commit bc2cea6a34fdb30f118ec75db39a46a191870607, no?
> 
> That is a different code path with a different set of assumptions and
> restrictions.  On a normal kexec of course we want to do an orderly shutdown.

Thats another problem with this patch. It introduces a difference
between the panic-shutdown kexec and the ordinary kexec.

> For the gart with a little luck we can just ignore it on kexec on
> panic.

The commit I mentioned above already proves this assumption wrong.

> Unlike a virtualization capable iommu it doesn't prevent access
> to devices, when it is enabled.   Worst case is that we have to start
> including iommu=off for gart systems.

No no no. This is a maintenance nightmare for almost everybody. Where do
you want to Document this special cases that 'if kernel uses gart then
and only then boot the kexec kernel with iommu=off'.
Always passing iommu=off to the kexec kernel doesn't work too for
obvious reasons.

> The best case is that we can figure out how to have the gart code
> reinitialize itself sanely, starting from some arbitrary point.

Yes, that is missing in this patch. But to keep changes small and don't
bother with the gart code at all I suggest to remove the shutdown
routine from the amd-iommu code only and not the whole shutdown call in
the machine_crash_shutdown path.

	Joerg


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

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
	Joerg Roedel <joerg.roedel@amd.com>,
	nhorman@redhat.com, nhorman@tuxdriver.com,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	hbabu@us.ibm.com, iommu@lists.linux-foundation.org,
	vgoyal@redhat.com
Subject: Re: [PATCH 3/4] Revert "x86: disable IOMMUs on kernel crash"
Date: Sun, 4 Apr 2010 10:44:36 +0200	[thread overview]
Message-ID: <20100404084435.GT24846@8bytes.org> (raw)
In-Reply-To: <m18w94l9c9.fsf@fess.ebiederm.org>

On Sat, Apr 03, 2010 at 10:44:22AM -0700, Eric W. Biederman wrote:
> Joerg Roedel <joro@8bytes.org> writes:

> > Hmm, I think for this we need to change the gart code too and disable
> > the gart before its initialization runs to not re-introduce issues fixed
> > in commit bc2cea6a34fdb30f118ec75db39a46a191870607, no?
> 
> That is a different code path with a different set of assumptions and
> restrictions.  On a normal kexec of course we want to do an orderly shutdown.

Thats another problem with this patch. It introduces a difference
between the panic-shutdown kexec and the ordinary kexec.

> For the gart with a little luck we can just ignore it on kexec on
> panic.

The commit I mentioned above already proves this assumption wrong.

> Unlike a virtualization capable iommu it doesn't prevent access
> to devices, when it is enabled.   Worst case is that we have to start
> including iommu=off for gart systems.

No no no. This is a maintenance nightmare for almost everybody. Where do
you want to Document this special cases that 'if kernel uses gart then
and only then boot the kexec kernel with iommu=off'.
Always passing iommu=off to the kexec kernel doesn't work too for
obvious reasons.

> The best case is that we can figure out how to have the gart code
> reinitialize itself sanely, starting from some arbitrary point.

Yes, that is missing in this patch. But to keep changes small and don't
bother with the gart code at all I suggest to remove the shutdown
routine from the amd-iommu code only and not the whole shutdown call in
the machine_crash_shutdown path.

	Joerg


  reply	other threads:[~2010-04-04  8:44 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-03  1:27 [PATCH 0/4] AMD IOMMU kdump fix plus cleanups (v2) Chris Wright
2010-04-03  1:27 ` Chris Wright
2010-04-03  1:27 ` [PATCH 1/4] x86/amd-iommu: enable iommu before attaching devices Chris Wright
2010-04-03  1:27   ` Chris Wright
2010-04-03  1:27 ` [PATCH 2/4] x86/amd-iommu: warn when issuing command to uninitialized cmd buffer Chris Wright
2010-04-03  1:27   ` Chris Wright
2010-04-03  1:27 ` [PATCH 3/4] Revert "x86: disable IOMMUs on kernel crash" Chris Wright
2010-04-03  1:27   ` Chris Wright
2010-04-03 17:22   ` Joerg Roedel
2010-04-03 17:22     ` Joerg Roedel
2010-04-03 17:44     ` Eric W. Biederman
2010-04-03 17:44       ` Eric W. Biederman
2010-04-04  8:44       ` Joerg Roedel [this message]
2010-04-04  8:44         ` Joerg Roedel
2010-04-04  9:16         ` Eric W. Biederman
2010-04-04  9:16           ` Eric W. Biederman
2010-04-04  9:19           ` Eric W. Biederman
2010-04-04  9:19             ` Eric W. Biederman
2010-04-03 17:41   ` Joerg Roedel
2010-04-03 17:41     ` Joerg Roedel
2010-04-03 17:49     ` Eric W. Biederman
2010-04-03 17:49       ` Eric W. Biederman
2010-04-03 19:13       ` Joerg Roedel
2010-04-03 19:13         ` Joerg Roedel
2010-04-03 19:41         ` Eric W. Biederman
2010-04-03 19:41           ` Eric W. Biederman
2010-04-04  7:24       ` Bernhard Walle
2010-04-04  7:24         ` Bernhard Walle
2010-04-04  7:51         ` Eric W. Biederman
2010-04-04  7:51           ` Eric W. Biederman
2010-04-04  8:53         ` Joerg Roedel
2010-04-04  8:53           ` Joerg Roedel
2010-04-04  9:44           ` Eric W. Biederman
2010-04-04  9:44             ` Eric W. Biederman
2010-04-04 10:01             ` Joerg Roedel
2010-04-04 10:01               ` Joerg Roedel
2010-04-06 17:42               ` Chris Wright
2010-04-06 17:42                 ` Chris Wright
2010-04-06 17:51                 ` Joerg Roedel
2010-04-06 17:51                   ` Joerg Roedel
2010-04-06 20:39                   ` Vivek Goyal
2010-04-06 20:39                     ` Vivek Goyal
2010-04-06 21:13                     ` Vivek Goyal
2010-04-06 21:13                       ` Vivek Goyal
2010-04-06 21:45                       ` Yinghai Lu
2010-04-06 21:45                         ` Yinghai Lu
2010-04-06 22:10                         ` Eric W. Biederman
2010-04-06 22:10                           ` Eric W. Biederman
2010-04-04 11:54     ` David Woodhouse
2010-04-04 11:54       ` David Woodhouse
2010-04-03  1:27 ` [PATCH 4/4] x86/amd-iommu: use for_each_pci_dev Chris Wright
2010-04-03  1:27   ` Chris Wright
2010-04-07 10:05 ` [PATCH 0/4] AMD IOMMU kdump fix plus cleanups (v2) Joerg Roedel
2010-04-07 10:05   ` Joerg Roedel

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=20100404084435.GT24846@8bytes.org \
    --to=joro@8bytes.org \
    --cc=chrisw@sous-sol.org \
    --cc=ebiederm@xmission.com \
    --cc=hbabu@us.ibm.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=nhorman@tuxdriver.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 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.