Re: [PATCH v21 07/15] KVM: arm64: Forward GCS exceptions to nested guests

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Sep 30, 2026 at 10:48:17PM +0100, Mark Brown wrote:
> For nested guests where HFGITR_EL2.nGCSSTR_EL1 is clear or when there are

I see at [0] that, if HFGITR_EL2.nGCSSTR_EL1 is clear:

"If EL2 is implemented and enabled in the current Security state, and
either EL3 is not implemented or SCR_EL3.FGTEn == 1, then execution at EL1
using AArch64 of any of the specified instructions generates a GCS
exception with EC syndrome value 0x2D, unless the instruction generates a
higher priority exception."

For:

GCSSTR.
GCSSTTR when PSTATE.UAO is 1.
GCSSTTR when the Effective value of HCR_EL2.{NV, NV1} is {1, 1}.

So privileged GCS stores.

[0]: https://support.arm.com/documentation/111107/2026-09/AArch64-Registers/HFGITR-EL2--Hypervisor-Fine-Grained-Instruction-Trap-Register?lang=en

> L2 GCS data check exceptions we need to forward the exception to the guest.
> Add handling to do so.
>
> Reviewed-by: Leonardo Bras <leo.bras@arm.com>
> Signed-off-by: Mark Brown <broonie@kernel.org>

(A bunch of commentary here, just reasoning out loud for my own
understanding.)

All LGTM, so:

Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index db37678dcb05..a8198e96fcb4 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c

> +/*
> + * We might get GCS exceptions that need to be forwarded to the
> + * hypervisor when a nested guest has HFGITR_EL2.nGCSSTR_EL1 clear, or
> + * for a GCS data check exception for a L2 guest.
> + */

OK so I see this is used as a handler in:

static exit_handle_fn arm_exit_handlers[] = {
	...
	[ESR_ELx_EC_GCS]	= kvm_handle_gcs,
};

And as per the arm ref page, 0x2D == ESR_ELx_EC_GCS.

And it's always something being injected, so returning 1 (handled) is fine.

>  static int kvm_handle_gcs(struct kvm_vcpu *vcpu)
>  {
> -	/* We don't expect GCS, so treat it with contempt */
> -	if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> -		WARN_ON_ONCE(1);
> +	if (!kvm_has_gcs(vcpu->kvm)) {
> +		kvm_inject_undefined(vcpu);
> +		return 1;
> +	}

OK so make it not-a-kernel-warning if unsupported...

>
> +	if (vcpu_has_nv(vcpu)) {
> +		kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));

...And this is the L0 at physical EL2 -> vEL2 (in physical EL1) injecting a
synchronous exception.

So it seems to me the key point of the patch is to forward to nested
guests, hence the subject line :>)

> +		return 1;
> +	}
> +
> +	WARN_ON_ONCE(1);

And this is an 'impossible' case because it should have been handled
natively otherwise. So it's a bug in KVM if it ever happened.

--
Cheers, Lorenzo