From: Mark Brown <broonie@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [BOOT-WRAPPER PATCH 3/3] aarch64: Enable use of GCS for EL2 and below
Date: Tue, 26 Nov 2024 18:53:03 +0000 [thread overview]
Message-ID: <287e6fab-e858-4a7b-bc21-687c36742e24@sirena.org.uk> (raw)
In-Reply-To: <Z0YNFCfisiCqU3lJ@J2N7QTR9R3.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
On Tue, Nov 26, 2024 at 06:01:56PM +0000, Mark Rutland wrote:
> GCSCR_EL3.PCRSEL resets to 0, so the HW won't push to the GCS for BL/BLR
> and won't pop from the GCS for a RET. That menas there's no GCS value
> for a return value check to compare with...
Oh, good point - I'd trusted that the initialisations were required and
misremembered which of PCRSEL and RVCHKEN was which. Sorry about that.
The values on reset follow the same pattern in all the GCS control
registers down to GCSCRE0_EL1 so the initialisations of the other
control registers are equally redundant. We should be consistent here,
either initialising all the GCS control registers or relying on the
architecture defaults for all of them, and the note in the changelog
about them needs an update if the initialisation is there.
> That does raise the question of what specifically happens for a return
> at EL3 when GCSCR_EL3.{PCRSEL,RVCHKEN} == {1,0}. Can you enlighten me?
RET will attempt to load and use a GCS record, the pseudocode is in
LoadCheckGCSRecord() which isn't EL dependent other than the selection
of which GCSPR and GCSCR to use and setting the access as privileged if
we're not at EL0.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-11-26 18:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-26 15:39 [BOOT-WRAPPER PATCH 0/3] Add support for FEAT_FPMR and FEAT_GCS Mark Rutland
2024-11-26 15:39 ` [BOOT-WRAPPER PATCH 1/3] aarch64: shuffle ID_AA64PFR{0,1}_EL1 definitions Mark Rutland
2024-11-26 15:39 ` [BOOT-WRAPPER PATCH 2/3] aarch64: Enable use of FPMR for EL2 and below Mark Rutland
2024-11-26 17:05 ` Mark Brown
2024-11-26 15:39 ` [BOOT-WRAPPER PATCH 3/3] aarch64: Enable use of GCS " Mark Rutland
2024-11-26 17:20 ` Mark Brown
2024-11-26 18:01 ` Mark Rutland
2024-11-26 18:53 ` Mark Brown [this message]
2024-11-27 10:25 ` Mark Rutland
2024-11-27 11:22 ` 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=287e6fab-e858-4a7b-bc21-687c36742e24@sirena.org.uk \
--to=broonie@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
/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