From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DBB5DC636CC for ; Sat, 11 Feb 2023 10:33:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zylOw2M5wFpLldWpRaAzENMXbIjuFFEbpKelFNzy808=; b=qFn0lmTMPAZhNt TZyuyRosZYwd01dW77SstGfSNEAA2vJ/VI1gQNMSH9++YzmsqFMsddSDMICEu5SY6iejq/Rey21qc iUFRegdSjBkoOVlZWZogLR5qZYjU9sRmSeLUHivYBfp8XFjjmO7ht4v0X5A6Fn0lbulH9wyhz5O0J DxQPSYi+yFupd/HkB6VkvLOlFLeW0EoRCWveIzzFFLha/9Zo7YVym5jHc+JHhWtvJa/4xUVSdXgXS Ahkn6e7t6aamo6gOynTEbkYRRU7GgMFt0kF9kSXg3pniLvNcGrztLxCAR33feRhOC2F+MWuFN5EvV ccVLXuQvuPwrwXTfyncw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQnAy-009DBp-Jh; Sat, 11 Feb 2023 10:32:12 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pQnAu-009DBH-LY for linux-arm-kernel@lists.infradead.org; Sat, 11 Feb 2023 10:32:10 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2A83FB80FE1; Sat, 11 Feb 2023 10:32:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7EBDC433D2; Sat, 11 Feb 2023 10:32:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676111524; bh=pDO3u6i+TOSzOKQUlqI4d5eFM2UpU6qY25Xpyg4lKbM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dJeFQSB1CdF3qLNKfe7/Mfp41nDWrxF/+BM3HwnBFTKDEJsYh9QwdWDs0JpmyAlGy uYhcwV7X7tV/O5KbY0EenL7sHxjmhf5HQPMm/AuCqGWjxRJh7OeSTqksrloRElBxY+ K5IzK9j3etKrjy2oHY3wvrmT0O/yupdmgxeCZ6v0yrZh8NjJiCbyx4nOfEnu84WnNd igRVhshiXeTfjhjvR2DGHrAltoJ7zgyHC/So/LmjMgl87/v0lyX0yoCflD827krnE4 KpFA0Cuirgrccjt4W54xBEwprU72cP1iJbYse1EVSjB4uStm5bIjF9AR/p+b+1UBAk Hmx6GzE8MZgXA== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1pQnAo-009WJz-EV; Sat, 11 Feb 2023 10:32:02 +0000 Date: Sat, 11 Feb 2023 10:31:59 +0000 Message-ID: <87pmaglcgw.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Andre Przywara , Catalin Marinas , Christoffer Dall , Ganapatrao Kulkarni , Russell King , James Morse , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH 12/18] KVM: arm64: nv: Handle PSCI call via smc from the guest In-Reply-To: References: <20230209175820.1939006-1-maz@kernel.org> <20230209175820.1939006-13-maz@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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, andre.przywara@arm.com, catalin.marinas@arm.com, christoffer.dall@arm.com, gankulkarni@os.amperecomputing.com, rmk+kernel@armlinux.org.uk, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230211_023209_035441_05A3C696 X-CRM114-Status: GOOD ( 50.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 11 Feb 2023 10:07:41 +0000, Oliver Upton wrote: > > Hi Marc, > > On Thu, Feb 09, 2023 at 05:58:14PM +0000, Marc Zyngier wrote: > > From: Jintack Lim > > > > VMs used to execute hvc #0 for the psci call if EL3 is not implemented. > > However, when we come to provide the virtual EL2 mode to the VM, the > > host OS inside the VM calls kvm_call_hyp() which is also hvc #0. So, > > it's hard to differentiate between them from the host hypervisor's point > > of view. > > > > So, let the VM execute smc instruction for the psci call. On ARMv8.3, > > even if EL3 is not implemented, a smc instruction executed at non-secure > > EL1 is trapped to EL2 if HCR_EL2.TSC==1, rather than being treated as > > UNDEFINED. So, the host hypervisor can handle this psci call without any > > confusion. > > I think this commit message is rather stale to the point of being rather > misleading. This lets the vEL2 get at the entire gamut of SMCCC calls we > have in KVM, not just PSCI. > > Of course, no problem with that since it is a requirement, but for > posterity the commit message should reflect the current state of KVM. > > If I may suggest: > > Non-nested guests have used the hvc instruction to initiate SMCCC > calls into KVM. This is quite a poor fit for NV as hvc exceptions are > always taken to EL2. In other words, KVM needs to unconditionally > forward the hvc exception back into vEL2 to uphold the architecture. > > Instead, treat the smc instruction from vEL2 as we would a guest > hypercall, thereby allowing the vEL2 to interact with KVM's hypercall > surface. Note that on NV-capable hardware HCR_EL2.TSC causes smc > instructions executed in non-secure EL1 to trap to EL2, even if EL3 is > not implemented. Very nice! > > > Reviewed-by: Alexandru Elisei > > Signed-off-by: Jintack Lim > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/handle_exit.c | 24 ++++++++++++++++++++++-- > > 1 file changed, 22 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > > index e75101f2aa6c..b0c343c4e062 100644 > > --- a/arch/arm64/kvm/handle_exit.c > > +++ b/arch/arm64/kvm/handle_exit.c > > @@ -63,6 +63,8 @@ static int handle_hvc(struct kvm_vcpu *vcpu) > > > > static int handle_smc(struct kvm_vcpu *vcpu) > > { > > + int ret; > > + > > /* > > * "If an SMC instruction executed at Non-secure EL1 is > > * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a > > @@ -70,10 +72,28 @@ static int handle_smc(struct kvm_vcpu *vcpu) > > * > > * We need to advance the PC after the trap, as it would > > * otherwise return to the same address... > > + * > > + * If imm is non-zero, it's not defined, so just skip it. > > + */ > > + if (kvm_vcpu_hvc_get_imm(vcpu)) { > > + vcpu_set_reg(vcpu, 0, ~0UL); > > + kvm_incr_pc(vcpu); > > + return 1; > > + } > > + > > + /* > > + * If imm is zero, it's a psci call. > > + * Note that on ARMv8.3, even if EL3 is not implemented, SMC executed > > + * at Non-secure EL1 is trapped to EL2 if HCR_EL2.TSC==1, rather than > > + * being treated as UNDEFINED. > > */ > > - vcpu_set_reg(vcpu, 0, ~0UL); > > + ret = kvm_hvc_call_handler(vcpu); > > + if (ret < 0) > > + vcpu_set_reg(vcpu, 0, ~0UL); > > + > > This also has the subtle effect of allowing smc instructions from a > non-nested guest to hit our hypercall surface too. I think we'll have to eventually allow that (see the TRNG spec which we blatantly deviate from by requiring an HVC), but we don't have to cross that bridge just yet. > I think we should avoid this and only handle smcs that actually come > from a vEL2. What do you think about the following? > > I can squash in all of the changes I've asked for here. > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index b0c343c4e062..a798c0b4d717 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c > @@ -73,16 +73,18 @@ static int handle_smc(struct kvm_vcpu *vcpu) > * We need to advance the PC after the trap, as it would > * otherwise return to the same address... > * > - * If imm is non-zero, it's not defined, so just skip it. > + * Only handle SMCs from the virtual EL2 with an immediate of zero and > + * skip it otherwise. > */ > - if (kvm_vcpu_hvc_get_imm(vcpu)) { > + if (!vcpu_is_el2(vcpu) || kvm_vcpu_hvc_get_imm(vcpu)) { > vcpu_set_reg(vcpu, 0, ~0UL); > kvm_incr_pc(vcpu); > return 1; > } > > /* > - * If imm is zero, it's a psci call. > + * If imm is zero then it is likely an SMCCC call. > + * > * Note that on ARMv8.3, even if EL3 is not implemented, SMC executed > * at Non-secure EL1 is trapped to EL2 if HCR_EL2.TSC==1, rather than > * being treated as UNDEFINED. > Looks good to me. Thanks for the suggestions! M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel