Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp4199761pxp; Tue, 15 Mar 2022 15:06:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+evHZdmZlkUSUhddGuKNz2TtuNCa0sfbRdLYl4TcjHsTgE0maVHruHZcHFozoi+v5BuDt X-Received: by 2002:a05:6402:18:b0:410:86cd:9dce with SMTP id d24-20020a056402001800b0041086cd9dcemr26674768edu.70.1647382010230; Tue, 15 Mar 2022 15:06:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647382010; cv=none; d=google.com; s=arc-20160816; b=m9XIXkR1MXyrxUJycIfKM+si8Qh/sSwe9wW/x2F2IEEmR8ZKT5at+xepaxRPSRxoMv jXAGAg/iH2Q1/q7slwWc3ED88SF8zBI/9xduIil25Qf5QV62x6h8aLVdML5QjfeTcXzZ dwj42kTrDmb/zTE4toRxVx4JNVe3nWi1TTYRivL5FjmmO359SEynWa5nxMCi53feGs0D unINvTfXfieSAiCm452D4dyZpZRvbQr20P7PZB2Zg247JlQqVfJeYxXLeG00MzbnOclY q6fVgWnEXBEcBMcq+XCtiLcxfqkqrjNYkCjGoPHyFVTNkJiNmfSsr4zcoCPqXGubC/Cx Vw6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=praixL3ItJFtmdPKsgH4n7ORPNUpESQrK/7qrWdA+ho=; b=ct6w1jLJor6TsAMoZ0FpVVtEORX54ZXtMIfnSq5cwbYflwYp0Z0a3I8LjxFf3jRMN9 87dVXHlA4CQpPaLyeMF5ZPMR7kqtrWfTRqm3HGz1jLAMTwSVFdUMnagay/rw9QUlp0G4 C9gc8PYJcMTngSwcIASrBaTPXJiEyYmDIyKcAlin0vidZ9F+BBY6TlI9/3Zj384AB0La 15YETjS5i0gwflA72ew3SdWNNMPqqx2CyEs8dTLgaar0+zERcdiUIcGt1QI0Uae4gT6V VfCP3gnd+4XMel/gfeW6L5DCsH3D5Y7vuTFCm+lRjETeJcm7X25L9YtJFaMV+Jn8D01f Rj4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="lEQAc/v0"; 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 u11-20020a170906b10b00b006ce058f6962si151196ejy.109.2022.03.15.15.05.59; Tue, 15 Mar 2022 15:06:50 -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="lEQAc/v0"; 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 S1345255AbiCOGm2 (ORCPT + 99 others); Tue, 15 Mar 2022 02:42:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345254AbiCOGmX (ORCPT ); Tue, 15 Mar 2022 02:42:23 -0400 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C67DD2DAA3 for ; Mon, 14 Mar 2022 23:41:11 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id r2so21044154iod.9 for ; Mon, 14 Mar 2022 23:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=praixL3ItJFtmdPKsgH4n7ORPNUpESQrK/7qrWdA+ho=; b=lEQAc/v08E6AwDhWfulfFcNd8tzucwEf+jG16hcoA9W0P9Yw+MZltz9DofyETCVm/t hTusPZF1sMRONhVj84b92IVJxWhnmdSKEym1WAyDLf2JlToU0P4FctfCukxQZQX5Bdvn KuCo29jjofjNYDl7S0ixHNG7GqB360TwbpUeXxNxg2vafj/46jDZELTFMVY9zJISF7/G XYzbaFDuTo7XjmF00UuV6e1AgOw3PlLDfCecVgoeDg2t2ncH8wO4De/t8iVDVJMcNEVU 52pT8D7r+ENGrrRxDQII83GWsg9zfp9+RwwxCJOtA6zn7WEOdsoGOutoP+/2Gx1aGwPR 5cmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=praixL3ItJFtmdPKsgH4n7ORPNUpESQrK/7qrWdA+ho=; b=QtrMLEigftN4Kr/Svlui8ECuyABquSw8ahOzFW00+FK6na9yxN4W/zfhHxV+eHkapq Uokk/Sj8tVao6YOu8WUIClZVfFGjHKGm6IzXvqEszyqitt3ncEmcb9aKHpIZUoM3OwIN HwqQV8yR4kHuN2GNEiUPxxO229dXoc1qOyg/JwzVYxO02gl2rT+guPFfhtM4Qn6CPhvU rYKo21E7HSGdp9g7q3+vytQyPfpNfxCEn/72/4SRooK5wskyC043PebhmPO/A1vE/EFE ga/XWSgK2u9NLm/wi9KE/4HcLOGWyi3O5eW9+uZ5xof8S1ZsCeWpjXnu8GHCBY2jfBSh KI6A== X-Gm-Message-State: AOAM532gPUGRWWK8E46hTdPxC8uA7CKOZgx4GC7np1UUc85cMoy1SR7s SNtowoxWyhJaCWSefAvt7Lz1RA== X-Received: by 2002:a05:6638:a2f:b0:314:b8b9:1c21 with SMTP id 15-20020a0566380a2f00b00314b8b91c21mr22666749jao.22.1647326470893; Mon, 14 Mar 2022 23:41:10 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id a13-20020a056e020e0d00b002c61ec2817fsm10053865ilk.57.2022.03.14.23.41.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Mar 2022 23:41:10 -0700 (PDT) Date: Tue, 15 Mar 2022 06:41:07 +0000 From: Oliver Upton To: Raghavendra Rao Ananta 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 Subject: Re: [PATCH v4 07/13] KVM: arm64: Add vendor hypervisor firmware register Message-ID: References: <20220224172559.4170192-1-rananta@google.com> <20220224172559.4170192-8-rananta@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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=unavailable 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 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. 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 > > >