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

[Christian Borntraeger <borntraeger@linux.ibm.com>]

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.