Re: [PATCH v3 23/27] KVM: arm64: nv: Add SVC trap forwarding

From: Marc Zyngier <maz@kernel.org>
To: eric.auger@redhat.com
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will@kernel.org>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Chase Conklin <chase.conklin@arm.com>,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
	Darren Hart <darren@os.amperecomputing.com>,
	Miguel Luis <miguel.luis@oracle.com>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH v3 23/27] KVM: arm64: nv: Add SVC trap forwarding
Date: Thu, 10 Aug 2023 11:42:19 +0100	[thread overview]
Message-ID: <87wmy3p4ac.wl-maz@kernel.org> (raw)
In-Reply-To: <2a751a64-559e-cb17-4359-7f368c1b42ca@redhat.com>

Hi Eric,

On Thu, 10 Aug 2023 09:35:41 +0100,
Eric Auger <eric.auger@redhat.com> wrote:
> 
> Hi Marc,
> 
> On 8/8/23 13:47, Marc Zyngier wrote:
> > HFGITR_EL2 allows the trap of SVC instructions to EL2. Allow these
> > traps to be forwarded. Take this opportunity to deny any 32bit activity
> > when NV is enabled.
> 
> I can't figure out how HFGITR_EL2.{SVC_EL1, SVC_EL0 and ERET} are
> handled. Please could you explain.

- SVC: KVM itself never traps it, so any trap of SVC must be the
  result of a guest trap -- we don't need to do any demultiplexing. We
  thus directly inject the trap back. This is what the comment in
  handle_svc() tries to capture, but obviously fails to convey the
  point.

- ERET: This is already handled since 6898a55ce38c ("KVM: arm64: nv:
  Handle trapped ERET from virtual EL2"). Similarly to SVC, KVM never
  traps it unless we run NV.

Now, looking into it, I think I'm missing the additional case where
the L2 guest runs at vEL1. I'm about to add the following patchlet:

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 3b86d534b995..617ae6dea5d5 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -222,7 +222,22 @@ static int kvm_handle_eret(struct kvm_vcpu *vcpu)
 	if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_ERET_ISS_ERET)
 		return kvm_handle_ptrauth(vcpu);
 
-	kvm_emulate_nested_eret(vcpu);
+	/*
+	 * If we got here, two possibilities:
+	 *
+	 * - the guest is in EL2, and we need to fully emulate ERET
+	 *
+	 * - the guest is in EL1, and we need to reinject the
+         *   exception into the L1 hypervisor.
+	 *
+	 * If KVM ever traps ERET for its own use, we'll have to
+	 * revisit this.
+	 */
+	if (is_hyp_ctxt(vcpu))
+		kvm_emulate_nested_eret(vcpu);
+	else
+		kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
+
 	return 1;
 }
 

Does the above help?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
