linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Takao Indoh <indou.takao@jp.fujitsu.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"open list:INTEL IOMMU (VT-d)" <iommu@lists.linux-foundation.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"ishii.hironobu@jp.fujitsu.com" <ishii.hironobu@jp.fujitsu.com>,
	Don Dutile <ddutile@redhat.com>,
	"Sumner, William" <bill.sumner@hp.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	Haren Myneni <hbabu@us.ibm.com>
Subject: Re: [PATCH v2] PCI: Reset PCIe devices to stop ongoing DMA
Date: Wed, 31 Jul 2013 15:56:23 -0400	[thread overview]
Message-ID: <20130731195622.GC1577@redhat.com> (raw)
In-Reply-To: <CAErSpo7TNhQO0dx_xZvF=dU2fSWTFf8x=xUJcEsbadJkv8ktuQ@mail.gmail.com>

On Tue, Jul 30, 2013 at 09:59:16AM -0600, Bjorn Helgaas wrote:
> On Tue, Jul 30, 2013 at 12:09 AM, Takao Indoh
> <indou.takao@jp.fujitsu.com> wrote:
> > (2013/07/29 23:17), Bjorn Helgaas wrote:
> >> On Sun, Jul 28, 2013 at 6:37 PM, Takao Indoh <indou.takao@jp.fujitsu.com> wrote:
> >>> (2013/07/26 2:00), Bjorn Helgaas wrote:
> 
> >>>> My point about IOMMU and PCI initialization order doesn't go away just
> >>>> because it doesn't fit "kdump policy."  Having system initialization
> >>>> occur in a logical order is far more important than making kdump work.
> >>>
> >>> My next plan is as follows. I think this is matched to logical order
> >>> on boot.
> >>>
> >>> drivers/pci/pci.c
> >>> - Add function to reset bus, for example, pci_reset_bus(struct pci_bus *bus)
> >>>
> >>> drivers/iommu/intel-iommu.c
> >>> - On initialization, if IOMMU is already enabled, call this bus reset
> >>>    function before disabling and re-enabling IOMMU.
> >>
> >> I raised this issue because of arches like sparc that enumerate the
> >> IOMMU before the PCI devices that use it.  In that situation, I think
> >> you're proposing this:
> >>
> >>    panic kernel
> >>      enable IOMMU
> >>      panic
> >>    kdump kernel
> >>      initialize IOMMU (already enabled)
> >>        pci_reset_bus
> >>        disable IOMMU
> >>        enable IOMMU
> >>      enumerate PCI devices
> >>
> >> But the problem is that when you call pci_reset_bus(), you haven't
> >> enumerated the PCI devices, so you don't know what to reset.
> >
> > Right, so my idea is adding reset code into "intel-iommu.c". intel-iommu
> > initialization is based on the assumption that enumeration of PCI devices
> > is already done. We can find target device from IOMMU page table instead
> > of scanning all devices in pci tree.
> >
> > Therefore, this idea is only for intel-iommu. Other architectures need
> > to implement their own reset code.
> 
> That's my point.  I'm opposed to adding code to PCI when it only
> benefits x86 and we know other arches will need a fundamentally
> different design.  I would rather have a design that can work for all
> arches.

I agree. It makes sense to work on a design which works for all
arches.

And that's when I feel that handling this problem at IOMMU level
makes more sense, if we can.

Thanks
Vivek

  parent reply	other threads:[~2013-07-31 19:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-14  5:29 [PATCH v2] PCI: Reset PCIe devices to stop ongoing DMA Takao Indoh
2013-05-14 22:04 ` Eric W. Biederman
2013-05-21 23:46   ` Takao Indoh
2013-06-06  7:25 ` Takao Indoh
2013-06-07  4:14 ` Bjorn Helgaas
2013-06-07  8:46   ` Takao Indoh
2013-06-11  2:20     ` Bjorn Helgaas
2013-06-11  6:08       ` Takao Indoh
2013-06-11 23:19         ` Sumner, William
2013-06-12  0:53           ` Bjorn Helgaas
2013-06-12 13:19           ` Don Dutile
2013-06-13  3:25             ` Takao Indoh
2013-06-12  4:45         ` Bjorn Helgaas
2013-06-13  2:44           ` Takao Indoh
2013-06-13  3:41             ` Bjorn Helgaas
2013-06-14  2:11               ` Takao Indoh
2013-07-24  6:29                 ` Takao Indoh
2013-07-25 14:24                   ` Vivek Goyal
2013-07-29  0:20                     ` Takao Indoh
2013-07-25 17:00                   ` Bjorn Helgaas
2013-07-29  0:37                     ` Takao Indoh
2013-07-29 14:17                       ` Bjorn Helgaas
2013-07-30  6:09                         ` Takao Indoh
2013-07-30 15:59                           ` Bjorn Helgaas
2013-07-31  0:35                             ` Takao Indoh
2013-07-31  3:11                               ` Alex Williamson
2013-07-31  5:50                                 ` Takao Indoh
2013-07-31 21:08                               ` Bjorn Helgaas
2013-07-31 21:23                                 ` Rafael J. Wysocki
2013-08-01  6:34                                   ` Takao Indoh
2013-08-01 12:42                                     ` Alex Williamson
2013-08-01 13:20                                     ` Vivek Goyal
2013-07-31 19:56                             ` Vivek Goyal [this message]
2013-07-31 16:09                     ` 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=20130731195622.GC1577@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=bill.sumner@hp.com \
    --cc=ddutile@redhat.com \
    --cc=hbabu@us.ibm.com \
    --cc=indou.takao@jp.fujitsu.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=ishii.hironobu@jp.fujitsu.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).