All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	hbabu@us.ibm.com, iommu@lists.linux-foundation.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH] amd iommu: force flush of iommu prior during shutdown
Date: Thu, 1 Apr 2010 17:56:43 +0200	[thread overview]
Message-ID: <20100401155643.GG24846@8bytes.org> (raw)
In-Reply-To: <20100401144736.GA14069@shamino.rdu.redhat.com>

On Thu, Apr 01, 2010 at 10:47:36AM -0400, Neil Horman wrote:
> On Thu, Apr 01, 2010 at 04:29:02PM +0200, Joerg Roedel wrote:
> > I am back in office next tuesday and will look into this problem too.
> > 
> Thank you.

Just took a look and I think the problem is that the devices are
attached to domains before the IOMMU hardware is enabled. This happens
in the function prealloc_protection_domains(). The attach code issues
the dte-invalidate commands but they are not executed because the
hardware is off. I will verify this when I have access to hardware
again.
The possible fix will be to enable the hardware earlier in the
initialization path.

> > Right. The default for all devices is to forbid DMA.
> > 
> Thanks, glad to know I read that right, took me a bit to understand it :)

I should probably add a comment :-)

> > Thats indeed true. I have seen that with ixgbe cards for example. They
> > seem to be really confused after an target abort.
> > 
> Yeah, this part worries me, target aborts lead to various brain dead hardware
> pieces.  What are you thoughts on leaving the iommu on through a reboot to avoid
> this issue (possibly resetting any pci device that encounters a target abort, as
> noted in the error log on the iommu?

This would only prevent possible data corruption. When the IOMMU is off
the devices will not get a target abort but will only write to different
physical memory locations. The window where a target abort can happen
starts when the kdump kernel re-enables the IOMMU and ends when the new
driver for that device attaches. This is a small window but there is not
a lot we can do to avoid this small time window.

	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: Neil Horman <nhorman@tuxdriver.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	hbabu@us.ibm.com, iommu@lists.linux-foundation.org,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH] amd iommu: force flush of iommu prior during shutdown
Date: Thu, 1 Apr 2010 17:56:43 +0200	[thread overview]
Message-ID: <20100401155643.GG24846@8bytes.org> (raw)
In-Reply-To: <20100401144736.GA14069@shamino.rdu.redhat.com>

On Thu, Apr 01, 2010 at 10:47:36AM -0400, Neil Horman wrote:
> On Thu, Apr 01, 2010 at 04:29:02PM +0200, Joerg Roedel wrote:
> > I am back in office next tuesday and will look into this problem too.
> > 
> Thank you.

Just took a look and I think the problem is that the devices are
attached to domains before the IOMMU hardware is enabled. This happens
in the function prealloc_protection_domains(). The attach code issues
the dte-invalidate commands but they are not executed because the
hardware is off. I will verify this when I have access to hardware
again.
The possible fix will be to enable the hardware earlier in the
initialization path.

> > Right. The default for all devices is to forbid DMA.
> > 
> Thanks, glad to know I read that right, took me a bit to understand it :)

I should probably add a comment :-)

> > Thats indeed true. I have seen that with ixgbe cards for example. They
> > seem to be really confused after an target abort.
> > 
> Yeah, this part worries me, target aborts lead to various brain dead hardware
> pieces.  What are you thoughts on leaving the iommu on through a reboot to avoid
> this issue (possibly resetting any pci device that encounters a target abort, as
> noted in the error log on the iommu?

This would only prevent possible data corruption. When the IOMMU is off
the devices will not get a target abort but will only write to different
physical memory locations. The window where a target abort can happen
starts when the kdump kernel re-enables the IOMMU and ends when the new
driver for that device attaches. This is a small window but there is not
a lot we can do to avoid this small time window.

	Joerg


  reply	other threads:[~2010-04-01 15:56 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-31 15:24 [PATCH] amd iommu: force flush of iommu prior during shutdown Neil Horman
2010-03-31 15:24 ` Neil Horman
2010-03-31 15:54 ` Vivek Goyal
2010-03-31 15:54   ` Vivek Goyal
2010-03-31 18:28   ` Neil Horman
2010-03-31 18:28     ` Neil Horman
2010-03-31 18:57     ` Eric W. Biederman
2010-03-31 18:57       ` Eric W. Biederman
2010-03-31 19:18       ` Neil Horman
2010-03-31 19:18         ` Neil Horman
2010-03-31 19:51         ` Eric W. Biederman
2010-03-31 19:51           ` Eric W. Biederman
2010-03-31 20:27           ` Neil Horman
2010-03-31 20:27             ` Neil Horman
2010-04-01  4:04             ` Eric W. Biederman
2010-04-01  4:04               ` Eric W. Biederman
2010-04-01 12:49               ` Neil Horman
2010-04-01 12:49                 ` Neil Horman
2010-04-01 14:29             ` Joerg Roedel
2010-04-01 14:29               ` Joerg Roedel
2010-04-01 14:47               ` Neil Horman
2010-04-01 14:47                 ` Neil Horman
2010-04-01 15:56                 ` Joerg Roedel [this message]
2010-04-01 15:56                   ` Joerg Roedel
2010-04-01 17:11                   ` Neil Horman
2010-04-01 17:11                     ` Neil Horman
2010-04-01 20:14                     ` Joerg Roedel
2010-04-01 20:14                       ` Joerg Roedel
2010-04-02  0:00                       ` Neil Horman
2010-04-02  0:00                         ` Neil Horman
2010-04-02  0:30                         ` Chris Wright
2010-04-02  0:30                           ` Chris Wright
2010-04-02  1:23                           ` [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices Chris Wright
2010-04-02  1:23                             ` Chris Wright
2010-04-02  1:31                             ` [PATCH 2/2] x86/amd-iommu: warn when issuing command to uninitiailed cmd buffer Chris Wright
2010-04-02  1:31                               ` Chris Wright
2010-04-02  1:35                             ` [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices Neil Horman
2010-04-02  1:35                               ` Neil Horman
2010-04-02  1:38                               ` Chris Wright
2010-04-02  1:38                                 ` Chris Wright
2010-04-02  9:11                             ` Joerg Roedel
2010-04-02  9:11                               ` Joerg Roedel
2010-04-02 23:59                               ` Chris Wright
2010-04-02 23:59                                 ` Chris Wright
2010-04-02 15:59                             ` Vivek Goyal
2010-04-02 15:59                               ` Vivek Goyal
2010-04-02 22:38                               ` Chris Wright
2010-04-02 22:38                                 ` Chris Wright
2010-04-02 22:55                                 ` Eric W. Biederman
2010-04-02 22:55                                   ` Eric W. Biederman
2010-04-02 23:57                                   ` Chris Wright
2010-04-02 23:57                                     ` Chris Wright
2010-04-03 17:38                               ` Joerg Roedel
2010-04-03 17:38                                 ` Joerg Roedel
2010-04-05 14:17                                 ` Vivek Goyal
2010-04-05 14:17                                   ` Vivek Goyal
2010-04-05 14:32                                   ` Joerg Roedel
2010-04-05 14:32                                     ` Joerg Roedel
2010-04-05 15:34                             ` Neil Horman
2010-04-05 15:34                               ` Neil Horman
2010-03-31 18:43   ` [PATCH] amd iommu: force flush of iommu prior during shutdown Eric W. Biederman
2010-03-31 18:43     ` Eric W. Biederman
2010-03-31 21:25 ` Chris Wright
2010-03-31 21:25   ` Chris Wright
2010-04-01  1:13   ` Neil Horman
2010-04-01  1:13     ` Neil Horman
2010-04-01  1:39     ` Chris Wright
2010-04-01  1:39       ` Chris Wright
2010-04-01  2:24     ` Vivek Goyal
2010-04-01  2:24       ` Vivek Goyal
2010-04-01 12:53       ` Neil Horman
2010-04-01 12:53         ` Neil Horman
2010-04-01 15:02         ` Vivek Goyal
2010-04-01 15:02           ` Vivek Goyal
2010-04-01 15:13           ` Neil Horman
2010-04-01 15:13             ` Neil Horman
2010-04-01  2:44   ` Vivek Goyal
2010-04-01  2:44     ` Vivek Goyal
2010-04-01  7:10     ` Chris Wright
2010-04-01  7:10       ` Chris Wright
2010-04-01 12:56       ` Neil Horman
2010-04-01 12:56         ` Neil 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=20100401155643.GG24846@8bytes.org \
    --to=joro@8bytes.org \
    --cc=ebiederm@xmission.com \
    --cc=hbabu@us.ibm.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.