Thread (59 messages) 59 messages, 6 authors, 13d ago

Re: [PATCH v7 23/23] KVM: s390: arm64: Add KVM_S390_ARM64 Kconfig and Makefile

From: Christian Borntraeger <borntraeger@linux.ibm.com>
Date: 2026-09-17 11:08:34
Also in: kvm, kvmarm, linux-s390, lkml


Am 03.09.26 um 18:33 schrieb Sean Christopherson:
On Thu, Sep 03, 2026, Steffen Eiden wrote:
quoted
On Thu, Sep 03, 2026 at 07:43:58AM -0700, Sean Christopherson wrote:
quoted
And FWIW, while it might seem daunting, from my perspective it's not actually that
much churn to do things "right".  Provide KVM_S390_NATIVE, and then have KVM reflect
the "weakest" of S390_NATIVE vs. S390_ARCH.  I.e. make KVM=m if either of the "real"
KVMs will be a module.  That requires some creative shenanigans, but it's not hard,
just weird.
FYI the first versions of this series had a 3 configs approach very
similar to yours.

IIRC it was not so much the churn we have in (upstream) kernel code but
more on the distro side and to everyone building the kernel in their
favourite architecture (s390 :))
How many people are running distro kernels on s390 hardware?  And how many distros
actually change the default KVM settings, e.g. to build KVM as a module instead of
baking it into the kernel?  My guess is "not many" and "almost none", i.e. the
actual impact on downstream users is likely miniscule.
quoted
Suddenly the KVM config changed its behaviour (effectively becoming a noop)
Not really, because "KVM" itself is inaccessible (well, unless someone is hand-
editing .configs or generating them by script, but that's their own fault).
E.g. upgrading to a new kernel will explicitly prompt the user to choose for both
KVM_S390_NATIVE and KVM_S390_ARM64 (or whatever they get called).
quoted
I am starting to think that having no separate config option for arm on
s390 might be the easisest way. Just KVM and guard both modules behind
it. It reduces the config space bloat and I do not see a reason why somoeone
should only compile one KVM module but not the other. kvm-arm64 won't
load if you do not have the hardware anyways.
Because there may be an unforseen need down the road?  Smushing things together
after the fact is generally easy, pulling things apart without breaking everything
is usually much, much harder.
quoted
But I am not opposed to the x86 approach. Just thinking loud.

Anyways, I am off for vacation expect a reduced reply frequency from my
side :)
Yet another option
I think there is value in keeping the config space simpte for users.
Why not simply keep CONFIG_KVM and it will disable, module build, compile-in
both variants.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help