GCS can generate exceptions with an EC of 0x2D (GCS Data Check
Exception) when data validation checks fail.  When running a nested
guest which has access to GCS such exceptions can be directed from EL0
to EL2 and therefore need to be forwarded to the guest hypervisor, add
handling for this.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 arch/arm64/kvm/handle_exit.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index a598072f36d2..2f5aef84b294 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -301,10 +301,18 @@ static int handle_svc(struct kvm_vcpu *vcpu)
 
 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;
+	}
 
+	if (vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu)) {
+		kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
+		return 1;
+	}
+
+	/* We shouldn't have generated a trap in this case */
+	WARN_ON_ONCE(1);
 	kvm_inject_undefined(vcpu);
 	return 1;
 }

-- 
2.39.5

On Wed, 20 Aug 2025 15:14:43 +0100,
Mark Brown <broonie@kernel.org> wrote:
> 
> GCS can generate exceptions with an EC of 0x2D (GCS Data Check
> Exception) when data validation checks fail.  When running a nested
> guest which has access to GCS such exceptions can be directed from EL0
> to EL2 and therefore need to be forwarded to the guest hypervisor, add
> handling for this.

Why is it so? A GCS exception from EL0 should be routed to EL1, no
matter what (either this is an L1 guest with EL1 pretending to be EL2,
or this is an L2 guest that has its own EL1).

Can you describe the case where we need to reinject the exception?

>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/kvm/handle_exit.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index a598072f36d2..2f5aef84b294 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -301,10 +301,18 @@ static int handle_svc(struct kvm_vcpu *vcpu)
>  
>  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;
> +	}
>  
> +	if (vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu)) {

We now have is_nested_ctxt(), which is more obvious.

> +		kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
> +		return 1;
> +	}
> +
> +	/* We shouldn't have generated a trap in this case */
> +	WARN_ON_ONCE(1);
>  	kvm_inject_undefined(vcpu);
>  	return 1;
>  }
> 

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

On Wed, Aug 20, 2025 at 11:15:25PM +0100, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:

> > GCS can generate exceptions with an EC of 0x2D (GCS Data Check
> > Exception) when data validation checks fail.  When running a nested
> > guest which has access to GCS such exceptions can be directed from EL0
> > to EL2 and therefore need to be forwarded to the guest hypervisor, add
> > handling for this.

> Why is it so? A GCS exception from EL0 should be routed to EL1, no
> matter what (either this is an L1 guest with EL1 pretending to be EL2,
> or this is an L2 guest that has its own EL1).

> Can you describe the case where we need to reinject the exception?

I think I'd got myself confused while looking at the HCR_EL2.TGE case
thinking we enabled that in some case.  I can't now see what I was
looking at there, pretty sure I'm just mistaken - thanks for spotting
that, unless I work out what I was thinking I'll drop this.