From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D266618991E; Wed, 20 Aug 2025 22:15:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755728130; cv=none; b=LezQdxf41Y/pwVre/Jxn+G3nGqxFhWj+wqrh9JDMnV/eIvLxeHvD1H3UP2aHLQMsdYAc+ZCL/+fl6XPd5OQj6poqcBviSc26ClenvdYey/idUxZWf1kAwTy8J3RWtQ/pWJ1Pby1c7omX7P0eYc5Pdc6MNwy9rZoLTq+RpK4TkRM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755728130; c=relaxed/simple; bh=pV6kDL6PIDFC0mwCK5gV9e0W2aPceEaVuWKaFn/7g6M=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=UrRs8bnMCjcXcj9prCdxABpVTd0oIX10qx+kQhSdchSqSr0A5cv5zRp6iYf50Z6BOH4+z/dhftg3d4xR4gTuNCHnoC2h5FLq5K3lPLQGirYU41nOG6ifTVEd3EWtVwH+f38f/6O9YrcG09nd5vKGRjz4kzN8lRMRBCeOLcI94q8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y2KyhvhA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y2KyhvhA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3690CC4CEE7; Wed, 20 Aug 2025 22:15:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1755728130; bh=pV6kDL6PIDFC0mwCK5gV9e0W2aPceEaVuWKaFn/7g6M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Y2KyhvhAVR3/gKC7W/S1QdsFqJ5l4WaOyzdLBEUDZr+vdUm4Lr790sESxZA6BBclN fugWGpTAV8t9htbX9EdrBo+hZfDjLGkZGcWeN6z7ISrP14fcfyMoCfRxsEH96nQ8qv XcWsitR1H7qLNcM6BAxEaY1886/48KQlU25v+SAdx/y1r9ApGvpzOeW77R2+T/Bic7 A4DFUFvsPSf94l+fA5Hr8khXeNpPIqZRJsKxYorDa0kY92r6vTZZc8ObaZ6i6rJLPj +e+M75CMCrtpkSJKP1Bc4X9yGqBQrBu3uLYmWqzwNaB6iIGa506aI+IRk3gQLhlWmr JQRBM5AoNvohw== Received: from host86-149-246-145.range86-149.btcentralplus.com ([86.149.246.145] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uor5b-009VxZ-Sz; Wed, 20 Aug 2025 23:15:28 +0100 Date: Wed, 20 Aug 2025 23:15:25 +0100 Message-ID: <87ldndk5c2.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Oliver Upton , Joey Gouly , Suzuki K Poulose , Shuah Khan , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v15 3/6] KVM: arm64: Forward GCS exceptions to nested guests In-Reply-To: <20250820-arm64-gcs-v15-3-5e334da18b84@kernel.org> References: <20250820-arm64-gcs-v15-0-5e334da18b84@kernel.org> <20250820-arm64-gcs-v15-3-5e334da18b84@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 86.149.246.145 X-SA-Exim-Rcpt-To: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, shuah@kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 20 Aug 2025 15:14:43 +0100, Mark Brown 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 > --- > 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.