linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Yongji Xie <xyjxie@linux.vnet.ibm.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	iommu@lists.linux-foundation.org, alex.williamson@redhat.com,
	bhelgaas@google.com, aik@ozlabs.ru, benh@kernel.crashing.org,
	paulus@samba.org, mpe@ellerman.id.au, joro@8bytes.org,
	warrier@linux.vnet.ibm.com, zhong@linux.vnet.ibm.com,
	nikunj@linux.vnet.ibm.com, eric.auger@linaro.org,
	will.deacon@arm.com, gwshan@linux.vnet.ibm.com,
	David.Laight@ACULAB.COM, alistair@popple.id.au,
	ruscur@russell.cc
Subject: Re: [PATCH 2/5] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping
Date: Wed, 25 May 2016 22:48:49 -0500	[thread overview]
Message-ID: <20160526034849.GE3208@localhost> (raw)
In-Reply-To: <201605250554.u4P5sRqv014439@mx0a-001b2d01.pphosted.com>

On Wed, May 25, 2016 at 01:54:23PM +0800, Yongji Xie wrote:
> On 2016/5/25 5:11, Bjorn Helgaas wrote:
> >On Wed, Apr 27, 2016 at 08:43:27PM +0800, Yongji Xie wrote:
> >>The capability of IRQ remapping is abstracted on IOMMU side on
> >>some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this.
> >>
> >>To have a universal flag to test this capability for different
> >>archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
> >>when IOMMU_CAP_INTR_REMAP is set.
> >>
> >>Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com>
> >>---
> >>  drivers/iommu/iommu.c |   15 +++++++++++++++
> >>  1 file changed, 15 insertions(+)
> >>
> >>diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> >>index 0e3b009..5d2b6f6 100644
> >>--- a/drivers/iommu/iommu.c
> >>+++ b/drivers/iommu/iommu.c
> >>@@ -813,6 +813,16 @@ struct iommu_group *pci_device_group(struct device *dev)
> >>  	return group;
> >>  }
> >>+static void pci_check_msi_remapping(struct pci_dev *pdev,
> >>+					const struct iommu_ops *ops)
> >>+{
> >>+	struct pci_bus *bus = pdev->bus;
> >>+
> >>+	if (ops->capable(IOMMU_CAP_INTR_REMAP) &&
> >>+		!(bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP))
> >>+		bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
> >>+}
> >This looks an awful lot like the pci_bus_check_msi_remapping() you add
> >elsewhere.  Why do we need both?
> 
> I will modify this function as you suggested.  And we add this function
> here because some iommu drivers would be initialed after PCI probing.
>
> >>  /**
> >>   * iommu_group_get_for_dev - Find or create the IOMMU group for a device
> >>   * @dev: target device
> >>@@ -871,6 +881,9 @@ static int add_iommu_group(struct device *dev, void *data)
> >>  	const struct iommu_ops *ops = cb->ops;
> >>  	int ret;
> >>+	if (dev_is_pci(dev) && ops->capable)
> >>+		pci_check_msi_remapping(to_pci_dev(dev), ops);
> >>+
> >>  	if (!ops->add_device)
> >>  		return 0;
> >>@@ -913,6 +926,8 @@ static int iommu_bus_notifier(struct notifier_block *nb,
> >>  	 * result in ADD/DEL notifiers to group->notifier
> >>  	 */
> >>  	if (action == BUS_NOTIFY_ADD_DEVICE) {
> >>+		if (dev_is_pci(dev) && ops->capable)
> >>+			pci_check_msi_remapping(to_pci_dev(dev), ops);
> >These calls don't smell right either.  Why do we need dev_is_pci()
> >checks here?
> 
> Some platform devices may also call this.
> 
> >Can't this be done in the PCI probe path somehow, e.g.,
> >in pci_set_bus_msi_domain() or something?
> 
> Yes, this can be done in pci_create_root_bus(). But it could only
> handle the case that iommu drivers are initialed before PCI probing.

Hmm, that's sort of what I expected, but I don't like it.  I don't
think initializing IOMMU drivers after probing PCI devices is the
optimal design.  As soon as we add a PCI device, a driver can bind to
it and start using it.  If we set up an IOMMU after a driver has
claimed the device, something is going to break.  The driver may have
already made DMA mappings that would now be invalid.

IOMMU drivers are logically between the CPU and the device, so they
should be initialized before the device is enumerated.  I know there
are probably some legacy issues behind this design, and I know it has
nothing to do with your patch, so this is not a very constructive
comment.

I just want to be on record that I'm not a fan of this out-of-order
initialization, and I don't like the notification scheme for handling
device hotplug either.  Notifiers make the code hard to read, and you
can't tell what order things happen in.  It just seems like a hack to
connect things together when they should really have been designed to
be more tightly integrated from the beginning.

Bjorn

  parent reply	other threads:[~2016-05-26  3:49 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27 12:43 [PATCH 0/5] vfio-pci: Add support for mmapping MSI-X table Yongji Xie
2016-04-27 12:43 ` [PATCH 1/5] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag Yongji Xie
2016-05-24 20:55   ` Bjorn Helgaas
2016-05-25  5:46     ` Yongji Xie
2016-04-27 12:43 ` [PATCH 2/5] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping Yongji Xie
2016-05-24 21:11   ` Bjorn Helgaas
2016-05-25  5:54     ` Yongji Xie
     [not found]     ` <201605250554.u4P5sRqv014439@mx0a-001b2d01.pphosted.com>
2016-05-26  3:48       ` Bjorn Helgaas [this message]
2016-04-27 12:43 ` [PATCH 3/5] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller supports " Yongji Xie
2016-05-24 21:04   ` Bjorn Helgaas
2016-05-25  5:48     ` Yongji Xie
2016-04-27 12:43 ` [PATCH 4/5] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge Yongji Xie
2016-05-06  6:34   ` Alexey Kardashevskiy
2016-04-27 12:43 ` [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported Yongji Xie
2016-05-03  5:34   ` Tian, Kevin
2016-05-03  6:08     ` Yongji Xie
2016-05-03  6:22       ` Tian, Kevin
2016-05-03  7:34         ` Yongji Xie
2016-05-05  9:36           ` Tian, Kevin
2016-05-05  9:54             ` David Laight
2016-05-05 11:42               ` Yongji Xie
2016-05-05 12:15                 ` Tian, Kevin
2016-05-05 13:28                   ` Yongji Xie
2016-05-05 15:05                   ` Alex Williamson
2016-05-06  6:35                     ` Alexey Kardashevskiy
2016-05-06 16:54                       ` Alex Williamson
2016-05-11  6:29                     ` Tian, Kevin
2016-05-11 15:53                       ` Alex Williamson
2016-05-12  1:19                         ` Tian, Kevin
2016-05-12  2:20                           ` Alex Williamson
2016-05-12  4:53                             ` Tian, Kevin
2016-05-12 17:47                               ` Alex Williamson
2016-05-13  2:33                                 ` Tian, Kevin
2016-05-13  5:32                                   ` Alex Williamson
2016-05-13  6:50                                     ` Tian, Kevin
2016-05-13 16:42                                       ` Alex Williamson
2016-05-13  9:16                                     ` David Laight
2016-05-13  2:36                                 ` Tian, Kevin
2016-05-05 11:44             ` Yongji Xie

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=20160526034849.GE3208@localhost \
    --to=helgaas@kernel.org \
    --cc=David.Laight@ACULAB.COM \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=alistair@popple.id.au \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=eric.auger@linaro.org \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=ruscur@russell.cc \
    --cc=warrier@linux.vnet.ibm.com \
    --cc=will.deacon@arm.com \
    --cc=xyjxie@linux.vnet.ibm.com \
    --cc=zhong@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).