* DMA Remapping and Marvell 88SE9172, 88SE9128 SATA controllers
@ 2012-08-27 16:05 Andrew Cooks
[not found] ` <CAJtEV7aGSvRvyevveysWkDn18Oz3n3qF6EpPtgvwC4dsJU41HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cooks @ 2012-08-27 16:05 UTC (permalink / raw)
To: linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
Cc: jgarzik-e+AXbWqSrlAAvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w
There's a problem relating to DMA Remapping which affects systems with
Marvell SATA controllers. It was first reported on 2012-01-28 on
bugzilla.kernel.org[1] and is best described by Don Dutile: "...the
lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as
the source of any of its DMA packets, the IOMMU will fault on it,
since 0b:00.1 didn't request DMA mappings (0b:00.0 did)."[2]
Is this kind of problem caused by a missing/incorrect entry in an ACPI
table? Is it feasible to introduce a fake device for the missing
function using a pci quirk?
Thanks,
ac.
1. https://bugzilla.kernel.org/show_bug.cgi?id=42679
2. https://lists.linux-foundation.org/pipermail/iommu/2012-January/003552.html
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: DMA Remapping and Marvell 88SE9172, 88SE9128 SATA controllers
[not found] ` <CAJtEV7aGSvRvyevveysWkDn18Oz3n3qF6EpPtgvwC4dsJU41HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-09-10 14:25 ` Alex Williamson
0 siblings, 0 replies; 2+ messages in thread
From: Alex Williamson @ 2012-09-10 14:25 UTC (permalink / raw)
To: Andrew Cooks
Cc: pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
jgarzik-e+AXbWqSrlAAvxtiuMwx3w, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ
On Tue, 2012-08-28 at 00:05 +0800, Andrew Cooks wrote:
> There's a problem relating to DMA Remapping which affects systems with
> Marvell SATA controllers. It was first reported on 2012-01-28 on
> bugzilla.kernel.org[1] and is best described by Don Dutile: "...the
> lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
> so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as
> the source of any of its DMA packets, the IOMMU will fault on it,
> since 0b:00.1 didn't request DMA mappings (0b:00.0 did)."[2]
>
> Is this kind of problem caused by a missing/incorrect entry in an ACPI
> table? Is it feasible to introduce a fake device for the missing
> function using a pci quirk?
We've added pci_get_dma_source() to help with such devices, but it's
only used by the IOMMU grouping code and requires a struct pci_dev for
the actual DMA source. I think for this device we're going to need to
run a quirk when we scan it that creates a fake device, add it to
pci_get_dma_source(), then make use of it in the dma mapping path. I
think the only other alternative would be to disable hardware IOMMUs
when this device is found in the system. Thanks,
Alex
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-09-10 14:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-27 16:05 DMA Remapping and Marvell 88SE9172, 88SE9128 SATA controllers Andrew Cooks
[not found] ` <CAJtEV7aGSvRvyevveysWkDn18Oz3n3qF6EpPtgvwC4dsJU41HA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-09-10 14:25 ` Alex Williamson
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).