linux-kernel - Re: Marvell 88NV9143 in mini-PCIe not working with intel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 07 Mar 2013 10:25:22 +0100
From:	Gaudenz Steinlin <gaudenz@...iologie.ch>
To:	Andrew Cooks <acooks@...il.com>
Cc:	jyli@...vell.com,
	"open list\:INTEL IOMMU \(VT-d\)" <iommu@...ts.linux-foundation.org>,
	open list <linux-kernel@...r.kernel.org>,
	Shun Fu <fushun@...vell.com>,
	Alex Williamson <alex.williamson@...hat.com>
Subject: Re: Marvell 88NV9143 in mini-PCIe not working with intel_iommu=on


Hi Andrew

Andrew Cooks <acooks@...il.com> writes:

> On Tue, Mar 5, 2013 at 11:03 PM, Gaudenz Steinlin <gaudenz@...iologie.ch> wrote:
>>
>> [ Sending this to the MVUMI driver authors and the IOMMU list as I can't
>> tell which part is at fault. ]
>>
>> [ ... ]
>> [    4.342079] dmar: DRHD: handling fault status reg 2
>> [    4.342132] dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr fffff000
>> [    4.342132] DMAR:[fault reason 02] Present bit in context entry is clear
>> [ ... ]
>> [   34.344078] mvumi 0000:02:00.1: no handshake response at state 0x2.
>> [   34.344115] mvumi 0000:02:00.1: isr : global=0x0,status=0x0.
>> [   34.344146] mvumi 0000:02:00.1: handshake failed at state 0x2.
>> [   34.344266] mvumi: probe of 0000:02:00.1 failed with error -22
>>
>
> Looks like another Marvell DMA source tag issue.

You are probably right with this. See below.

>
>> And the full lspic output for this device:
>>
>> gaudenz@...eor:~$ sudo lspci -vv -nnq -s 02:
>> 02:00.0 Mass storage controller [01ff]: Marvell Technology Group Ltd. Device [1b4b:91f3]
>>         Subsystem: Marvell Technology Group Ltd. Device [1b4b:9143]
>> ...
>>         Capabilities: [140 v1] Virtual Channel
>>                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>>                 Arb:    Fixed- WRR32- WRR64- WRR128-
>>                 Ctrl:   ArbSelect=Fixed
>>                 Status: InProgress-
>>                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>>                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>>                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>>                         Status: NegoPending- InProgress-
>>
>> 02:00.1 Mass storage controller [0180]: Marvell Technology Group Ltd. Device [1b4b:9143] (rev 10)
>>         Subsystem: Marvell Technology Group Ltd. Device [1b4b:9143]
>> ...
>>         Kernel driver in use: mvumi
>>
>> 02:00.2 Non-Volatile memory controller [0108]: Marvell Technology Group Ltd. Device [1b4b:91e3] (prog-if 01)
>>         Subsystem: Marvell Technology Group Ltd. Device [1b4b:9143]
>>...
>
> In this case it seems like a multifunction device with 02:00.1 being
> the only function that the mvumi driver cares about.  So my guess is
> that 02:00.1 is issuing DMA with the incorrect tag of 02:00.0.
>
> Perhaps Alex Williamson can tell us about iommu device groups, whether
> it would be possible to group the functions together automatically and
> whether that would solve the problem. It should also be possible to
> adapt the quirk patch I posted recently to handle this, but I'm still
> waiting to hear if that patch has a future.

I adapted your quirk patch to my device and it works. As I'm very new to
this I don't know if my modifications are right or if there is a better
way to do this. Diff on top of the latest version of the quirk you
posted to the iommu list:

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 13323f2..0ba462a 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1684,7 +1684,7 @@ static int map_ghost_dma_fn(struct dmar_domain *domain,
 
        fn_map = pci_get_dma_source_map(pdev);
 
-       for (fn = 1; fn < 8; fn++) {
+       for (fn = 0; fn < 8; fn++) {
                if (fn_map & (1 << fn)) {
                        err = domain_context_mapping_one(domain,
                                        pci_domain_nr(pdev->bus),
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index d311100..21b664b 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3314,6 +3314,7 @@ static const struct pci_dev_dma_multi_func_sources {
        { 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)},
+       { PCI_VENDOR_ID_MARVELL_2, 0x9143, (1<<0)},
        { 0 }
 };

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/