Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp336301pxp; Wed, 16 Mar 2022 06:49:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJNeCTklTl8uUFHaEo+Yd5hE3At5fnFocrufYV3W/RaWJQBIu3GQOsSAvBXc0WVcJoS3aZ X-Received: by 2002:a17:907:62a9:b0:6da:7953:4df0 with SMTP id nd41-20020a17090762a900b006da79534df0mr89165ejc.316.1647438592057; Wed, 16 Mar 2022 06:49:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647438592; cv=none; d=google.com; s=arc-20160816; b=kpRf9KHr4UTi8N3V+6COYnuVZ06qrFWie+Wvl/A37pw0VMZZrnjQwhj+EPEaKRQ2mY hjRXR/YsFBi6h2FtPd9J+hzbgvft0nxF9bX61MNB37+XBaK69SlGPLjqguSuwxm6+DWn O5Lo0Esi9oyaDIu6YiSRlizuIBY2W6p/zrW8/0vKvKqzb4LnA7rY/Lp0qLGoKTq0si6k hKQrZ5u3/h0n4/xFE/xblBKAGZQM2mOF6Sl7mhdTpg/3ivPXQ27K2o8fmoPAikWW5nGh 45E6d/OW/gV4rdsY4hdngMBHA9DVivsekT2uT+/9TrIs+i5pn/Rj1HM0XQ/nDIDrm8x0 hr6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=/gCZYXA1pFPtDLMS/KV6Ow2JMvpV89INylwyV10OD1Q=; b=xnXjYiNsJjdBkh4ClYWV4eZpBsRdhy0y7THAIz/hIUclLTMSRFHbvjl/H7dwfpjPUE LZ5UW15oxCINzQTi4rnL07klTd1R0VbeaTM1//ZjvDlni1Oe2YTPnIHcdpULvIBJYHM2 eAmaQCSFU1jD9E30BHLslMVnlvZXzqQvEH8INxc1OaUssbjdKJJ51gXRdY9xLuXhjXnN 3PZ3QOiM4TOYOC+UkwLHH9iCvWXUO3AM+0ptRU8g7idRzKGhkyiSiIR3Qv73gUepyr9W aCkW3PYQqFgeMOcMAYLbOiruBjANVobAAAucqUT8/VPtCt6DNIr7Nx8fIEr6PtBH50aS P//A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=o8EjxOyg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f1-20020a170906560100b006cf5754360dsi1101191ejq.905.2022.03.16.06.49.26; Wed, 16 Mar 2022 06:49:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=o8EjxOyg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350763AbiCORzY (ORCPT + 99 others); Tue, 15 Mar 2022 13:55:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238572AbiCORzX (ORCPT ); Tue, 15 Mar 2022 13:55:23 -0400 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2948522C5 for ; Tue, 15 Mar 2022 10:54:10 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id u3so34372ybh.5 for ; Tue, 15 Mar 2022 10:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/gCZYXA1pFPtDLMS/KV6Ow2JMvpV89INylwyV10OD1Q=; b=o8EjxOygDbe80v1/WABejnL1Pnq2uPy2+1seK8c4qpLhT7Tvg6tysQsseyBW42n2Nm DecA+jHN9K8mORqxXFOt2hQcNu16K8S7CiRpGbANNDtPWG9LE0R4INvJrBK/SSw/iGHK igHPhlAOlERy+Py3Naz9mrwa2uTojC1pjW2TiJFoffo905jVV0jUhmoko1UWFsJFFvZJ co3JQohnNSRP5sWZolye/BxIjelGc6eOy7h1HmL+TOwZAYp6cwi0G/e8o7R8/dkJYmnO FkS1lFtSA1q77Icd4gMoCqv9j8jSU+QJETSbQUfK6o5t6xnyIJZMUfqvYRhc1qvdULmh +9rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/gCZYXA1pFPtDLMS/KV6Ow2JMvpV89INylwyV10OD1Q=; b=U2OsHcWD71x7fad5/MNuRwzzkID1kOxEBjUXBtaO7rDZ9+BulzSk8djANpWZKpC1rW 6Af/B+ArnqWlOfatOzU1NjCi4sHRamIE5Y1eiywgIVTRe7bQbutiaTZYBE5eh7RXevSE EMXIt80Rbs1xT+5Qh9QFV7LH1eFhr4xZc41n8hRUBA4fnLxtBmp7yFMsHWJUZ+FwbUgN Z1IEKY3WpPZtQBj/mqpmbPHOtOBVpQSwEjPT/O5Hls05tpM4CQ81+Sip/wqWgRj60R2W /5gqX05JwmX1r/NNISG3sSREjOTq7i3z4oBy62+WIikO0e9xEuGiOYp+jWXWsh0pAZh+ d9uQ== X-Gm-Message-State: AOAM530a94wbDssis8nBaTM4St4YAEM3DEe7tckFDrN1b0iPGkpHPbrt 1D9BEaJBWjOv5P7BzMwe/npZ+0JHRY1SPSGAaJNDnA== X-Received: by 2002:a5b:d46:0:b0:628:aafa:1e54 with SMTP id f6-20020a5b0d46000000b00628aafa1e54mr23369223ybr.509.1647366849726; Tue, 15 Mar 2022 10:54:09 -0700 (PDT) MIME-Version: 1.0 References: <20220224172559.4170192-1-rananta@google.com> <20220224172559.4170192-8-rananta@google.com> In-Reply-To: From: Raghavendra Rao Ananta Date: Tue, 15 Mar 2022 10:53:58 -0700 Message-ID: Subject: Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register To: Oliver Upton Cc: Marc Zyngier , Andrew Jones , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Reiji Watanabe , Jing Zhang , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 14, 2022 at 11:41 PM Oliver Upton wrote: > > On Mon, Mar 14, 2022 at 05:30:15PM -0700, Raghavendra Rao Ananta wrote: > > On Mon, Mar 14, 2022 at 12:59 PM Oliver Upton wrote: > > > > > > On Thu, Feb 24, 2022 at 05:25:53PM +0000, Raghavendra Rao Ananta wrote: > > > > Introduce the firmware register to hold the vendor specific > > > > hypervisor service calls (owner value 6) as a bitmap. The > > > > bitmap represents the features that'll be enabled for the > > > > guest, as configured by the user-space. Currently, this > > > > includes support only for Precision Time Protocol (PTP), > > > > represented by bit-0. > > > > > > > > The register is also added to the kvm_arm_vm_scope_fw_regs[] > > > > list as it maintains its state per-VM. > > > > > > > > Signed-off-by: Raghavendra Rao Ananta > > > > --- > > > > arch/arm64/include/asm/kvm_host.h | 2 ++ > > > > arch/arm64/include/uapi/asm/kvm.h | 4 ++++ > > > > arch/arm64/kvm/guest.c | 1 + > > > > arch/arm64/kvm/hypercalls.c | 22 +++++++++++++++++++++- > > > > include/kvm/arm_hypercalls.h | 3 +++ > > > > 5 files changed, 31 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > > > > index 318148b69279..d999456c4604 100644 > > > > --- a/arch/arm64/include/asm/kvm_host.h > > > > +++ b/arch/arm64/include/asm/kvm_host.h > > > > @@ -106,10 +106,12 @@ struct kvm_arch_memory_slot { > > > > * > > > > * @hvc_std_bmap: Bitmap of standard secure service calls > > > > * @hvc_std_hyp_bmap: Bitmap of standard hypervisor service calls > > > > + * @hvc_vendor_hyp_bmap: Bitmap of vendor specific hypervisor service calls > > > > */ > > > > struct kvm_hvc_desc { > > > > u64 hvc_std_bmap; > > > > u64 hvc_std_hyp_bmap; > > > > + u64 hvc_vendor_hyp_bmap; > > > > }; > > > > > > > > struct kvm_arch { > > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > > > > index 9a2caead7359..ed470bde13d8 100644 > > > > --- a/arch/arm64/include/uapi/asm/kvm.h > > > > +++ b/arch/arm64/include/uapi/asm/kvm.h > > > > @@ -299,6 +299,10 @@ struct kvm_arm_copy_mte_tags { > > > > #define KVM_REG_ARM_STD_HYP_BIT_PV_TIME BIT(0) > > > > #define KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX 0 /* Last valid bit */ > > > > > > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP KVM_REG_ARM_FW_BMAP_REG(2) > > > > +#define KVM_REG_ARM_VENDOR_HYP_BIT_PTP BIT(0) > > > > +#define KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX 0 /* Last valid bit */ > > > > + > > > > /* SVE registers */ > > > > #define KVM_REG_ARM64_SVE (0x15 << KVM_REG_ARM_COPROC_SHIFT) > > > > > > > > diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c > > > > index c42426d6137e..fc3656f91aed 100644 > > > > --- a/arch/arm64/kvm/guest.c > > > > +++ b/arch/arm64/kvm/guest.c > > > > @@ -67,6 +67,7 @@ static const u64 kvm_arm_vm_scope_fw_regs[] = { > > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, > > > > KVM_REG_ARM_STD_BMAP, > > > > KVM_REG_ARM_STD_HYP_BMAP, > > > > + KVM_REG_ARM_VENDOR_HYP_BMAP, > > > > }; > > > > > > > > /** > > > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c > > > > index ebc0cc26cf2e..5c5098c8f1f9 100644 > > > > --- a/arch/arm64/kvm/hypercalls.c > > > > +++ b/arch/arm64/kvm/hypercalls.c > > > > @@ -79,6 +79,9 @@ static bool kvm_hvc_call_supported(struct kvm_vcpu *vcpu, u32 func_id) > > > > case ARM_SMCCC_HV_PV_TIME_ST: > > > > return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_std_hyp_bmap, > > > > KVM_REG_ARM_STD_HYP_BIT_PV_TIME); > > > > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID: > > > > + return kvm_arm_fw_reg_feat_enabled(hvc_desc->hvc_vendor_hyp_bmap, > > > > + KVM_REG_ARM_VENDOR_HYP_BIT_PTP); > > > > default: > > > > /* By default, allow the services that aren't listed here */ > > > > return true; > > > > @@ -162,7 +165,14 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu) > > > > break; > > > > case ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID: > > > > val[0] = BIT(ARM_SMCCC_KVM_FUNC_FEATURES); > > > > - val[0] |= BIT(ARM_SMCCC_KVM_FUNC_PTP); > > > > + > > > > + /* > > > > + * The feature bits exposed to user-space doesn't include > > > > + * ARM_SMCCC_KVM_FUNC_FEATURES. However, we expose this to > > > > + * the guest as bit-0. Hence, left-shift the user-space > > > > + * exposed bitmap by 1 to accommodate this. > > > > + */ > > > > + val[0] |= hvc_desc->hvc_vendor_hyp_bmap << 1; > > > > > > Having an off-by-one difference between the userspace and guest > > > representations of this bitmap seems like it could be a source of bugs > > > in the future. Its also impossible for the guest to completely hide the > > > vendor range if it so chooses. > > > > > > Why not tie ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID and > > > ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID to BIT(0)? PTP would then > > > become BIT(1). > > > > > I agree it's a little asymmetrical. But exposing a bit for the > > func_ids that you mentioned means providing a capability to disable > > them by the userspace. This would block the guests from even > > discovering the space. If it's not too ugly, we can maintain certain > > bits to always remain read-only to the user-space. On the other hand, > > we can simply ignore what the userspace configure and simply treat it > > as a userspace bug. What do you think? > > I think that assigning a bit to the aforementioned hypercalls would be > best. If userspace decides to hide all the features enumerated in the > subrange then there isn't much point to the guest knowing that the range > even exists. It shouldn't amount to much for userspace, as it will > likely just keep the default value and only worry about these registers > when migrating. > Sure, I'll include a bit for these as well. Thanks, Raghavenadra > Apologies if I'm being pedantic, but such a subtle implementation detail > could be overlooked in future changes. > > -- > Oliver > > > > > break; > > > > case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID: > > > > kvm_ptp_get_time(vcpu, val); > > > > @@ -188,6 +198,7 @@ static const u64 kvm_arm_fw_reg_ids[] = { > > > > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2, > > > > KVM_REG_ARM_STD_BMAP, > > > > KVM_REG_ARM_STD_HYP_BMAP, > > > > + KVM_REG_ARM_VENDOR_HYP_BMAP, > > > > }; > > > > > > > > void kvm_arm_init_hypercalls(struct kvm *kvm) > > > > @@ -196,6 +207,7 @@ void kvm_arm_init_hypercalls(struct kvm *kvm) > > > > > > > > hvc_desc->hvc_std_bmap = ARM_SMCCC_STD_FEATURES; > > > > hvc_desc->hvc_std_hyp_bmap = ARM_SMCCC_STD_HYP_FEATURES; > > > > + hvc_desc->hvc_vendor_hyp_bmap = ARM_SMCCC_VENDOR_HYP_FEATURES; > > > > } > > > > > > > > int kvm_arm_get_fw_num_regs(struct kvm_vcpu *vcpu) > > > > @@ -285,6 +297,9 @@ int kvm_arm_get_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) > > > > case KVM_REG_ARM_STD_HYP_BMAP: > > > > val = READ_ONCE(hvc_desc->hvc_std_hyp_bmap); > > > > break; > > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP: > > > > + val = READ_ONCE(hvc_desc->hvc_vendor_hyp_bmap); > > > > + break; > > > > default: > > > > return -ENOENT; > > > > } > > > > @@ -311,6 +326,10 @@ static int kvm_arm_set_fw_reg_bmap(struct kvm_vcpu *vcpu, u64 reg_id, u64 val) > > > > fw_reg_bmap = &hvc_desc->hvc_std_hyp_bmap; > > > > fw_reg_features = ARM_SMCCC_STD_HYP_FEATURES; > > > > break; > > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP: > > > > + fw_reg_bmap = &hvc_desc->hvc_vendor_hyp_bmap; > > > > + fw_reg_features = ARM_SMCCC_VENDOR_HYP_FEATURES; > > > > + break; > > > > default: > > > > return -ENOENT; > > > > } > > > > @@ -416,6 +435,7 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg) > > > > return 0; > > > > case KVM_REG_ARM_STD_BMAP: > > > > case KVM_REG_ARM_STD_HYP_BMAP: > > > > + case KVM_REG_ARM_VENDOR_HYP_BMAP: > > > > return kvm_arm_set_fw_reg_bmap(vcpu, reg_id, val); > > > > default: > > > > return -ENOENT; > > > > diff --git a/include/kvm/arm_hypercalls.h b/include/kvm/arm_hypercalls.h > > > > index a1cb6e839c74..91be758ca58e 100644 > > > > --- a/include/kvm/arm_hypercalls.h > > > > +++ b/include/kvm/arm_hypercalls.h > > > > @@ -12,6 +12,9 @@ > > > > #define ARM_SMCCC_STD_HYP_FEATURES \ > > > > GENMASK_ULL(KVM_REG_ARM_STD_HYP_BMAP_BIT_MAX, 0) > > > > > > > > +#define ARM_SMCCC_VENDOR_HYP_FEATURES \ > > > > + GENMASK_ULL(KVM_REG_ARM_VENDOR_HYP_BMAP_BIT_MAX, 0) > > > > + > > > > int kvm_hvc_call_handler(struct kvm_vcpu *vcpu); > > > > > > > > static inline u32 smccc_get_function(struct kvm_vcpu *vcpu) > > > > -- > > > > 2.35.1.473.g83b2b277ed-goog > > > >