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

[Marc Zyngier <maz@kernel.org>]

On Wed, 07 Aug 2024 13:03:28 +0100,
Arnd Bergmann <arnd@linaro.org> wrote:
> 
> On Wed, 7 Aug 2024 at 13:51, Marc Zyngier <maz@kernel.org> wrote:
> >
> > 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 <arnd@linaro.org>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks for that.

> 
> >  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.