linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 12/18] KVM: arm64: nv: Handle PSCI call via smc from the guest
Date: Sat, 11 Feb 2023 10:07:41 +0000	[thread overview]
Message-ID: <Y+do7RAm5PC8LFw2@linux.dev> (raw)
In-Reply-To: <20230209175820.1939006-13-maz@kernel.org>

Hi Marc,

On Thu, Feb 09, 2023 at 05:58:14PM +0000, Marc Zyngier wrote:
> From: Jintack Lim <jintack.lim@linaro.org>
> 
> 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.

> Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
> Signed-off-by: Jintack Lim <jintack.lim@linaro.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  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 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.

-- 
Thanks,
Oliver

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-02-11 10:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-09 17:58 [PATCH 00/18] KVM: arm64: Prefix patches for NV support Marc Zyngier
2023-02-09 17:58 ` [PATCH 01/18] arm64: Add ARM64_HAS_NESTED_VIRT cpufeature Marc Zyngier
2023-02-09 17:58 ` [PATCH 02/18] KVM: arm64: Use the S2 MMU context to iterate over S2 table Marc Zyngier
2023-02-11  1:00   ` Andre Przywara
2023-02-09 17:58 ` [PATCH 03/18] KVM: arm64: nv: Introduce nested virtualization VCPU feature Marc Zyngier
2023-02-09 17:58 ` [PATCH 04/18] KVM: arm64: nv: Reset VCPU to EL2 registers if VCPU nested virt is set Marc Zyngier
2023-02-09 17:58 ` [PATCH 05/18] KVM: arm64: nv: Allow userspace to set PSR_MODE_EL2x Marc Zyngier
2023-02-09 17:58 ` [PATCH 06/18] KVM: arm64: nv: Add EL2 system registers to vcpu context Marc Zyngier
2023-02-09 17:58 ` [PATCH 07/18] KVM: arm64: nv: Add nested virt VCPU primitives for vEL2 VCPU state Marc Zyngier
2023-02-09 17:58 ` [PATCH 08/18] KVM: arm64: nv: Handle HCR_EL2.NV system register traps Marc Zyngier
2023-02-24 17:39   ` Joey Gouly
2023-02-24 18:36     ` Oliver Upton
2023-02-24 19:03       ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 09/18] KVM: arm64: nv: Support virtual EL2 exceptions Marc Zyngier
2023-02-09 17:58 ` [PATCH 10/18] KVM: arm64: nv: Inject HVC exceptions to the virtual EL2 Marc Zyngier
2023-02-09 17:58 ` [PATCH 11/18] KVM: arm64: nv: Handle trapped ERET from " Marc Zyngier
2023-02-09 17:58 ` [PATCH 12/18] KVM: arm64: nv: Handle PSCI call via smc from the guest Marc Zyngier
2023-02-11 10:07   ` Oliver Upton [this message]
2023-02-11 10:31     ` Marc Zyngier
2023-02-11 18:17       ` Oliver Upton
2023-02-09 17:58 ` [PATCH 13/18] KVM: arm64: nv: Add accessors for SPSR_EL1, ELR_EL1 and VBAR_EL1 from virtual EL2 Marc Zyngier
2023-02-09 17:58 ` [PATCH 14/18] KVM: arm64: nv: Emulate PSTATE.M for a guest hypervisor Marc Zyngier
2023-02-09 17:58 ` [PATCH 15/18] KVM: arm64: nv: Allow a sysreg to be hidden from userspace only Marc Zyngier
2023-02-09 17:58 ` [PATCH 16/18] KVM: arm64: nv: Emulate EL12 register accesses from the virtual EL2 Marc Zyngier
2023-02-09 17:58 ` [PATCH 17/18] KVM: arm64: nv: Filter out unsupported features from ID regs Marc Zyngier
2023-02-09 17:58 ` [PATCH 18/18] KVM: arm64: nv: Only toggle cache for virtual EL2 when SCTLR_EL2 changes Marc Zyngier
2023-02-13 22:26 ` [PATCH 00/18] KVM: arm64: Prefix patches for NV support Oliver Upton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+do7RAm5PC8LFw2@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).