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 <[email protected]>
> Signed-off-by: Mark Brown <[email protected]>
(A bunch of commentary here, just reasoning out loud for my own
understanding.)
All LGTM, so:
Reviewed-by: Lorenzo Stoakes (ARM) <[email protected]>
> 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
