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:   Mon, 7 Jun 2021 14:41:14 +0800
From:   Guo Ren <guoren@...nel.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Nick Kossifidis <mick@....forth.gr>,
        Drew Fustini <drew@...gleboard.org>,
        Anup Patel <anup.patel@....com>,
        Palmer Dabbelt <palmerdabbelt@...gle.com>, wefu@...hat.com,
        Wei Wu (吴伟) <lazyparser@...il.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-sunxi@...ts.linux.dev, Guo Ren <guoren@...ux.alibaba.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Benjamin Koch <snowball@...b.de>,
        Matteo Croce <mcroce@...ux.microsoft.com>,
        Wei Fu <tekkamanninja@...il.com>
Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support

On Mon, Jun 7, 2021 at 2:27 PM Christoph Hellwig <hch@....de> wrote:
>
> On Mon, Jun 07, 2021 at 11:19:03AM +0800, Guo Ren wrote:
> > >From Linux non-coherency view, we need:
> >  - Non-cache + Strong Order PTE attributes to deal with drivers' DMA descriptors
> >  - Non-cache + weak order to deal with framebuffer drivers
> >  - CMO dma_sync to sync cache with DMA devices
>
> This is not strictly true.  At the very minimum you only need cache
> invalidation and writeback instructions.  For example early parisc
> CPUs and some m68knommu SOCs have no support for uncached areas at all,
> and Linux works.  But to be fair this is very painful and supports only
> very limited periphals.  So for modern full Linux support some uncahed
> memory is advisable.  But that doesn't have to be using PTE attributes.
> It could also be physical memory regions that are either totally fixed
Double/Triple the size of physical memory regions can't be accepted by
SOC vendors, because it wastes HW resources.
Some cost-down soc interconnects only have 32bit~34bit width of
physical address, are you sure you could force them to expand it? (I
can't)

> or somewhat dynamic.
How can HW implement with dynamic modifying PMA? What's the granularity?



-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ