linux-kernel - Re: [PATCH v2 1/3] dt-bindings: riscv: document cbom-block-size

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]

Date:   Wed, 18 May 2022 11:20:27 +0200
From:   Philipp Tomsich <philipp.tomsich@...ll.eu>
To:     Anup Patel <anup@...infault.org>
Cc:     Heiko Stübner <heiko@...ech.de>,
        Rob Herring <robh@...nel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        Wei Fu <wefu@...hat.com>, Guo Ren <guoren@...nel.org>,
        Atish Patra <atishp@...shpatra.org>,
        Nick Kossifidis <mick@....forth.gr>,
        Samuel Holland <samuel@...lland.org>,
        Christoph Muellner <cmuellner@...ux.com>, krzk+dt@...nel.org,
        DTML <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] dt-bindings: riscv: document cbom-block-size

On Wed, 18 May 2022 at 11:10, Anup Patel <anup@...infault.org> wrote:
> > > > > +    description:
> > > > > +      Blocksize in bytes for the Zicbom cache operations. The block
> > > > > +      size is a property of the core itself and does not necessarily
> > > > > +      match other software defined cache sizes.
> > > >
> > > > What about hardware defined cache sizes? I'm scratching my head as to
> > > > what a 'software defined cache size' is.
> >
> > I agree that this should be worded better. The intent was to tell that this
> > is different from say the l1-cache-block-size.
> >
> > I.e. these values can be the same but don't need to be. But I guess I got
> > too much lead on by a kernel implementation detail (L1_CACHE_BYTES constant)
>
> Better to just call it as "the cache block-size expected by Zicbom cache
> operations" without getting details of relation with L1 cache block size.

I would make this an even stronger statement and assert that Anup's
recommended rewording (and staying away from L1 block/line sizes in
terminology) is required to accurately reflect the design of the
RISC-V CMOs.

The Zicbom operation size is in fact decoupled from the
l1-cache-block-size (as that would be the cache line size — and
therefore the size of fetches/replacements to the cache) as the
deliberations within the CMO group showed.   This is only the granule
that Zicbom instructions operate on (and there might be additional
mechanisms at work in the background that ensure that this is safe for
any given underlying cache implementation).

Cheers,
Philipp.