From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 554692206B3 for ; Thu, 19 Dec 2024 09:51:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734601889; cv=none; b=bdx98B/kB44t/1Bs16sUwaF/8s36EcueOIDvX6u/lENrqwOFMqGAiZlJVqESfyJ/QjLDCnzB7BH1JQCcHQTYOkbcAx/P6cbaSeNdxl9aN3SNWnetBxSb2El4Vs/eCFkefyf35ryoAFxPMBkI9+9U9o3W1vfMKdDW/YAE2wBVFTY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734601889; c=relaxed/simple; bh=BeFB9iTgD5uBQm5O0ged2kFhbP2RZiy0d9iadpufIr4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=WWDVuiebPjdNFY35mS3sRLsBFjm7e8ez6Z10mWbymeR5u3trScZF5Pvk0cpvl2K9vLMvT0Z/nmeWEpGWuof5qzqfK31UEZqn/+J1ORMNLMe0ivV+kb5Dq4D1MS+L4cy9uUj0QbkfCiKVdTuD0nXl5ncOLuwtwaU4rSBnEvjS7hE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z6Gd1w9b; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z6Gd1w9b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD4BEC4CECE; Thu, 19 Dec 2024 09:51:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734601886; bh=BeFB9iTgD5uBQm5O0ged2kFhbP2RZiy0d9iadpufIr4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Z6Gd1w9b7uUXuD7pLLMO5cfMf+t46yPo9H0chPClAoSUAPCAR1NaLHZDzpkjnrXIt UDZ8afT5eYWlcqwh6xGbRgSWeAk8FhQNl2wzVqsrlm+ijeEUyU8tRlOzk1k5g5qh6e snOt59JOKOVq2z+Z9xHRN3j3eN4XQT1UaiWZxIs63A0fOxjskG/aqvWcNlpgCCH0ii 9KUqSuLOT3YNR/5LoPZgJKIBV4A7Xw/kjvcYNuJb245ImQfsnbRbzQpFQbVITrntys cCDnfWU51HQhsTGa3HGAG9AZZN8oyLgfGF0jVyCi3/ls5Me6iBBCgkgxAP1wst2HPU U232AG+t2Jy8A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1tODBk-005E8A-GP; Thu, 19 Dec 2024 09:51:24 +0000 Date: Thu, 19 Dec 2024 09:51:23 +0000 Message-ID: <86cyhoq9us.wl-maz@kernel.org> From: Marc Zyngier To: Shameer Kolothum Cc: , , , , , , , , , , , , , , Subject: Re: [PATCH v4 2/3] KVM: arm64: Introduce hypercall support for retrieving target implementations In-Reply-To: <20241218105345.73472-3-shameerali.kolothum.thodi@huawei.com> References: <20241218105345.73472-1-shameerali.kolothum.thodi@huawei.com> <20241218105345.73472-3-shameerali.kolothum.thodi@huawei.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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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.219.108.64 X-SA-Exim-Rcpt-To: shameerali.kolothum.thodi@huawei.com, kvmarm@lists.linux.dev, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, cohuck@redhat.com, eric.auger@redhat.com, sebott@redhat.com, yuzenghui@huawei.com, wangzhou1@hisilicon.com, jiangkunkun@huawei.com, jonathan.cameron@huawei.com, anthony.jebson@huawei.com, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hi Shameer, On Wed, 18 Dec 2024 10:53:44 +0000, Shameer Kolothum wrote: > > If the Guest requires migration to multiple targets, this hypercall > will provide a way to retrieve the target CPU implementations from > the user space VMM. > > Subsequent patch will use this to enable the associated errata. > > Suggested-by: Oliver Upton > Reviewed-by: Sebastian Ott > Signed-off-by: Shameer Kolothum > --- > Documentation/virt/kvm/arm/hypercalls.rst | 30 +++++++++++++++++++++++ > include/linux/arm-smccc.h | 7 ++++++ > 2 files changed, 37 insertions(+) > > diff --git a/Documentation/virt/kvm/arm/hypercalls.rst b/Documentation/virt/kvm/arm/hypercalls.rst > index af7bc2c2e0cb..16b4c02cf9d9 100644 > --- a/Documentation/virt/kvm/arm/hypercalls.rst > +++ b/Documentation/virt/kvm/arm/hypercalls.rst > @@ -142,3 +142,33 @@ region is equal to the memory protection granule advertised by > | | | +---------------------------------------------+ > | | | | ``INVALID_PARAMETER (-3)`` | > +---------------------+----------+----+---------------------------------------------+ > + > +``ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_CPUS_FUNC_ID`` > +------------------------------------------------------- > + > +Request the target CPU implementation information for the Guest VM. This hypercall > +must be handled by the userspace VMM. The Guest kernel will use this information to > +enable the associated errata. A maximum of 64 implementations is supported. In the interest of being able to support this long term, I really think there should be a separate function returning: - the version of the extension, modelled after the PSCI versioning - how many different implementations the extension supports This would avoid hardcoding this 'maximum of 64 implementations' in the spec, and allow us to add new ID registers if they are added in the future. > + > ++---------------------+-------------------------------------------------------------+ > +| Presence: | Optional; KVM/ARM64 Guests only | > ++---------------------+-------------------------------------------------------------+ > +| Calling convention: | HVC64 | > ++---------------------+----------+--------------------------------------------------+ > +| Function ID: | (uint32) | 0xC600007E | > ++---------------------+----------+----+---------------------------------------------+ > +| Arguments: | (uint64) | R1 | selected implementation index | > +| +----------+----+---------------------------------------------+ > +| | (uint64) | R2 | Reserved / Must be zero | > +| +----------+----+---------------------------------------------+ > +| | (uint64) | R3 | Reserved / Must be zero | > ++---------------------+----------+----+---------------------------------------------+ > +| Return Values: | (int64) | R0 | -1 on error else the maximum required CPU | > +| | | | implementation index. | With the above introduced, this can be simplified to always return "SUCCESS (0)" or "INVALID_PARAMETERS (-3)". Please use the SMCCC names to describe standard return values (see section 7.1 in the spec). > +| +----------+----+---------------------------------------------+ > +| | (uint64) | R1 | MIDR_EL1 of the selected implementation | > +| +----------+----+---------------------------------------------+ > +| | (uint64) | R2 | REVIDR_EL1 of the selected implementation | > +| +----------+----+---------------------------------------------+ > +| | (uint64) | R3 | Reserved / Must be zero | > ++---------------------+----------+----+---------------------------------------------+ This is missing AIDR_EL1. Although Linux never had to use it, its purpose is to describe additional implementation details that we may find relevant in the future. > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h > index 67f6fdf2e7cd..6c080fa9d345 100644 > --- a/include/linux/arm-smccc.h > +++ b/include/linux/arm-smccc.h > @@ -179,6 +179,7 @@ > #define ARM_SMCCC_KVM_FUNC_PKVM_RESV_62 62 > #define ARM_SMCCC_KVM_FUNC_PKVM_RESV_63 63 > /* End of pKVM hypercall range */ > +#define ARM_SMCCC_KVM_FUNC_DISCOVER_IMPL_CPUS 126 No need to stay at the back of the room, you can happily take slot 64! > #define ARM_SMCCC_KVM_FUNC_FEATURES_2 127 > #define ARM_SMCCC_KVM_NUM_FUNCS 128 > > @@ -225,6 +226,12 @@ > ARM_SMCCC_OWNER_VENDOR_HYP, \ > ARM_SMCCC_KVM_FUNC_MMIO_GUARD) > > +#define ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_CPUS_FUNC_ID \ > + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ > + ARM_SMCCC_SMC_64, \ > + ARM_SMCCC_OWNER_VENDOR_HYP, \ > + ARM_SMCCC_KVM_FUNC_DISCOVER_IMPL_CPUS) > + > /* ptp_kvm counter type ID */ > #define KVM_PTP_VIRT_COUNTER 0 > #define KVM_PTP_PHYS_COUNTER 1 Thanks, M. -- Without deviation from the norm, progress is not possible.