From: Benjamin Herrenschmidt <benh@au1.ibm.com>
To: Robin Murphy <robin.murphy@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"open list:INTEL IOMMU (VT-d)" <iommu@lists.linux-foundation.org>,
Yongji Xie <elohimes@gmail.com>,
Yongji Xie <xyjxie@linux.vnet.ibm.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH kernel v4 4/6] iommu: Set PCI_BUS_FLAGS_MSI_REMAP on iommu driver initialization
Date: Wed, 19 Jul 2017 15:12:54 +1000 [thread overview]
Message-ID: <1500441174.3350.19.camel@au1.ibm.com> (raw)
In-Reply-To: <2391df16-2095-315b-e091-3e3eb69bb668@arm.com>
On Tue, 2017-07-11 at 11:39 +0100, Robin Murphy wrote:
> I have no idea what the context is here, but this flag looks wrong
> generally. IRQ remapping is a property of the irqchip and has nothing to
> do with PCI, so pretending it's a property of PCI buses looks like a
> massive hack around... something.
>
> Also, iommu_capable() is a fundamentally broken and unworkable interface
> anyway. The existing IRQ remapping code really wants updating to
> advertise IRQ_DOMAIN_FLAG_MSI_REMAP on the relevant MSI domains so that
> IOMMU_CAP_INTR_REMAP can go away for good. That way, all consumers who
> actually care about whether IRQ remapping is implemented (see e.g. VFIO)
> can use irq_domain_check_msi_remap() or check specific devices in a sane
> and scalable manner.
As you rightfully said, you have no idea what the context is :-)
This is not an interrupt domain.
On powerpc we have a single global unified domains that contains all
our MSIs, IPIs, internally interrupts and what not, because of the way
our interrupts infrastructure works.
So there is no such thing as "a property of the MSI domain".
The way the HW works is that the PCI Host Bridge has the ability
to filter which device can access which MSIs. This is done by the IOMMU
portion of the bridge.
Thus it's a filtering capability, not a remapping capability per-se,
and it's a property of the IOMMU domain.
Sicne this is also a paravitualized interface, the "remapping" part
is handled by the HV calls done by the guest to configure the MSIs.
The HW filtering ensures that an evil guest cannot do bad things if
it goes manually whack the MSI table.
Now this issue have been discussed and patches floated around for
*YEARS* now and there is still no upstream solution for what is a
completely trivial problem: Don't bloody bloock MSI BAR table access on
pseries platforms. It kills performance on a number of device due to
our 64K pages.
A 1-liner fix in qemu would have done it YEARS ago. But instead we have
now painted about 1000 bike sheds and going without anything that
actually works. Yay.
Ben.
next prev parent reply other threads:[~2017-07-19 5:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 5:24 [PATCH kernel v4 0/6] vfio-pci: Add support for mmapping MSI-X table Alexey Kardashevskiy
2017-06-30 5:24 ` [PATCH kernel v4 1/6] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag Alexey Kardashevskiy
2017-07-10 19:20 ` Bjorn Helgaas
2017-07-11 8:36 ` Alexey Kardashevskiy
2017-06-30 5:24 ` [PATCH kernel v4 2/6] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller enables IRQ remapping Alexey Kardashevskiy
2017-06-30 5:24 ` [PATCH kernel v4 3/6] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of " Alexey Kardashevskiy
2017-07-01 10:27 ` kbuild test robot
2017-06-30 5:24 ` [PATCH kernel v4 4/6] iommu: Set PCI_BUS_FLAGS_MSI_REMAP on iommu driver initialization Alexey Kardashevskiy
[not found] ` <20170630052436.15212-5-aik-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org>
2017-07-10 19:23 ` Bjorn Helgaas via iommu
[not found] ` <CAErSpo4pAZfDx5p_S9Z8jR_ctH=ZrkgG6aNaNmPaN2H77dgEgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-11 10:39 ` Robin Murphy
2017-07-12 2:47 ` Alexey Kardashevskiy
2017-07-19 5:12 ` Benjamin Herrenschmidt [this message]
2017-07-19 10:02 ` Alexey Kardashevskiy
2017-07-25 6:09 ` Alexey Kardashevskiy
[not found] ` <b444851a-3240-f98f-04b9-0223649ea856-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org>
2017-07-26 9:50 ` Joerg Roedel
[not found] ` <20170726095053.GG15833-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-07-26 11:33 ` Benjamin Herrenschmidt
2017-07-12 7:04 ` Jike Song
2017-07-12 7:28 ` Alexey Kardashevskiy
2017-06-30 5:24 ` [PATCH kernel v4 5/6] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge Alexey Kardashevskiy
2017-06-30 5:24 ` [PATCH kernel v4 6/6] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled Alexey Kardashevskiy
2017-07-10 2:20 ` [PATCH kernel v4 0/6] vfio-pci: Add support for mmapping MSI-X table Alexey Kardashevskiy
2017-07-10 19:11 ` Bjorn Helgaas
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=1500441174.3350.19.camel@au1.ibm.com \
--to=benh@au1.ibm.com \
--cc=aik@ozlabs.ru \
--cc=bhelgaas@google.com \
--cc=david@gibson.dropbear.id.au \
--cc=elohimes@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=xyjxie@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