linux-kernel - Re: [PATCH v2 1/9] RISC-V: Add AIA related CSR defines

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]

Message-ID: <CAK9=C2VzJvpQLPedc+ruUnw8xDDDaC6_Vmj6qg1nXv+iqU-AfQ@mail.gmail.com>
Date:   Fri, 27 Jan 2023 17:28:57 +0530
From:   Anup Patel <apatel@...tanamicro.com>
To:     Conor Dooley <conor@...nel.org>
Cc:     Anup Patel <anup@...infault.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Atish Patra <atishp@...shpatra.org>,
        Alistair Francis <Alistair.Francis@....com>,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/9] RISC-V: Add AIA related CSR defines

On Wed, Jan 18, 2023 at 2:12 AM Conor Dooley <conor@...nel.org> wrote:
>
> Hey Anup,
>
> I thought I had already replied here but clearly not, sorry!
>
> On Mon, Jan 09, 2023 at 10:39:08AM +0530, Anup Patel wrote:
> > On Thu, Jan 5, 2023 at 4:37 AM Conor Dooley <conor@...nel.org> wrote:
> > > On Tue, Jan 03, 2023 at 07:44:01PM +0530, Anup Patel wrote:
>
> > > > +/* AIA CSR bits */
> > > > +#define TOPI_IID_SHIFT               16
> > > > +#define TOPI_IID_MASK                0xfff
>
> While I think of it, it'd be worth noting that these are generic across
> all of topi, mtopi etc. Initially I thought that this mask was wrong as
> the topi section says:
>         bits 25:16 Interrupt identity (source number)
>         bits 7:0 Interrupt priority

These defines are for the AIA CSRs and not AIA APLIC IDC registers.

As per the latest frozen spec, the mtopi/stopi/vstopi has following bits:
    bits: 27:16 IID
    bits: 7:0 IPRIO

>
> > > > +#define TOPI_IPRIO_MASK              0xff
> > > > +#define TOPI_IPRIO_BITS              8
> > > > +
> > > > +#define TOPEI_ID_SHIFT               16
> > > > +#define TOPEI_ID_MASK                0x7ff
> > > > +#define TOPEI_PRIO_MASK              0x7ff
> > > > +
> > > > +#define ISELECT_IPRIO0               0x30
> > > > +#define ISELECT_IPRIO15              0x3f
> > > > +#define ISELECT_MASK         0x1ff
> > > > +
> > > > +#define HVICTL_VTI           0x40000000
> > > > +#define HVICTL_IID           0x0fff0000
> > > > +#define HVICTL_IID_SHIFT     16
> > > > +#define HVICTL_IPRIOM                0x00000100
> > > > +#define HVICTL_IPRIO         0x000000ff
> > >
> > > Why not name these as masks, like you did for the other masks?
> > > Also, the mask/shift defines appear inconsistent. TOPI_IID_MASK is
> > > intended to be used post-shift AFAICT, but HVICTL_IID_SHIFT is intended
> > > to be used *pre*-shift.
> > > Some consistency in naming and function would be great.
> >
> > The following convention is being followed in asm/csr.h for defining
> > MASK of any XYZ field in ABC CSR:
> > 1. ABC_XYZ : This name is used for MASK which is intended
> >    to be used before SHIFT
> > 2. ABC_XYZ_MASK: This name is used for MASK which is
> >    intended to be used after SHIFT
>
> Which makes sense in theory.
>
> > The existing defines for [M|S]STATUS, HSTATUS, SATP, and xENVCFG
> > follows the above convention. The only outlier is HGATPx_VMID_MASK
> > define which I will fix in my next KVM RISC-V series.
>
> Yup, it is liable to end up like that.
>
> > I don't see how any of the AIA CSR defines are violating the above
> > convention.
>
> What I was advocating for was picking one style and sticking to it.
> These copy-paste from docs things are tedious and error prone to review,
> and I don't think having multiple styles is helpful.

On the other hand, I think we should let developers choose a style
which is better suited for a particular register field instead enforcing
it here. The best we can do is follow a naming convention for defines.

>
> Tedious as it was, I did check all the numbers though, so in that
> respect:
> Reviewed-by: Conor Dooley <conor.dooley@...rochip.com>

BTW, this patch is shared with KVM AIA CSR series so most likely
I will take this patch through that series.

Regards,
Anup