linux-kernel - Re: [PATCH v3 1/7] arm64/sysreg: Convert CCSIDR

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] [day] [month] [year] [list]

Message-ID: <Y6CkxueMwWPBMV7h@sirena.org.uk>
Date:   Mon, 19 Dec 2022 17:52:06 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Akihiko Odaki <akihiko.odaki@...nix.com>,
        linux-kernel@...r.kernel.org, kvmarm@...ts.linux.dev,
        kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        James Morse <james.morse@....com>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        asahi@...ts.linux.dev, Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Sven Peter <sven@...npeter.dev>,
        Hector Martin <marcan@...can.st>
Subject: Re: [PATCH v3 1/7] arm64/sysreg: Convert CCSIDR_EL1 to automatic
 generation

On Mon, Dec 19, 2022 at 03:27:17PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > fully represent everything in the spec yet.  For things like the
> > registers with multiple possible views it's much more effort which
> > shouldn't get in the way of progress on features but with something like
> > this just updating the tool so we can match the architecture spec is the
> > right thing.

> I was tempted to add a Namespace tag that wouldn't generate the sysreg
> #defines, but only generate the fields with a feature-specific
> namespace. For example:

I think this is roughly where we'd end up - I was using the term view
when thinking about it but that's just bikeshed.

> Sysreg	CCSIDR_EL1	3	1	0	0	0
> Res0	63:32
> Unkn	31:28
> Field	27:13	NumSets
> Field	12:3	Associativity
> Field	2:0	LineSize
> EndSysreg
> 
> Namespace CCIDX CCSIDR_EL1
> Res0	63:56
> Field	55:32	NumSets
> Res0	31:25
> Field	24:3	Associativity
> Field	2:0	LineSize
> EndSysreg

Yeah, something like that.  I think we also want a way to label bits in
the root register as only existing in namespaces/views for things where
there's no default (eg, where a feature adds two views at once or things
have been there since the base architecture), and I wasn't sure if it
made sense to nest the declaration of the views inside the Sysreg (I'm
tempted to think it's more trouble than it's worth especially on the
tooling side).

I also wanted to go through and do an audit of all the current registers
to make sure there were no nasty cases that'd complicate things.  I
don't think there'd be anything but...

> the later generating:

> #define CCIDR_EL1_CCIDX_RES0		(GENMASK(63, 56) | GENMASK(31, 25))
> #define	CCIDR_EL1_CCIDX_NumSets		GENMASK(55, 32)
> #define	CCIDR_EL1_CCIDX_Associativity	GENMASK(24, 3)
> #define CCIDR_EL1_CCIDX_LineSize	GENMASK(2, 0)

> Thoughts?

Definitely that for the output.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)