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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE588C76188 for ; Wed, 5 Apr 2023 07:35:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230163AbjDEHf3 (ORCPT ); Wed, 5 Apr 2023 03:35:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229925AbjDEHf1 (ORCPT ); Wed, 5 Apr 2023 03:35:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45975A6 for ; Wed, 5 Apr 2023 00:35:26 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id C61E462244 for ; Wed, 5 Apr 2023 07:35:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 293D1C433D2; Wed, 5 Apr 2023 07:35:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680680125; bh=r9fPk2ZLwV8C4ivtlt4hbSQ0Xx3nNbvxEH7kLfN7kTY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YTwzs24ZFYpYps1DURxOFyoQzr8k+w0vnAuZiRYv4FZKzA4bzXglzoMkOgB7CFB92 Wz/0RKqQYjhdWTmcyT4RSY6eW+yRAS+E+tB7dJ9TRhi6TmNs6xIZajIcHsgzMNNJ+M D6vHJb2VlQr+jtfIyckq44KaojgrZ++nLtPg66Dp4zaTX7/r+quT/IH27pTMp5ucNr doD1yX4K5ZtsBAZ9G0ddnUczPMoHDPYcnPquN5gdgJ8yHfedFF7u1qDJgMCZ6ZPSs3 LyJZVjsTAvGY9euZeHVCJ3GvDmYmz2ejDtwk9PKxuRyZzf4bdSNgL3aE7Wc3UzuRBN uV326ypH7W8PA== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] 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 1pjxfu-005tS6-PZ; Wed, 05 Apr 2023 08:35:22 +0100 Date: Wed, 05 Apr 2023 08:35:05 +0100 Message-ID: <87o7o26aty.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, Paolo Bonzini , James Morse , Suzuki K Poulose , Zenghui Yu , Sean Christopherson , Salil Mehta Subject: Re: [PATCH v3 08/13] KVM: arm64: Add support for KVM_EXIT_HYPERCALL In-Reply-To: <20230404154050.2270077-9-oliver.upton@linux.dev> References: <20230404154050.2270077-1-oliver.upton@linux.dev> <20230404154050.2270077-9-oliver.upton@linux.dev> 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") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, pbonzini@redhat.com, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, seanjc@google.com, salil.mehta@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 04 Apr 2023 16:40:45 +0100, Oliver Upton wrote: > > In anticipation of user hypercall filters, add the necessary plumbing to > get SMCCC calls out to userspace. Even though the exit structure has > space for KVM to pass register arguments, let's just avoid it altogether > and let userspace poke at the registers via KVM_GET_ONE_REG. > > This deliberately stretches the definition of a 'hypercall' to cover > SMCs from EL1 in addition to the HVCs we know and love. KVM doesn't > support EL1 calls into secure services, but now we can paint that as a > userspace problem and be done with it. > > Finally, we need a flag to let userspace know what conduit instruction > was used (i.e. SMC vs. HVC). > > Signed-off-by: Oliver Upton > --- > Documentation/virt/kvm/api.rst | 18 ++++++++++++++++-- > arch/arm64/include/uapi/asm/kvm.h | 4 ++++ > arch/arm64/kvm/handle_exit.c | 4 +++- > arch/arm64/kvm/hypercalls.c | 16 ++++++++++++++++ > 4 files changed, 39 insertions(+), 3 deletions(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 9b01e3d0e757..9497792c4ee5 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6221,11 +6221,25 @@ to the byte array. > __u64 flags; > } hypercall; > > -Unused. This was once used for 'hypercall to userspace'. To implement > -such functionality, use KVM_EXIT_IO (x86) or KVM_EXIT_MMIO (all except s390). > + > +It is strongly recommended that userspace use ``KVM_EXIT_IO`` (x86) or > +``KVM_EXIT_MMIO`` (all except s390) to implement functionality that > +requires a guest to interact with host userpace. > > .. note:: KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO. > > +For arm64: > +---------- > + > +``nr`` contains the function ID of the guest's SMCCC call. Userspace is > +expected to use the ``KVM_GET_ONE_REG`` ioctl to retrieve the call > +parameters from the vCPU's GPRs. > + > +Definition of ``flags``: > + - ``KVM_HYPERCALL_EXIT_SMC``: Indicates that the guest used the SMC > + conduit to initiate the SMCCC call. If this bit is 0 then the guest > + used the HVC conduit for the SMCCC call. > + > :: > > /* KVM_EXIT_TPR_ACCESS */ > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index f9672ef1159a..f86446c5a7e3 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -472,12 +472,16 @@ enum { > enum kvm_smccc_filter_action { > KVM_SMCCC_FILTER_HANDLE = 0, > KVM_SMCCC_FILTER_DENY, > + KVM_SMCCC_FILTER_FWD_TO_USER, > > #ifdef __KERNEL__ > NR_SMCCC_FILTER_ACTIONS > #endif > }; > > +/* arm64-specific KVM_EXIT_HYPERCALL flags */ > +#define KVM_HYPERCALL_EXIT_SMC (1U << 0) > + > #endif > > #endif /* __ARM_KVM_H__ */ > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index 68f95dcd41a1..3f43e20c48b6 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c > @@ -71,7 +71,9 @@ static int handle_smc(struct kvm_vcpu *vcpu) > * Trap exception, not a Secure Monitor Call exception [...]" > * > * We need to advance the PC after the trap, as it would > - * otherwise return to the same address... > + * otherwise return to the same address. Furthermore, pre-incrementing > + * the PC before potentially exiting to userspace maintains the same > + * abstraction for both SMCs and HVCs. nit: this comment really needs to find its way in the documentation so that a VMM author can determine the PC of the SMC/HVC. This is specially important for 32bit, which has a 16bit encodings for SMC/HVC. And thinking of it, this outlines a small flaw in this API. If luserspace needs to find out about the address of the HVC/SMC, it needs to know the *size* of the instruction. But we don't propagate the ESR value. I think this still works by construction (userspace can check PSTATE and work out whether we're in ARM or Thumb mode), but this feels fragile. Should we expose the ESR, or at least ESR_EL2.IL as an additional flag? Thanks, M. -- Without deviation from the norm, progress is not possible.