All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mark Brown" <broonie@kernel.org>
Cc: "Oliver Upton" <oupton@kernel.org>,
	kvmarm@lists.linux.dev, "Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH v19 05/14] KVM: arm64: Set PSTATE.EXLOCK when entering an exception
Date: Wed, 12 Aug 2026 19:33:29 +0000	[thread overview]
Message-ID: <20260812193330.51CB31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812-arm64-gcs-v19-5-9105afd828ac@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `compute_exlock()` uses `is_hyp_ctxt(vcpu)` to select between `GCSCR_EL1` and `GCSCR_EL2`, which evaluates the current execution context rather than the explicit target exception level.
--

--- Patch [5]: [PATCH v19 05/14] KVM: arm64: Set PSTATE.EXLOCK when entering an exception ---
commit 0b3b4f11382cdcd92d8ee1a1c35e2013e9df99ba
Author: Mark Brown <broonie@kernel.org>

KVM: arm64: Set PSTATE.EXLOCK when entering an exception

This commit implements the management of PSTATE.EXLOCK when entering an
exception in KVM's AArch64 exception injection path. When taking an exception
to the same EL, EXLOCK is set to the value of GCSCR_ELx.EXLOCKEN.

> diff --git a/arch/arm64/kvm/hyp/exception.c b/arch/arm64/kvm/hyp/exception.c
> index bef40ddb16dbc..15b00e0ee1ec7 100644
> --- a/arch/arm64/kvm/hyp/exception.c
> +++ b/arch/arm64/kvm/hyp/exception.c
[ ... ]
> @@ -65,6 +65,38 @@ static void __vcpu_write_spsr_und(struct kvm_vcpu *vcpu, u64 val)
>  		vcpu->arch.ctxt.spsr_und = val;
>  }
>  
> +static unsigned long compute_exlock(struct kvm_vcpu *vcpu,
> +				    unsigned long mode,
> +				    unsigned long target_mode)
> +{
> +	u64 gcscr;
> +
> +	if (!kvm_has_gcs(kern_hyp_va(vcpu->kvm)))
> +		return 0;
> +
> +	/* GCS can't be enabled for 32 bit */
> +	if (mode & PSR_MODE32_BIT)
> +		return 0;
> +
> +	/* When taking an exception to a higher EL EXLOCK is cleared. */
> +	if ((mode | PSR_MODE_THREAD_BIT) != target_mode)
> +		return 0;
> +
> +	/*
> +	 * When taking an exception to the same EL EXLOCK is set to
> +	 * the effective value of GCSR_ELx.EXLOCKEN.
> +	 */
> +	if (is_hyp_ctxt(vcpu))
> +		gcscr = __vcpu_read_sys_reg(vcpu, GCSCR_EL2);
> +	else
> +		gcscr = __vcpu_read_sys_reg(vcpu, GCSCR_EL1);

[Severity: Medium]
Does this code read the correct GCSCR_ELx register if the target exception
level differs from the current hypervisor context?

By using is_hyp_ctxt(vcpu), this evaluates the current execution context
(for example, if HCR_EL2.TGE is set) rather than relying on target_mode. In
enter_exception64(), the target mode is explicitly used to select the
correct registers:

	switch (target_mode) {
	case PSR_MODE_EL1h:
		vbar = __vcpu_read_sys_reg(vcpu, VBAR_EL1);
		sctlr = __vcpu_read_sys_reg(vcpu, SCTLR_EL1);
		...

If KVM injects an exception to EL1 (where target_mode == PSR_MODE_EL1h)
while is_hyp_ctxt(vcpu) evaluates to true, compute_exlock() would
incorrectly read GCSCR_EL2 instead of GCSCR_EL1.

Should this logic be updated to use target_mode == PSR_MODE_EL2h instead of
is_hyp_ctxt(vcpu) to ensure consistency with the rest of the exception
injection path?

> +
> +	if (gcscr & GCSCR_ELx_EXLOCKEN)
> +		return PSR_EXLOCK_BIT;
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812-arm64-gcs-v19-0-9105afd828ac@kernel.org?part=5

  reply	other threads:[~2026-08-12 19:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 19:11 [PATCH v19 00/14] KVM: arm64: Provide guest support for GCS Mark Brown
2026-08-12 19:12 ` [PATCH v19 01/14] arm64/gcs: Ensure FGTs for EL1 GCS instructions are disabled Mark Brown
2026-08-12 19:12 ` [PATCH v19 02/14] KVM: arm64: Fix FGT mapping for HFGITR_EL2.nGCSEPP Mark Brown
2026-08-12 19:12 ` [PATCH v19 03/14] KVM: arm64: Manage GCS access and registers for guests Mark Brown
2026-08-12 19:44   ` sashiko-bot
2026-08-12 19:12 ` [PATCH v19 04/14] KVM: arm64: Ensure GCS memory effects are visible Mark Brown
2026-08-12 19:12 ` [PATCH v19 05/14] KVM: arm64: Set PSTATE.EXLOCK when entering an exception Mark Brown
2026-08-12 19:33   ` sashiko-bot [this message]
2026-08-12 19:12 ` [PATCH v19 06/14] KVM: arm64: Validate GCS exception lock when emulating ERET Mark Brown
2026-08-12 19:12 ` [PATCH v19 07/14] KVM: arm64: Forward GCS exceptions to nested guests Mark Brown
2026-08-12 19:32   ` sashiko-bot
2026-08-12 19:12 ` [PATCH v19 08/14] KVM: arm64: Enforce EXLOCK for SPSR and ELR Mark Brown
2026-08-12 19:12 ` [PATCH v19 09/14] KVM: arm64: Allow GCS to be enabled for guests Mark Brown
2026-08-12 19:12 ` [PATCH v19 10/14] KVM: selftests: arm64: Add GCS registers to get-reg-list Mark Brown
2026-08-12 19:30   ` sashiko-bot
2026-08-12 19:12 ` [PATCH v19 11/14] KVM: selftests: arm64: Add GCS to set_id_regs Mark Brown
2026-08-12 19:12 ` [PATCH v19 12/14] KVM: selftests: arm64: Only restore SPSR_EL1 and ELR_EL1 if they change Mark Brown
2026-08-12 19:12 ` [PATCH v19 13/14] tools: Synchronise the kernel esr.h Mark Brown
2026-08-12 19:37   ` sashiko-bot
2026-08-12 19:12 ` [PATCH v19 14/14] KVM: selftests: arm64: Add GCS EXLOCK exception emulation test Mark Brown
2026-08-12 19:37   ` sashiko-bot

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=20260812193330.51CB31F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=broonie@kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.