[PATCH v3 3/3] arm64: Get rid of CONFIG_ARM64_VHE

[Marc Zyngier]

On Thu, 08 Apr 2021 22:47:38 +0100,
Arnd Bergmann <arnd at kernel.org> wrote:
> 
> On Thu, Apr 8, 2021 at 3:10 PM Marc Zyngier <maz at kernel.org> wrote:
> >
> > CONFIG_ARM64_VHE was introduced with ARMv8.1 (some 7 years ago),
> > and has been enabled by default for almost all that time.
> >
> > Given that newer systems that are VHE capable are finally becoming
> > available, and that some systems are even incapable of not running VHE,
> > drop the configuration altogether.
> >
> > Anyone willing to stick to non-VHE on VHE hardware for obscure
> > reasons should use the 'kvm-arm.mode=nvhe' command-line option.
> 
> Have you considered adding options to do the reverse logic for this
> and other features, such as making support for the old non-VHE
> optional at compile time?

This nVHE code is exclusively limited to KVM, because the whole point
of VHE is that the EL1 kernel can run at EL2 completely unchanged.
Furthermore, nVHE has properties that VHE cannot deliver, such as
memory isolation between host and guests.

So no, I wouldn't consider make it optional at compile time. Instead,
I would consider jettisoning the nVHE EL2 code after init to save a
handful of pages when running on a VHE-capable system in VHE mode.

> 
> I understand that so far the rule is (almost) always that an arm64 kernel
> should run on any Armv8.0-A or higher system regardless of configuration,
> but the now announced Armv9.0-A definition might be the chance to
> introduce the concept of a minimum level the way we do on other
> architectures (e.g. armv6/v6k/v7 or k8/pentium4/core2/atom/generic).
>
> The way I can see this working would be to have a single user-visible
> option that controls whether the kernel supports only Armv9.0-A/Armv8.5-A
> and assumes all mandatory features of that are present, or it remains
> as before and supports all implementations back to the first v8.

The view that v8.5/v9 is a monolithic setup with a set of mandatory
option is unfortunately disconnected from reality. Reality is that an
implementer picks and chooses whatever feature set they want
irrespective of what the architecture says, and the architecture
revision is nothing but an index into the documentation.

Features that were mandatory often become optional, and/or are further
made unimplementable due to some other extension of the architecture.
We also have the extremely common case where a feature that is usable
on a host isn't virtualisable, meaning that the kernel gets exposed
different feature sets depending on whether it runs bare-metal or not,
which puts another nail on the "per-revision feature set" coffin.

The ARM architecture is effectively a mix-and-match system, where you
choose the feature set you want for a single vertically integrated
application, and not a nice linear progression of features that land
in bulk.

> This would help eliminate the runtime detection for not just VHE but
> also LSE, LPA, PAN, etc. Not sure how significant the cost of any of
> those are in terms of runtime performance and/or code size, but it
> would feel nice to be able to build a kernel that can actually rely
> on sane hardware features even if it will take a few more years before
> that hardware becomes common enough to actually get some distros
> ship a kernel that requires v8.5/v9.0.

We went there with 32bit because we were forced to: different ISAs,
different page table formats. I would rather keep a single kernel
until we get to that point of divergence *or* that we can demonstrate
such a significant performance/maintenance improvement that it'd be
silly not to do it.

The published architecture does not hint at such changes yet, nor has
performance overhead been reported due to "feature bloat". The current
feature discovery and runtime patching seems adequate and saves us
from the bitrot effect that multiple configurations inevitably would
trigger.

So at the moment, I am strongly in favor of keeping the current
"single kernel" approach, and even drop more of the existing
configuration symbols (though some have ugly toolchain constraints).

Thanks,

	M.

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