All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 0/8] arm64: Automatic system register definition generation
Date: Thu, 21 Apr 2022 11:15:24 +0100	[thread overview]
Message-ID: <YmEuvDMnM9Plon2X@FVFF77S0Q05N> (raw)
In-Reply-To: <20220419104329.188489-1-broonie@kernel.org>

Hi Mark,

I'm obviously in favour of this series. Overall I think the general approach
looks good, and I've commented on the bits I'm not sure about.

The only things that I'm really not sure about is what we do for registers
whose structure changes, or where a register has multiple names (like some
GICv3 ICV regs), and it would be nice if we could see an example of those.

Otherwise, I think we just need to agree upon the naming/structure we want to
generate. With that we can do some preparatory renaming (and any strucutral
changes for things like shifts) ahead of a bulk conversion to generated
definitions.

Does that sound about right to you, or is there any concern that I've missed
that we should consider?

Thanks,
Mark.

On Tue, Apr 19, 2022 at 11:43:21AM +0100, Mark Brown wrote:
> The arm64 kernel requires some metadata for each system register it may
> need to access. Currently we have:
> 
> * A SYS_<regname> definition which sorresponds to a sys_reg() macro.
>   This is used both to look up a sysreg by encoding (e.g. in KVM), and
>   also to generate code to access a sysreg where the assembler is
>   unaware of the specific sysreg encoding.
> 
>   Where assemblers support the S3_<op1>_C<crn>_C<crm>_<op2> syntax for
>   system registers, we could use this rather than manually assembling
>   the instructions. However, we don't have consistent definitions for
>   these and we currently still need to handle toolchains that lack this
>   feature.
> 
> * A set of <regname>_<fieldname>_SHIFT and <regname>_<fieldname>_MASK
>   definitions, which can be used to extract fields from the register, or
>   to construct a register from a set of fields.
> 
>   These do not follow the convention used by <linux/bitfield.h>, and the
>   masks are not shifted into place, preventing their use in FIELD_PREP()
>   and FIELD_GET(). We require the SHIFT definitions for inline assembly
>   (and WIDTH definitions would be helpful for UBFX/SBFX), so we cannot
>   only define a shifted MASK. Defining a SHIFT, WIDTH, shifted MASK and
>   unshifted MASK is tedious and error-prone and life is much easier when
>   they can be relied up to exist when writing code.
> 
> * A set of <regname>_<fieldname>_<valname> definitions for each
>   enumerated value a field may hold. These are used when identifying the
>   presence of features.
> 
> Atop of this, other code has to build up metadata at runtime (e.g. the
> sets of RES0/RES1 bits in a register). This patch series introduces a
> script which describes registers and the fields within them in a format
> that is easy to cross reference with the architecture reference manual
> and uses them to generate the constants we use in a standard format:
> 
> | #define REG_ID_AA64ISAR0_EL1                    S3_0_C0_C6_0
> | #define SYS_ID_AA64ISAR0_EL1                    sys_reg(3, 0, 0, 6, 0)
> | #define SYS_ID_AA64ISAR0_EL1_Op0                3
> | #define SYS_ID_AA64ISAR0_EL1_Op1                0
> | #define SYS_ID_AA64ISAR0_EL1_CRn                0
> | #define SYS_ID_AA64ISAR0_EL1_CRm                6
> | #define SYS_ID_AA64ISAR0_EL1_Op2                0
> 
> | #define ID_AA64ISAR0_EL1_RNDR                   ARM64_SYSREG_BITMASK(63, 60)
> | #define ID_AA64ISAR0_EL1_RNDR_MASK              ARM64_SYSREG_BITMASK(63, 60)
> | #define ID_AA64ISAR0_EL1_RNDR_SHIFT             60
> | #define ID_AA64ISAR0_EL1_RNDR_WIDTH             4
> | #define ID_AA64ISAR0_EL1_RNDR_NI                ULL(0b0000)
> | #define ID_AA64ISAR0_EL1_RNDR_IMP               ULL(0b0001)
> 
> This should be particularly useful for the ID registers where we will be
> able to specify just the register and field for more of the bitfield
> information, simplifying ARM64_FTR_BITS() and providing helpers for use
> in struct arm64_cpu_capabilities or for hwcaps.
> 
> At the moment this is only intended to express metadata from the
> architecture, and does not handle policy imposed by the kernel, such as
> values exposed to userspace or VMs. In future this could be extended to
> express such information. This could also be extended to cover more
> information such as the FTR_SIGNED/FTR_UNSIGNED distinction. There is
> also currently no support for registers which change layout at runtime,
> for example based on virtualisation settings - these could be manually
> handled for the time being, or the script extended.
> 
> At the present time (especially given how near we are to the merge
> window) this is as much about getting feedback on the general approach
> and how to move forward if we want to move forward. Rather than
> attempting to convert every register at once the current series converts
> a few sample registers to provide some concrete examples but allow for
> easier updating during review of the file format and the script.
> Handling a register at a time should also make review less taxing so it
> seems like a sensible approach in general.
> 
> The generation script was originally written by Mark Rutland and
> subsequently improved and integrated into the kernel build by me.
> 
> v4:
>  - Rebase onto v5.18-rc3.
> v3:
>  - Rebase onto v5.18-rc1.
> v2:
>  - Fix issue with building bounds.s in an O= build by renaming the
>    generated header.
> 
> Mark Brown (7):
>   arm64/mte: Move shift from definition of TCF0 enumeration values
>   arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names
>   arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI
>   arm64/sysreg: Enable automatic generation of system register
>     definitions
>   arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1
>   arm64/sysreg: Generate definitions for TTBRn_EL1
>   arm64/sysreg: Generate definitions for SCTLR_EL1
> 
> Mark Rutland (1):
>   arm64: Add sysreg header generation scripting
> 
>  arch/arm64/include/asm/Kbuild                 |   1 +
>  arch/arm64/include/asm/archrandom.h           |   2 +-
>  arch/arm64/include/asm/sysreg.h               |  61 +----
>  arch/arm64/kernel/cpufeature.c                |  70 +++---
>  arch/arm64/kernel/mte.c                       |   6 +-
>  .../arm64/kvm/hyp/include/nvhe/fixed_config.h |  28 +--
>  arch/arm64/tools/Makefile                     |   8 +-
>  arch/arm64/tools/gen-sysreg.awk               | 213 ++++++++++++++++++
>  arch/arm64/tools/sysreg                       | 183 +++++++++++++++
>  9 files changed, 466 insertions(+), 106 deletions(-)
>  create mode 100755 arch/arm64/tools/gen-sysreg.awk
>  create mode 100644 arch/arm64/tools/sysreg
> 
> 
> base-commit: b2d229d4ddb17db541098b83524d901257e93845
> -- 
> 2.30.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-04-21 10:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 10:43 [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown
2022-04-19 10:43 ` [PATCH v4 1/8] arm64/mte: Move shift from definition of TCF0 enumeration values Mark Brown
2022-04-21  9:33   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 2/8] arm64/sysreg: Standardise ID_AA64ISAR0_EL1 macro names Mark Brown
2022-04-21  9:35   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 3/8] arm64/sysreg: Rename SCTLR_EL1_NTWE/TWI to SCTLR_EL1_nTWE/TWI Mark Brown
2022-04-21  9:36   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 4/8] arm64: Add sysreg header generation scripting Mark Brown
2022-04-21  9:47   ` Mark Rutland
2022-04-21 13:00     ` Mark Brown
2022-04-21 14:16       ` Mark Rutland
2022-04-21 14:50         ` Mark Brown
2022-04-21 15:35           ` Mark Rutland
2022-04-21 15:46             ` Mark Brown
2022-04-19 10:43 ` [PATCH v4 5/8] arm64/sysreg: Enable automatic generation of system register definitions Mark Brown
2022-04-21  9:52   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 6/8] arm64/sysreg: Generate definitions for ID_AA64ISAR0_EL1 Mark Brown
2022-04-21  9:58   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 7/8] arm64/sysreg: Generate definitions for TTBRn_EL1 Mark Brown
2022-04-21  9:59   ` Mark Rutland
2022-04-19 10:43 ` [PATCH v4 8/8] arm64/sysreg: Generate definitions for SCTLR_EL1 Mark Brown
2022-04-21 10:05   ` Mark Rutland
2022-04-22 12:14     ` Mark Brown
2022-04-22 13:42       ` Mark Rutland
2022-04-22 13:50         ` Mark Brown
2022-04-21 10:15 ` Mark Rutland [this message]
2022-04-21 15:14   ` [PATCH v4 0/8] arm64: Automatic system register definition generation Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmEuvDMnM9Plon2X@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.