linux-kernel - Re: [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions

Open Source and information security mailing list archives

Message-ID: <CAOnJCU+j33gaq4rDsXnDotTRnfCxsR81V4aHayNjbg7=DsB3Fw@mail.gmail.com>
Date:   Wed, 15 Sep 2021 21:42:27 -0700
From:   Atish Patra <atishp@...shpatra.org>
To:     Anup Patel <anup@...infault.org>
Cc:     Guo Ren <guoren@...nel.org>, Christoph Hellwig <hch@....de>,
        Anup Patel <anup.patel@....com>,
        Atish Patra <atish.patra@....com>,
        Palmer Dabbelt <palmerdabbelt@...gle.com>,
        Christoph Müllner <christoph.muellner@...ll.eu>,
        Philipp Tomsich <philipp.tomsich@...ll.eu>,
        liush <liush@...winnertech.com>, wefu@...hat.com,
        Wei Wu (吴伟) <lazyparser@...il.com>,
        Drew Fustini <drew@...gleboard.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        taiten.peng@...onical.com, aniket.ponkshe@...onical.com,
        Heinrich Schuchardt <heinrich.schuchardt@...onical.com>,
        gordan.markus@...onical.com
Subject: Re: [RFC PATCH V4 4/6] RISC-V: Implement arch_sync_dma* functions

On Wed, Sep 15, 2021 at 9:25 PM Anup Patel <anup@...infault.org> wrote:
>
> On Thu, Sep 16, 2021 at 7:03 AM Guo Ren <guoren@...nel.org> wrote:
> >
> > On Wed, Sep 15, 2021 at 3:50 PM Christoph Hellwig <hch@....de> wrote:
> > >
> > > On Sat, Sep 11, 2021 at 05:21:37PM +0800, guoren@...nel.org wrote:
> > > > +static void __dma_sync(phys_addr_t paddr, size_t size, enum dma_data_direction dir)
> > > > +{
> > > > +     if ((dir == DMA_FROM_DEVICE) && (dma_cache_sync->cache_invalidate))
> > > > +             dma_cache_sync->cache_invalidate(paddr, size);
> > > > +     else if ((dir == DMA_TO_DEVICE) && (dma_cache_sync->cache_clean))
> > > > +             dma_cache_sync->cache_clean(paddr, size);
> > > > +     else if ((dir == DMA_BIDIRECTIONAL) && dma_cache_sync->cache_flush)
> > > > +             dma_cache_sync->cache_flush(paddr, size);
> > > > +}
> > >
> > > Despite various snipplets this is a still pretty much the broken previous
> > > versions.  These need to use the CMO instructions directly which are
> > > about to go into review, and then your SBI can trap on those can call
> > > whatever non-standard mess you're using.
> > I think you mean put an ALTERNATIVE slot in the prologue of __dma_sync?
> >
> > #define ALT_DMA_SYNC()                                           \
> > asm(ALTERNATIVE(".rept 64\n nop\n .endr\n", "<vendor code>",
> > XXX_VENDOR_ID,        \
> >                 ERRATA_XXX, CONFIG_ERRATA_XXX)  \
> >                 : : : "memory")
> >
> > static void __dma_sync(phys_addr_t paddr, size_t size, enum
> > dma_data_direction dir)
> > {
> >         ALT_DMA_SYNC();
> >
> >         /* future cmo codes */
> > }
>
> I think Christoph is suggesting to always use CMO instructions for
> implementing arch specific DMA sync functions. The SBI implementation
> will trap-n-emulate CMO instructions when underlying HW does not
> have it. This means custom cache instructions on D1 can reside in
> the platform support code of OpenSBI.
>
> I also agree with the above suggestion. At least, this will ensure that we
> have only one way of doing cache operations from S-mode perspective
> which is CMO instructions.
>

Sounds good to me. For stralight Socs, we may need to add a l2 cache controller
driver in OpenSBI as well. IIRC, sifive cores do have some M-mode only
CMO instructions
as well but they may not align with CMO spec. I have to double check.

> Regards,
> Anup
>
> >
> >
> >
> >
> > --
> > Best Regards
> >  Guo Ren
> >
> > ML: https://lore.kernel.org/linux-csky/
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

-- 
Regards,
Atish

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