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