linux-kernel - Re: dma_map_resource() has a bad performance in pcie peer to peer transactions when iommu enabled in Linux

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] [day] [month] [year] [list]

Message-ID: <f7ee378e-6fd4-620f-abf9-2a8aa3643f94@amd.com>
Date:   Wed, 4 Oct 2023 08:26:26 +0200
From:   Christian König <christian.koenig@....com>
To:     Robin Murphy <robin.murphy@....com>,
        Kelly Devilliv <kelly.devilliv@...look.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "will@...nel.org" <will@...nel.org>
Cc:     "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: dma_map_resource() has a bad performance in pcie peer to peer
 transactions when iommu enabled in Linux

Am 02.10.23 um 22:08 schrieb Robin Murphy:
> On 2023-09-26 16:30, Kelly Devilliv wrote:
>> [SNIP]
>> Hi Robin,
>>
>> Is there any chance to extend the dma_map_resource() API as discussed 
>> above?
>
> As Christoph says, no. There are things one could do to make a 
> minimal-effort bodge in a downstream kernel, but upstream we already 
> have a dedicated PCI peer-to-peer API, so we have no reason and no 
> desire to also attempt to crowbar P2P support into a different API 
> which isn't designed for it. Sure there exist some drivers that went 
> ahead of the game and did their own thing before we realised that 
> dma_map_resource() just fundamentally wouldn't be a good fit for P2P 
> as initially suggested, but all that means is that if they're still 
> doing that today, they're now lagging behind and it's on them to 
> update to the newer solution if they want to benefit from all its 
> goodness. Note that this isn't just maintainer semantics or relatively 
> straightforward things like memory attributes; I believe the proper 
> API can also handle stuff like direct P2P when you do have an IOMMU 
> but don't have ACS upstream redirect, which dma_map_resource() could 
> never do.

The problem is that the new API requires to have struct pages for PCIe 
resources which the graphics drivers absolutely don't want to do.

Allocating struct pages for memory mapped I/O simply doesn't make to 
much sense when the underlying resource is not even memory.

Regards,
Christian.

>
> Thanks,
> Robin.