From: Alex Williamson <alex.williamson@redhat.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org,
acooks@gmail.com, linux-kernel@vger.kernel.org,
eddy0596@gmail.com, linux@horizon.com
Subject: Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems
Date: Wed, 28 May 2014 14:45:23 -0600 [thread overview]
Message-ID: <1401309923.2412.71.camel@ul30vt.home> (raw)
In-Reply-To: <20140528202922.GT11907@google.com>
On Wed, 2014-05-28 at 14:29 -0600, Bjorn Helgaas wrote:
> On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote:
> > For testing, this version can be found in my git tree:
> >
> > git://github.com/awilliam/linux-vfio.git dma-alias-v4
> >
> > Please report any issues.
> >
> > v4:
> > - Change dma_func_alias to dma_alias_devfn, holding a single
> > devfn to alias, thereby supporting aliases to the wrong slot.
> > The DMA alias iterator is easily changed, but IOMMU grouping
> > requires significant rework. This is now done in IOMMU code
> > rather than PCI code.
> >
> > - AMD-Vi - try to incorporate IVRS aliases dynamically into
> > PCI alias quirks to make sure that our grouping remains the
> > same. Potentially this could end up reporting BIOS aliases
> > that we can add to our list of quirks.
> >
> > v3:
> > - Found several instances where I had PCI_SLOT when I meant
> > PCI_FUNC. Thanks to Andrew for spotting this. This should
> > fix the problem he was having with Ricoh quirks. We also
> > pruned down the func0 quirks to only those that we know are
> > needed. We can always add them back later.
> >
> > - Found a case in intel-iommu of using dev_is_pci() where I
> > really wanted !dev_is_pci(). Fixed.
> >
> > v2:
> > - Several new Marvell controllers added to quirks. There's been
> > a lot of success reported with this series in
> > https://bugzilla.kernel.org/show_bug.cgi?id=42679
> >
> > - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do
> > not expose a PCIe capability. These have been shown to use
> > the standard PCIe-to-PCI bridge requester ID.
> >
> > - Fix copy/paste duplicate Ricoh quirk ID
> >
> > - Fixed AMD IOMMU for the "ghost" function case where the DMA
> > alias is for an absent device. The iommu rlookup table and
> > data fields need to be initializes.
> >
> > - Fixed Intel interrupt remapping, I wasn't passing the target
> > bus number, only the alias bus number.
> >
> > These patches are split across PCI and IOMMU, but I've front-loaded
> > all of the PCI infrastructure so that the first 7 patches can be
> > applied to PCI-core, the IOMMU maintainers can pickup their patches,
> > then we can finish with dead code removal. Bjorn might also be
> > willing to carry the IOMMU changes if the maintainers want to ack
> > them.
>
> I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest,
> too, given acks from Joerg and David. Or if they prefer to take them all,
> which might be easier than coordinating two trees, especially since there's
> PCI stuff at the beginning and end, here's my ack for the PCI bits (patches
> 1-7 and 15-16):
>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Awesome, thanks!
> If you want to send me updated changelogs for patches 5 & 6, I'll drop
> those in.
Yep, I'll send changelog updates for 5 & 6 in a few minutes.
> Didn't you have more testing reports? I see George's, but I thought there
> were some others, too.
I also see:
https://lkml.org/lkml/2014/5/28/24
Tested-by: Pat Erley <pat-lkml@erley.org>
There are several reports of success in the bzs, but I don't see any
official tested-by tags there. Thanks,
Alex
> > Original description:
> >
> > This series attempts to fix a couple issues we've had outstanding in
> > the PCI/IOMMU code for a while. The first issue is with devices that
> > use the wrong requester ID for DMA transactions. We already have a
> > sort of half-baked attempt to fix this for several Ricoh devices, but
> > the fix only helps them be useful through IOMMU groups, not the
> > general DMA case. There are also several Marvell devices which use
> > use a different wrong requester ID and don't even fit into the DMA
> > source idea. This series creates a DMA alias iterator that will
> > step through each possible alias of a device, allowing IOMMUs to
> > insert mappings for both the device and its aliases.
> >
> > Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge()
> > function, which is known to blowup when it finds itself suddenly at
> > a PCIe device without crossing a PCIe-to-PCI bridge (as identified by
> > the PCIe capability). It also likes to make the invalid assumption
> > that a PCIe device never has its requester ID masked by any usptream
> > bus. We can fix this using the above new DMA alias iterator, since
> > that's effectively what this function was meant to do.
> >
> > Finally, with all these helpers, it makes sense to consolidate code
> > for determining IOMMU groups. The first step in finding the root
> > of a group is finding the final upstream DMA alias for the device,
> > then applying additional ACS rules and incorporating device specific
> > aliases. As this is all common to PCI, create a single implementation
> > and remove piles of code from the individual IOMMU drivers.
> >
> > This series allows devices like the Marvell 88SE9123 to finally work
> > on Linux with either AMD-Vi or VT-d enabled on the box. I've
> > collected device IDs from various bugs to support as many SKUs of
> > these devices as possible, but I'm sure there are others that I've
> > missed.
> >
> > This should also enable motherboards with an onboard ASmedia
> > ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled. I've
> > acquired an adapter board with this chip, but it actually exposes
> > a PCIe capability, unlike most of the onboard controllers. Therefore
> > I expect this series will fix the WARN_ON currently hit during boot,
> > but there's a 50/50 chance whether the device behaves like a PCI
> > bridge or a PCIe bridge with regard to the requester ID that it uses
> > to take ownership of the transaction. If it turns out to use the
> > PCIe bridge model, I expect we can quirk it using a dev_flags bit
> > to identify a PCI bridge that takes ownership as if it was a PCIe
> > bridge.
> >
> > Please test and provide feedback. I expect IOMMU group topology
> > should not change from this series, but if a case is found where it
> > does, please share. Also, if there are additional quirks we need
> > to add, please either file new or add to the existing bugs. Thanks,
> >
> > Alex
> >
> > ---
> >
> > Alex Williamson (16):
> > PCI: Add DMA alias iterator
> > PCI: define pci_dev_flags as bit shifts
> > PCI: quirk pci_for_each_dma_alias()
> > PCI: quirk dma_alias_devfn for Ricoh devices
> > PCI: quirk dma_alias_devfn for Marvell devices
> > PCI: Quirk pci_for_each_dma_alias() for bridges
> > PCI: Add quirks for ASMedia and Tundra bridges
> > iommu: Create central IOMMU group lookup/creation interface
> > iommu/amd: Update to use PCI DMA aliases
> > iommu/amd: Use iommu_group_get_for_dev()
> > iommu/intel: Use iommu_group_get_for_dev()
> > iommu/intel: Update to use PCI DMA aliases
> > iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups
> > iommu: Remove pci.h
> > PCI: Remove pci_find_upstream_pcie_bridge()
> > PCI: Remove pci_get_dma_source()
> >
> >
> > drivers/iommu/amd_iommu.c | 214 +++++++-----------------
> > drivers/iommu/amd_iommu_types.h | 1
> > drivers/iommu/fsl_pamu_domain.c | 66 --------
> > drivers/iommu/intel-iommu.c | 307 +++++++++++++----------------------
> > drivers/iommu/intel_irq_remapping.c | 55 ++++--
> > drivers/iommu/iommu.c | 181 +++++++++++++++++++++
> > drivers/iommu/pci.h | 29 ---
> > drivers/pci/quirks.c | 116 ++++++++-----
> > drivers/pci/search.c | 104 +++++++++---
> > include/linux/iommu.h | 1
> > include/linux/pci.h | 31 +---
> > 11 files changed, 557 insertions(+), 548 deletions(-)
> > delete mode 100644 drivers/iommu/pci.h
next prev parent reply other threads:[~2014-05-28 20:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 23:07 Alex Williamson
2014-05-22 23:07 ` [PATCH v4 01/16] PCI: Add DMA alias iterator Alex Williamson
2014-05-22 23:07 ` [PATCH v4 02/16] PCI: define pci_dev_flags as bit shifts Alex Williamson
2014-05-22 23:07 ` [PATCH v4 03/16] PCI: quirk pci_for_each_dma_alias() Alex Williamson
2014-05-22 23:07 ` [PATCH v4 04/16] PCI: quirk dma_alias_devfn for Ricoh devices Alex Williamson
2014-05-22 23:07 ` [PATCH v4 05/16] PCI: quirk dma_alias_devfn for Marvell devices Alex Williamson
2014-05-23 1:29 ` George Spelvin
2014-05-28 17:55 ` Bjorn Helgaas
2014-05-28 18:04 ` Alex Williamson
2014-05-28 20:54 ` [PATCH v4.1 " Alex Williamson
2014-05-22 23:08 ` [PATCH v4 06/16] PCI: Quirk pci_for_each_dma_alias() for bridges Alex Williamson
2014-05-28 18:00 ` Bjorn Helgaas
2014-05-28 19:09 ` Alex Williamson
2014-05-28 20:57 ` [PATCH v4.1 " Alex Williamson
2014-05-22 23:08 ` [PATCH v4 07/16] PCI: Add quirks for ASMedia and Tundra bridges Alex Williamson
2014-05-22 23:08 ` [PATCH v4 08/16] iommu: Create central IOMMU group lookup/creation interface Alex Williamson
2014-05-22 23:08 ` [PATCH v4 09/16] iommu/amd: Update to use PCI DMA aliases Alex Williamson
2014-05-22 23:08 ` [PATCH v4 10/16] iommu/amd: Use iommu_group_get_for_dev() Alex Williamson
2014-05-22 23:08 ` [PATCH v4 11/16] iommu/intel: " Alex Williamson
2014-05-22 23:08 ` [PATCH v4 12/16] iommu/intel: Update to use PCI DMA aliases Alex Williamson
2014-05-22 23:08 ` [PATCH v4 13/16] iommu/fsl: Use iommu_group_get_for_dev() for IOMMU groups Alex Williamson
2014-05-30 9:17 ` Varun Sethi
2014-05-22 23:08 ` [PATCH v4 14/16] iommu: Remove pci.h Alex Williamson
2014-05-22 23:08 ` [PATCH v4 15/16] PCI: Remove pci_find_upstream_pcie_bridge() Alex Williamson
2014-05-22 23:09 ` [PATCH v4 16/16] PCI: Remove pci_get_dma_source() Alex Williamson
2014-05-28 5:23 ` [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems Pat Erley
2014-05-28 20:29 ` Bjorn Helgaas
2014-05-28 20:45 ` Alex Williamson [this message]
2014-05-30 5:30 ` Andrew Cooks
2014-06-09 18:01 ` Alex Williamson
2014-06-16 14:47 ` Joerg Roedel
2014-06-16 15:34 ` Alex Williamson
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=1401309923.2412.71.camel@ul30vt.home \
--to=alex.williamson@redhat.com \
--cc=acooks@gmail.com \
--cc=bhelgaas@google.com \
--cc=eddy0596@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@horizon.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
all inboxes | Powered by JetHome®