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 4465DC433F5 for ; Tue, 3 May 2022 17:15:41 +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=D6ZR4lSrUesDKqdp1Bc5haKyQXqC6bvvwOmCrNHZSC4=; b=Z6e3LngvhYq/ih 58xHkSRP3BgA3hMqmeq04fGd0ATLlm1BBSkTGoZ6yuCT9FLMgbupVFVRZbx3efK+VhpnmkLDJeeOV XJo/LM6xuMDidxrBRyrIcOuEL7OP+J7gF6NPuLv3xIASm6rqAhFB7kGS/nLCLoIh4/9oAUSop1YoU kk26mTINVFHxa5nEeWVKYA02TEEfJ2uOqmIWB5q/vr5Ln3qq7NnV2EdD0R11t6ulCPXRpATWi4IS2 WLtSRM4XZI+I7gEK54CfebsUBZ8cTO/1hqQOA0L8Vf3RLon8z3gMdsypZkMy4NZ/RpApHBFw3mimu 9aDd2BBmSk+DFW9k5DSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nlw6P-006xdz-BI; Tue, 03 May 2022 17:14:21 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nlw6G-006xa3-SE for linux-arm-kernel@lists.infradead.org; Tue, 03 May 2022 17:14:15 +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 4BF35B81D9A; Tue, 3 May 2022 17:14:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE9B8C385A9; Tue, 3 May 2022 17:14:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651598049; bh=AplqjMJygV5N2GJ3+bH6/snyHg1GxYj0Pi04o+s5Et0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Hi6mCfouyVmjZxSVbORS/GhkRPnI8onFUPKaZL32RKjhslEyhjFCcgfoHKxl3MFD2 mp0RhJ/mF5wujJ+csCdONmvxh/iqPpooUX+SqLoMtumsgGEMUxsKDYu98tdyzxgBAy NitGG9dXGgMCuq61CfZaA3pbu0G6Gx6hB5Z6SnIJtDnE/o6YzJrzTunYhIRdZieTTy a1A+R9HMMO5jTOeiDYLmWEOSamfz1rm/PZRd19SrejUhKGJY42IIWuV2fHVXV83LUP 2HbvLHn/rN/rrGo6gwV8mwrAaG+pj4VUPcc9E8aWlVLfsT/BggH0NLG8kyLm8Sj6CX on/ZMB7FSaQPw== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nlw6A-008hld-7y; Tue, 03 May 2022 18:14:06 +0100 Date: Tue, 03 May 2022 18:14:06 +0100 Message-ID: <87a6by8roh.wl-maz@kernel.org> From: Marc Zyngier To: Raghavendra Rao Ananta Cc: Andrew Jones , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Catalin Marinas , Will Deacon , Peter Shier , Ricardo Koller , Oliver Upton , Reiji Watanabe , Jing Zhang , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Gavin Shan Subject: Re: [PATCH v7 6/9] Docs: KVM: Add doc for the bitmap firmware registers In-Reply-To: <20220502233853.1233742-7-rananta@google.com> References: <20220502233853.1233742-1-rananta@google.com> <20220502233853.1233742-7-rananta@google.com> 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: rananta@google.com, drjones@redhat.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, pbonzini@redhat.com, catalin.marinas@arm.com, will@kernel.org, pshier@google.com, ricarkol@google.com, oupton@google.com, reijiw@google.com, jingzhangos@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, gshan@redhat.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-20220503_101413_804778_D5A2E498 X-CRM114-Status: GOOD ( 43.39 ) 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 Tue, 03 May 2022 00:38:50 +0100, Raghavendra Rao Ananta wrote: > > Add the documentation for the bitmap firmware registers in > hypercalls.rst and api.rst. This includes the details for > KVM_REG_ARM_STD_BMAP, KVM_REG_ARM_STD_HYP_BMAP, and > KVM_REG_ARM_VENDOR_HYP_BMAP registers. > > Since the document is growing to carry other hypercall related > information, make necessary adjustments to present the document > in a generic sense, rather than being PSCI focused. > > Signed-off-by: Raghavendra Rao Ananta > Reviewed-by: Gavin Shan > --- > Documentation/virt/kvm/api.rst | 16 ++++ > Documentation/virt/kvm/arm/hypercalls.rst | 94 ++++++++++++++++++----- > 2 files changed, 92 insertions(+), 18 deletions(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 4a900cdbc62e..8ae638be79fd 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -2542,6 +2542,22 @@ arm64 firmware pseudo-registers have the following bit pattern:: > > 0x6030 0000 0014 > > +arm64 bitmap feature firmware pseudo-registers have the following bit pattern:: > + > + 0x6030 0000 0016 > + > +The bitmap feature firmware registers exposes the hypercall services that are > +available for userspace to configure. The set bits corresponds to the services > +that are available for the guests to access. By default, KVM sets all the > +supported bits during VM initialization. The userspace can discover the > +available services via KVM_GET_ONE_REG, and write back the bitmap corresponding > +to the features that it wishes guests to see via KVM_SET_ONE_REG. > + > +Note: These registers are immutable once any of the vCPUs of the VM has run at > +least once. A KVM_SET_ONE_REG in such a scenario will return a -EBUSY to userspace. > + The placement is odd, as SVE uses ID 0x0015, and is *after* this. > +(See Documentation/virt/kvm/arm/hypercalls.rst for more details.) > + > arm64 SVE registers have the following bit patterns:: > > 0x6080 0000 0015 00 Zn bits[2048*slice + 2047 : 2048*slice] > diff --git a/Documentation/virt/kvm/arm/hypercalls.rst b/Documentation/virt/kvm/arm/hypercalls.rst > index d52c2e83b5b8..383ca766cf36 100644 > --- a/Documentation/virt/kvm/arm/hypercalls.rst > +++ b/Documentation/virt/kvm/arm/hypercalls.rst > @@ -1,32 +1,32 @@ > .. SPDX-License-Identifier: GPL-2.0 > > -========================================= > -Power State Coordination Interface (PSCI) > -========================================= > +======================= > +ARM Hypercall Interface > +======================= > > -KVM implements the PSCI (Power State Coordination Interface) > -specification in order to provide services such as CPU on/off, reset > -and power-off to the guest. > +KVM handles the hypercall services as requested by the guests. New hypercall > +services are regularly made available by the ARM specification or by KVM (as > +vendor services) if they make sense from a virtualization point of view. > > -The PSCI specification is regularly updated to provide new features, > -and KVM implements these updates if they make sense from a virtualization > -point of view. > - > -This means that a guest booted on two different versions of KVM can > -observe two different "firmware" revisions. This could cause issues if > -a given guest is tied to a particular PSCI revision (unlikely), or if > -a migration causes a different PSCI version to be exposed out of the > -blue to an unsuspecting guest. > +This means that a guest booted on two different versions of KVM can observe > +two different "firmware" revisions. This could cause issues if a given guest > +is tied to a particular version of a hypercall service, or if a migration > +causes a different version to be exposed out of the blue to an unsuspecting > +guest. > > In order to remedy this situation, KVM exposes a set of "firmware > pseudo-registers" that can be manipulated using the GET/SET_ONE_REG > interface. These registers can be saved/restored by userspace, and set > -to a convenient value if required. > +to a convenient value as required. > > -The following register is defined: > +The following registers are defined: > > * KVM_REG_ARM_PSCI_VERSION: > > + KVM implements the PSCI (Power State Coordination Interface) > + specification in order to provide services such as CPU on/off, reset > + and power-off to the guest. > + > - Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set > (and thus has already been initialized) > - Returns the current PSCI version on GET_ONE_REG (defaulting to the > @@ -74,4 +74,62 @@ The following register is defined: > KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED: > The workaround is always active on this vCPU or it is not needed. > > -.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf > + > +Bitmap Feature Firmware Registers > +--------------------------------- > + > +Contrary to the above registers, the following registers exposes the hypercall > +services in the form of a feature-bitmap to the userspace. This bitmap is > +translated to the services that are available to the guest. There is a register > +defined per service call owner and can be accessed via GET/SET_ONE_REG interface. > + > +By default, these registers are set with the upper limit of the features that > +are supported. This way userspace can discover all the electable hypercall services > +via GET_ONE_REG. The user-space can write-back the desired bitmap back via > +SET_ONE_REG. The features for the registers that are untouched, probably because > +userspace isn't aware of them, will be exposed as is to the guest. > + > +Note that KVM would't allow the userspace to configure the registers anymore once > +any of the vCPUs has run at least once. Instead, it will return a -EBUSY. > + Formatting is a bit off. We try to stay within the 80 cols format for text documents such as this. > +The psuedo-firmware bitmap register are as follows: Typo. > + > +* KVM_REG_ARM_STD_BMAP: > + Controls the bitmap of the ARM Standard Secure Service Calls. > + > + The following bits are accepted: > + > + Bit-0: KVM_REG_ARM_STD_BIT_TRNG_V1_0: > + The bit represents the services offered under v1.0 of ARM True Random > + Number Generator (TRNG) specification, ARM DEN0098. > + > +* KVM_REG_ARM_STD_HYP_BMAP: > + Controls the bitmap of the ARM Standard Hypervisor Service Calls. > + > + The following bits are accepted: > + > + Bit-0: KVM_REG_ARM_STD_HYP_BIT_PV_TIME: > + The bit represents the Paravirtualized Time service as represented by > + ARM DEN0057A. > + > +* KVM_REG_ARM_VENDOR_HYP_BMAP: > + Controls the bitmap of the Vendor specific Hypervisor Service Calls. > + > + The following bits are accepted: > + > + Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT > + The bit represents the ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID > + and ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID function-ids. > + > + Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP: > + The bit represents the Precision Time Protocol KVM service. > + > +Errors: > + > + ======= ============================================================= > + -ENOENT Unknown register accessed. > + -EBUSY Attempt a 'write' to the register after the VM has started. > + -EINVAL Invalid bitmap written to the register. > + ======= ============================================================= > + > +.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf > \ No newline at end of file > -- > 2.36.0.464.gb9c8b46e94-goog > > Thanks, 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