Re: [PATCH] KVM: arm64: Enforce dependency on an ARMv8.4-aware toolchain

On Wed, 07 Aug 2024 13:03:28 +0100,
Arnd Bergmann [off-list ref] wrote:

On Wed, 7 Aug 2024 at 13:51, Marc Zyngier [off-list ref] wrote:

quoted

With the NV support of TLBI-range operations, KVM makes use of
instructions that are only supported by binutils versions >= 2.30.

This breaks the build for very old toolchains.

Make KVM support conditional on having ARMv8.4 support in the
assembler, side-stepping the issue.

Fixes: 5d476ca57d7d ("KVM: arm64: nv: Add handling of range-based TLBI operations")
Reported-by: Viresh Kumar <viresh.kumar@linaro.org>
Suggested-by: Arnd Bergmann <redacted>
Signed-off-by: Marc Zyngier <maz@kernel.org>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks for that.

quoted

 menuconfig KVM
        bool "Kernel-based Virtual Machine (KVM) support"
+       depends on AS_HAS_ARMV8_4
        select KVM_COMMON
        select KVM_GENERIC_HARDWARE_ENABLING
        select KVM_GENERIC_MMU_NOTIFIER

I think this is good enough here, only slightly more limiting than
we strictly need. A slightly more fine-grained approach would
turn off VHE mode on old binutils but keep NVHE. That is still
inaccurate of course since VHE only depends on v8.2, so
I'm in favor of keeping the version you posted.

nit: VHE is from ARMv8.1, though there isn't a large number of v8.1
implementations (Cavium/Broadcom TX2 is the best known one).

Now, splitting VHE out would be pretty invasive. A marginally better
approach would be to disable NV support for TLBI range instructions
and make them UNDEF in the guest.

But overall, I really hate the idea of playing a "dice and slice" game
with KVM, just because the toolchain is from a time when I could still
have long hair. It leads to all sort of issues with latent bugs that
only show-up in some configs (cue the repeated issues with PMU
emulation, which has generally been a disaster). I would only consider
this if someone came up with a valid reason why they cannot move to a
toolchain that has newer binutils (like the ones you provide on k.org).

For reference, even the gcc-5.5 toolchain I built for kernel.org
in 2019 came with recent enough binutils, and we are likely to
soon require gcc-8 or higher anyway.

Definitely looking forward to this!

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.