linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] arm64: Document requirements for fine grained traps at boot
Date: Fri, 26 Mar 2021 11:55:41 +0000	[thread overview]
Message-ID: <20210326115541.GC5126@arm.com> (raw)
In-Reply-To: <20210312154917.23263-1-broonie@kernel.org>

On Fri, Mar 12, 2021 at 03:49:17PM +0000, Mark Brown wrote:
> The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses
> to small sets of registers and instructions from EL1 and EL0.  Currently
> Linux makes no use of this feature, explicitly document that it should
> be disabled when entering the kernel at EL2 (as is the architectural
> default) to help avoid surprises.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  Documentation/arm64/booting.rst | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
> index 7552dbc1cc54..1efc2d3023bb 100644
> --- a/Documentation/arm64/booting.rst
> +++ b/Documentation/arm64/booting.rst
> @@ -270,6 +270,13 @@ Before jumping into the kernel, the following conditions must be met:
>        having 0b1 set for the corresponding bit for each of the auxiliary
>        counters present.
>  
> +  For CPUs with Fine Grained Traps (FEAT_FGT) extension present:
> +
> +  - If the kernel is entered at EL2:
> +
> +    - HAFGRTR_EL2, HDFGWTR_EL2, HDFGRTR_EL2, HFGWTR_EL2, HFGRTR_EL2 and
> +      HFGITR_EL2 must be initialised to 0.

While this requirement is correct, documenting such individual registers
doesn't scales well. You may run a 5 year old kernel on a newer CPU and
we can't predict which control registers have been added and what
side-effect they have. The architecture, at least for the above
registers, states that if warm reset to EL2, their value is 0. I think
the EL3 firmware (which is normally up to date with the CPU it is
running on) should follow the ARM ARM reset values. There are probably
EL1 registers with similar requirements (I haven't checked).

Can we instead have a broad statement regarding any EL1/EL2 registers
that they should be either rest to 0 or to the architectural (warm)
reset value as per the ARM ARM? Or something like any feature must be
disabled by default at the EL1/EL2 control registers level and this
would imply the fine-grained traps.

We currently have this statement:

  All writable architected system registers at the exception level where
  the kernel image will be entered must be initialised by software at a
  higher exception level to prevent execution in an UNKNOWN state.

The "prevent execution in an UNKNOWN state" needs to be clearer. The
above should also include exception levels _below_ the one where the
kernel is entered. It doesn't help if KVM is old and has no clue of new
EL1-specific registers.

Adding Mark R, I think he looked at some of these in the past.

-- 
Catalin

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

  reply	other threads:[~2021-03-26 11:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 15:49 [PATCH] arm64: Document requirements for fine grained traps at boot Mark Brown
2021-03-26 11:55 ` Catalin Marinas [this message]
2021-03-29 10:31   ` Will Deacon
2021-03-29 12:16     ` Catalin Marinas
2021-03-29 12:25     ` Mark Brown
2021-03-29 17:06   ` 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=20210326115541.GC5126@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).