linux-kernel - Re: [RFC PATCH] xen/gntdev: Stop abusing DT of_dma

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1ae7f42e-bf93-b335-b543-653fae5cf49f@epam.com>
Date:   Thu, 26 Sep 2019 10:17:13 +0000
From:   Oleksandr Andrushchenko <Oleksandr_Andrushchenko@...m.com>
To:     Julien Grall <julien.grall@....com>, Rob Herring <robh@...nel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Robin Murphy <robin.murphy@....com>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        Oleksandr Andrushchenko <andr2000@...il.com>
Subject: Re: [RFC PATCH] xen/gntdev: Stop abusing DT of_dma_configure API


On 9/26/19 12:49 PM, Julien Grall wrote:
> Hi Rob,
>
>
> On 9/25/19 10:50 PM, Rob Herring wrote:
>> As the comment says, this isn't a DT based device. of_dma_configure()
>> is going to stop allowing a NULL DT node, so this needs to be fixed.
>
> And this can't work on arch not selecting CONFIG_OF and can select 
> CONFIG_XEN_GRANT_DMA_ALLOC.
>
> We are lucky enough on x86 because, AFAICT, arch_setup_dma_ops is just 
> a nop.
>
No luck is needed as [1] does nothing for those platforms not using 
CONFIG_OF
>>
>> Not sure exactly what setup besides arch_setup_dma_ops is needed...
>
> We probably want to update dma_mask, coherent_dma_mask and 
> dma_pfn_offset.
>
> Also, while look at of_configure_dma, I noticed that we consider the 
> DMA will not be coherent for the grant-table. Oleksandr, do you know 
> why they can't be coherent?
The main and the only reason to use of_configure_dma is that if we don't 
then we
are about to stay with dma_dummy_ops [2]. It effectively means that 
operations on dma-bufs
will end up returning errors, like [3], [4], thus not making it possible 
for Xen PV DRM and DMA
part of gntdev driver to do what we need (dma-bufs in our use-cases 
allow zero-copying
while using graphics buffers and many more).

I didn't find any better way of achieving that, but of_configure_dma...
If there is any better solution which will not break the existing 
functionality then
I will definitely change the drivers so we do not abuse DT )
Before that, please keep in mind that merging this RFC will break Xen PV 
DRM +
DMA buf support in gntdev...
Hope we can work out some acceptable solution, so everyone is happy
>
> Cheers,
>

Thank you,
Oleksandr

[1] 
https://elixir.bootlin.com/linux/v5.3.1/source/include/linux/of_device.h#L109
[2] https://elixir.bootlin.com/linux/v5.3.1/source/kernel/dma/dummy.c#L33
[3] https://elixir.bootlin.com/linux/v5.3.1/source/kernel/dma/dummy.c#L11
[4] https://elixir.bootlin.com/linux/v5.3.1/source/kernel/dma/dummy.c#L18