linux-kernel - Re: [PATCH 04/13] x86: use generic swiotlb

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]

Message-ID: <20180312082633.GA5724@lst.de>
Date:   Mon, 12 Mar 2018 09:26:33 +0100
From:   Christoph Hellwig <hch@....de>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Christoph Hellwig <hch@....de>, x86@...nel.org,
        Tom Lendacky <thomas.lendacky@....com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        linux-kernel@...r.kernel.org, Muli Ben-Yehuda <mulix@...ix.org>,
        iommu@...ts.linux-foundation.org,
        David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 04/13] x86: use generic swiotlb_ops

On Thu, Mar 08, 2018 at 04:03:12PM +0000, Robin Murphy wrote:
>> Also fix the sta2x11 case.  For that SOC the dma map ops need an
>> additional physical to dma address translations.  For swiotlb buffers
>> that is done throught the phys_to_dma helper, but the sta2x11_dma_ops
>> also added an additional translation on the return value from
>> x86_swiotlb_alloc_coherent, which is only correct if that functions
>> returns a direct allocation and not a swiotlb buffer.  With the
>> generic swiotlb and dma-direct code phys_to_dma is not always used
>> and the separate sta2x11_dma_ops can be replaced with a simple
>> bit that marks if the additional physical to dma address translation
>> is needed.
>
> FWIW, last time I looked I got the impression that STA2x11 could just use 
> dma_pfn_offset - the comments and a2p/p2a logic in sta2x11-fixup.c 
> certainly imply that the underlying hardware situation is pretty much 
> exactly that for which dma_pfn_offset exists.

That probably is the case.  But without access to the hardware I don't
feel like doing this deeper surgery.  And even without that this case
provides a great simplification.