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

From: Steffen Eiden

Date: Thu Sep 17 2026 - 07:51:28 EST


On Thu, Sep 17, 2026 at 01:07:47PM +0200, Christian Borntraeger wrote:
>
>
> Am 03.09.26 um 18:33 schrieb Sean Christopherson:
> > On Thu, Sep 03, 2026, Steffen Eiden wrote:
> > > On Thu, Sep 03, 2026 at 07:43:58AM -0700, Sean Christopherson wrote:
> > > > 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.
> >
> > > 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).
> >
> > > 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.
> >
> > > 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.

Good Idea. I'll merge the configs into one.