linux-kernel - Re: [PATCH] drm/xen-front: Make shmem backed display buffer coherent

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: <83a4be07-a06f-5585-66f6-4973f80dbfba@gmail.com>
Date:   Fri, 21 Dec 2018 11:16:44 +0200
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Christoph Hellwig <hch@...radead.org>,
        Daniel Vetter <daniel@...ll.ch>
Cc:     Juergen Gross <jgross@...e.com>,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        xen-devel@...ts.xenproject.org, boris.ostrovsky@...cle.com
Subject: Re: [PATCH] drm/xen-front: Make shmem backed display buffer coherent

On 12/20/18 8:38 PM, Christoph Hellwig wrote:
> On Thu, Dec 20, 2018 at 07:35:15PM +0100, Daniel Vetter wrote:
>>> Err, with streaming DMA buffer sharing is trivial.  The coherent DMA
>>> allocator is what causes all kinds of horrible hacks that can't actually
>>> work on various platforms.
>> Hm, I thought the streaming dma api is the one that causes bounce
>> buffers and all that fun. If you're unlucky at least.
> Yes it may.  But even if that happens everything will actually work,
> just slower.  While the dma coherent API is simply broken.
>
> But if you don't want bounce buffering you need to use the dma
> noncoherent allocator as proposed here:
>
> 	https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031982.html
>
> which combines allocating memory that doesn't need to be bounce
> buffered with a sharing scheme that can actually work.
So, the bottom line will be: I can use DMA API for what I need, but:
1. I need to remove GFP_USER
2. No need for DMA32 (so no chance for bouncing to step in)
3. I may need to check if mapping and unmapping of the buffer
at once will also help, e.g. no need to have the buffer mapped until
it is destroyed
Did I get it all right?

Thank you,
Oleksandr