Re: [PATCH 09/37] arm64: kvm: Use cpus_have_final_cap() explicitly

From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
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
Date: Thu, 21 Sep 2023 08:49:46 +0100	[thread overview]
Message-ID: <8734z83qzp.wl-maz@kernel.org> (raw)
In-Reply-To: <20230919092850.1940729-10-mark.rutland@arm.com>

On Tue, 19 Sep 2023 10:28:22 +0100,
Mark Rutland <mark.rutland@arm.com> 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 <maz@kernel.org>

	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