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 967B1CD5BD5 for ; Thu, 21 Sep 2023 07:50:32 +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=fuslxn+xUFCViLhTEuJ3co7+eXLWkEAgyLa2Q0hznFM=; b=sfuld8kTd7XRBZ cThSrbVYdwQBZQHw4/l12aeHEmxkreuCRukvJVuFJ6GYNfZEw9O/WnOZAz4Rurq1XVX6a54RUeo2r GcNMSjmMEDxxlQUzWsfwzkwU/Cc+INV3P7np1GfPxkMOIprffNtxiWrfQcEqw5M4OnIlSm2Md4mN+ /ctHJpIPIgOxGVBCMuBD86kqDCDp/qdIb1ull9b0IbUqCwmsPY6bwzEEzvpdBvQnTi2i6H9A0CDqr BhhqPrcdg+aDxs0t6zpJOCLIscSx16mh5bVuhVkad9ehJDYmtkfdA4O6dgWaSpd/vjwq2Hz7uzMBj 6/Azz0ZSuFEIWo2aH8gg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qjERk-005P0h-2z; Thu, 21 Sep 2023 07:50:00 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qjERh-005Ozt-2I for linux-arm-kernel@lists.infradead.org; Thu, 21 Sep 2023 07:49:59 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 509F9B81F9A; Thu, 21 Sep 2023 07:49:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D78AEC4166B; Thu, 21 Sep 2023 07:49:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695282594; bh=Zifq/Zah/uEyf37YqHDhLwP3Om2B7UVf+U3E50gFrdE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TPJdiXoaNYpzqtp+N30qOUSvPItOa8Uz4Va263MWpUCgbgygtm+A5ii+tqP6Ioe2v qjsNCm5lDZAhO1kH18gR8VgDLiJ1IIj9f45uH2wUlcZ4SmSCAP3pIJlzuUA0x3BTIS VC/5pxqXfdHJRwj+C1zsvHIwPm742GMrc8Ku18h1XsxMewV+N6VtL5feItzKNdMSpF 9im8oRfA5alBAr6i2tgXp5qvDAIyA8iGUrjly25pVZCrx9dkjytnvKYu5X25kNH4Wu hLCJr1ov6NkrnuM343xMLpQclo1Tnf8q+qvl+I4A7WeKwRhs0ZRHnr6laSuesTWfko ptaAVuwBdAuUw== Received: from 82-132-232-12.dab.02.net ([82.132.232.12] 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 1qjERb-00Es9C-Lv; Thu, 21 Sep 2023 08:49:52 +0100 Date: Thu, 21 Sep 2023 08:49:46 +0100 Message-ID: <8734z83qzp.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, ardb@kernel.org, bertrand.marquis@arm.com, boris.ostrovsky@oracle.com, broonie@kernel.org, catalin.marinas@arm.com, daniel.lezcano@linaro.org, james.morse@arm.com, jgross@suse.com, oliver.upton@linux.dev, pcc@google.com, sstabellini@kernel.org, suzuki.poulose@arm.com, tglx@linutronix.de, vladimir.murzin@arm.com, will@kernel.org Subject: Re: [PATCH 09/37] arm64: kvm: Use cpus_have_final_cap() explicitly In-Reply-To: <20230919092850.1940729-10-mark.rutland@arm.com> References: <20230919092850.1940729-1-mark.rutland@arm.com> <20230919092850.1940729-10-mark.rutland@arm.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/28.2 (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: 82.132.232.12 X-SA-Exim-Rcpt-To: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, ardb@kernel.org, bertrand.marquis@arm.com, boris.ostrovsky@oracle.com, broonie@kernel.org, catalin.marinas@arm.com, daniel.lezcano@linaro.org, james.morse@arm.com, jgross@suse.com, oliver.upton@linux.dev, pcc@google.com, sstabellini@kernel.org, suzuki.poulose@arm.com, tglx@linutronix.de, vladimir.murzin@arm.com, will@kernel.org 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-20230921_004958_023249_A16278D6 X-CRM114-Status: GOOD ( 29.04 ) 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, 19 Sep 2023 10:28:22 +0100, Mark Rutland wrote: > > Much of the arm64 KVM code uses cpus_have_const_cap() to check for > cpucaps, but this is unnecessary and it would be preferable to use > cpus_have_final_cap(). > > For historical reasons, cpus_have_const_cap() is more complicated than > it needs to be. Before cpucaps are finalized, it will perform a bitmap > test of the system_cpucaps bitmap, and once cpucaps are finalized it > will use an alternative branch. This used to be necessary to handle some > race conditions in the window between cpucap detection and the > subsequent patching of alternatives and static branches, where different > branches could be out-of-sync with one another (or w.r.t. alternative > sequences). Now that we use alternative branches instead of static > branches, these are all patched atomically w.r.t. one another, and there > are only a handful of cases that need special care in the window between > cpucap detection and alternative patching. > > Due to the above, it would be nice to remove cpus_have_const_cap(), and > migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(), > or cpus_have_cap() depending on when their requirements. This will > remove redundant instructions and improve code generation, and will make > it easier to determine how each callsite will behave before, during, and > after alternative patching. > > KVM is initialized after cpucaps have been finalized and alternatives > have been patched. Since commit: > > d86de40decaa14e6 ("arm64: cpufeature: upgrade hyp caps to final") > > ... use of cpus_have_const_cap() in hyp code is automatically converted > to use cpus_have_final_cap(): > > | static __always_inline bool cpus_have_const_cap(int num) > | { > | if (is_hyp_code()) > | return cpus_have_final_cap(num); > | else if (system_capabilities_finalized()) > | return __cpus_have_const_cap(num); > | else > | return cpus_have_cap(num); > | } > > Thus, converting hyp code to use cpus_have_final_cap() directly will not > result in any functional change. > > Non-hyp KVM code is also not executed until cpucaps have been finalized, > and it would be preferable to extent the same treatment to this code and > use cpus_have_final_cap() directly. > > This patch converts instances of cpus_have_const_cap() in KVM-only code > over to cpus_have_final_cap(). As all of this code runs after cpucaps > have been finalized, there should be no functional change as a result of > this patch, but the redundant instructions generated by > cpus_have_const_cap() will be removed from the non-hyp KVM code. Reviewed-by: Marc Zyngier 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