From: Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Andrew Cooks <acooks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: gm.ychu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
xjtuychu-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org,
"open list:INTEL IOMMU (VT-d)"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org,
"open list:PCI SUBSYSTEM"
<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org
Subject: Re: [PATCH] Quirk to support Marvell 88SE91xx SATA controllers with Intel IOMMU.
Date: Tue, 05 Mar 2013 21:04:35 -0700 [thread overview]
Message-ID: <1362542675.22132.86.camel@bling.home> (raw)
In-Reply-To: <1362126373-32318-1-git-send-email-acooks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 2013-03-01 at 16:26 +0800, Andrew Cooks wrote:
> This is my third submitted patch to make Marvell 88SE91xx SATA controllers work when IOMMU is enabled.[1][2]
>
> What's changed:
> * Adopt David Woodhouse's terminology by referring to the quirky functions as 'ghost' functions.
> * Unmap ghost functions when device is detached from IOMMU.
> * Stub function for when CONFIG_PCI_QUIRKS is not enabled.
>
> The bad:
> * Still no AMD support.
> * The table of affected chip IDs is as complete as I can make it by googling for bug reports.
>
> This patch was generated against commit b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50, but will also apply cleanly to 3.7.10.
>
> Bug reports:
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=757166
> 2. https://bugzilla.kernel.org/show_bug.cgi?id=42679
>
> Signed-off-by: Andrew Cooks <acooks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/iommu/intel-iommu.c | 50 +++++++++++++++++++++++++++++++++++++++++++
> drivers/pci/quirks.c | 47 +++++++++++++++++++++++++++++++++++++++-
> include/linux/pci.h | 5 ++++
> include/linux/pci_ids.h | 1 +
> 4 files changed, 102 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 0099667..13323f2 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1674,6 +1674,50 @@ static int domain_context_mapping_one(struct dmar_domain *domain, int segment,
> return 0;
> }
>
> +/* For quirky devices like Marvell 88SE91xx chips that use ghost functions. */
> +static int map_ghost_dma_fn(struct dmar_domain *domain,
> + struct pci_dev *pdev,
> + int translation)
> +{
> + u8 fn, fn_map;
> + int err = 0;
> +
> + fn_map = pci_get_dma_source_map(pdev);
if (!fn_map)
return 0;
> +
> + for (fn = 1; fn < 8; fn++) {
Wouldn't you want to do 0 to 7, then add:
if (fn == PCI_FUNC(pdev->devfn))
continue;
You could also get more creative with the loop using shifts and exit
when the remaining map is 0.
> + if (fn_map & (1 << fn)) {
> + err = domain_context_mapping_one(domain,
> + pci_domain_nr(pdev->bus),
> + pdev->bus->number,
> + PCI_DEVFN(PCI_SLOT(pdev->devfn), fn),
> + translation);
> + if (err)
> + return err;
I'd be worried that there's missing cleanup here, what if you were
mapping multiple ghost functions and the 2nd one failed, leaving one
attached?
> + dev_dbg(&pdev->dev, "dma quirk; func %d mapped", fn);
> + }
> + }
> + return 0;
> +}
> +
> +static void iommu_detach_dev(struct intel_iommu *iommu, u8 bus, u8 devfn);
> +
> +static void unmap_ghost_dma_fn(struct intel_iommu *iommu,
> + struct pci_dev *pdev)
> +{
> + u8 fn, fn_map;
> +
> + fn_map = pci_get_dma_source_map(pdev);
> +
> + for (fn = 1; fn < 8; fn++) {
Same early exit and loop comments as above.
> + if (fn_map & (1 << fn)) {
> + iommu_detach_dev(iommu,
> + pdev->bus->number,
> + PCI_DEVFN(PCI_SLOT(pdev->devfn), fn));
> + dev_dbg(&pdev->dev, "dma quirk; func %d unmapped", fn);
> + }
> + }
> +}
> +
> static int
> domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev,
> int translation)
> @@ -1687,6 +1731,11 @@ domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev,
> if (ret)
> return ret;
>
> + /* quirk for undeclared/ghost pci functions */
> + ret = map_ghost_dma_fn(domain, pdev, translation);
> + if (ret)
> + return ret;
> +
> /* dependent device mapping */
> tmp = pci_find_upstream_pcie_bridge(pdev);
> if (!tmp)
> @@ -3786,6 +3835,7 @@ static void domain_remove_one_dev_info(struct dmar_domain *domain,
> iommu_disable_dev_iotlb(info);
> iommu_detach_dev(iommu, info->bus, info->devfn);
> iommu_detach_dependent_devices(iommu, pdev);
> + unmap_ghost_dma_fn(iommu, pdev);
> free_devinfo_mem(info);
>
> spin_lock_irqsave(&device_domain_lock, flags);
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 0369fb6..d311100 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3249,6 +3249,10 @@ static struct pci_dev *pci_func_0_dma_source(struct pci_dev *dev)
> return pci_get_slot(dev->bus, PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
> }
>
> +/* Table of source functions for real devices. The DMA requests for the
> + * device are tagged with a different real function as source. This is
> + * relevant to multifunction devices.
> + */
> static const struct pci_dev_dma_source {
> u16 vendor;
> u16 device;
> @@ -3275,7 +3279,8 @@ static const struct pci_dev_dma_source {
> * the device doing the DMA, but sometimes hardware is broken and will
> * tag the DMA as being sourced from a different device. This function
> * allows that translation. Note that the reference count of the
> - * returned device is incremented on all paths.
> + * returned device is incremented on all paths. Translation is done when
> + * the device is added to an IOMMU group.
> */
> struct pci_dev *pci_get_dma_source(struct pci_dev *dev)
> {
> @@ -3292,6 +3297,46 @@ struct pci_dev *pci_get_dma_source(struct pci_dev *dev)
> return pci_dev_get(dev);
> }
>
> +/* Table of multiple (ghost) source functions. This is similar to the
> + * translated sources above, but with the following differences:
> + * 1. the device may use multiple functions as DMA sources,
> + * 2. these functions cannot be assumed to be actual devices,
> + * 3. the specific ghost function for a request can not be exactly predicted.
> + * The bitmap only contains the additional quirk functions.
> + */
> +static const struct pci_dev_dma_multi_func_sources {
> + u16 vendor;
> + u16 device;
> + u8 func_map; /* bit map. lsb is fn 0. */
> +} pci_dev_dma_multi_func_sources[] = {
> + { PCI_VENDOR_ID_MARVELL_2, 0x9123, (1<<0)|(1<<1)},
> + { PCI_VENDOR_ID_MARVELL_2, 0x9125, (1<<0)|(1<<1)},
> + { PCI_VENDOR_ID_MARVELL_2, 0x9128, (1<<0)|(1<<1)},
> + { PCI_VENDOR_ID_MARVELL_2, 0x9130, (1<<0)|(1<<1)},
> + { PCI_VENDOR_ID_MARVELL_2, 0x9172, (1<<0)|(1<<1)},
Links to bug reports in the comments might be useful for future
workarounds. I'm also not sure what you mean in the 3rd bullet, the
non-ghost function of some of these is sometimes 0, sometimes 1? And
the ghost function is the other? Skipping fn 0 above, I assume all
cases are fn 0 exists and fn 1 is the ghost function, right? If so,
then we probably only want bit 1 set. I'm afraid to ask whether there
are configurations of this vendor/device that have a fn 1. Thanks,
Alex
> + { 0 }
> +};
> +
> +/*
> + * The mapping of fake/ghost functions is used when the real device is
> + * attached to an IOMMU domain. IOMMU groups are not aware of these
> + * functions, because they're not real devices.
> + */
> +u8 pci_get_dma_source_map(struct pci_dev *dev)
> +{
> + const struct pci_dev_dma_multi_func_sources *i;
> +
> + for (i = pci_dev_dma_multi_func_sources; i->func_map; i++) {
> + if ((i->vendor == dev->vendor ||
> + i->vendor == (u16)PCI_ANY_ID) &&
> + (i->device == dev->device ||
> + i->device == (u16)PCI_ANY_ID)) {
> + return i->func_map;
> + }
> + }
> + return 0;
> +}
> +
> static const struct pci_dev_acs_enabled {
> u16 vendor;
> u16 device;
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2461033..5ad3822 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1578,6 +1578,7 @@ enum pci_fixup_pass {
> #ifdef CONFIG_PCI_QUIRKS
> void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
> struct pci_dev *pci_get_dma_source(struct pci_dev *dev);
> +u8 pci_get_dma_source_map(struct pci_dev *dev);
> int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
> #else
> static inline void pci_fixup_device(enum pci_fixup_pass pass,
> @@ -1586,6 +1587,10 @@ static inline struct pci_dev *pci_get_dma_source(struct pci_dev *dev)
> {
> return pci_dev_get(dev);
> }
> +u8 pci_get_dma_source_map(struct pci_dev *dev)
> +{
> + return 0;
> +}
> static inline int pci_dev_specific_acs_enabled(struct pci_dev *dev,
> u16 acs_flags)
> {
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index f11c1c2..df57496 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -1604,6 +1604,7 @@
> #define PCI_SUBDEVICE_ID_KEYSPAN_SX2 0x5334
>
> #define PCI_VENDOR_ID_MARVELL 0x11ab
> +#define PCI_VENDOR_ID_MARVELL_2 0x1b4b
> #define PCI_DEVICE_ID_MARVELL_GT64111 0x4146
> #define PCI_DEVICE_ID_MARVELL_GT64260 0x6430
> #define PCI_DEVICE_ID_MARVELL_MV64360 0x6460
next prev parent reply other threads:[~2013-03-06 4:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1354533387-4110-1-git-send-email-acooks@gmail.com>
[not found] ` <1354533387-4110-1-git-send-email-acooks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-03 11:16 ` [PATCH 4/4] create context mapping entries for devices that use phantom functions Andrew Cooks
2012-12-19 10:58 ` [RFC PATCH] Fix Intel IOMMU support for Marvell 88SE91xx SATA controllers Andrew Cooks
2012-12-19 13:41 ` Chu Ying
[not found] ` <A1185FFE-6B90-4B44-BF8C-082E487AA73D-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-19 15:07 ` Andrew Cooks
[not found] ` <CAJtEV7ZmgkJMhFL_2Qzt1YsKnZ40gNi0yHgixVW3yJEfi4QzfA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-20 2:55 ` Ying Chu
[not found] ` <1355914703-28576-1-git-send-email-acooks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-02-22 19:29 ` Stijn Tintel
[not found] ` <5127C716.6050903-VfPWfsRibaPZj6PxcwrBaQ@public.gmane.org>
2013-02-25 8:37 ` Andrew Cooks
2013-03-01 8:26 ` [PATCH] Quirk to support Marvell 88SE91xx SATA controllers with Intel IOMMU Andrew Cooks
[not found] ` <1362126373-32318-1-git-send-email-acooks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-03-01 17:51 ` Justin Piszcz
2013-03-01 22:19 ` Andrew Cooks
[not found] ` <CAJtEV7Zs2BiwJ9jdDeoceh9hiVXvVaSvj=9H+4+vEzhY72AS9g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 23:18 ` Justin Piszcz
2013-03-04 1:35 ` Andrew Cooks
[not found] ` <CAJtEV7bvPORPoXgQY2OahNVMj+SY5z=xxQ=nueX7=kLVfpyF_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-04 11:32 ` Justin Piszcz
2013-03-29 14:36 ` Justin Piszcz
2013-03-06 4:04 ` Alex Williamson [this message]
[not found] ` <1362542675.22132.86.camel-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-03-06 6:59 ` Andrew Cooks
2013-03-01 17:54 ` Justin Piszcz
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=1362542675.22132.86.camel@bling.home \
--to=alex.williamson-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=acooks-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=gm.ychu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jpiszcz-BP4nVm5VUdNhbmWW9KSYcQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=xjtuychu-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.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).