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

[Steffen Eiden <seiden@linux.ibm.com>]

On Thu, Sep 03, 2026 at 07:43:58AM -0700, Sean Christopherson wrote:
> On Thu, Sep 03, 2026, Steffen Eiden wrote:
> > On Wed, Sep 02, 2026 at 09:20:23AM -0700, Sean Christopherson wrote:
> > > On Mon, Aug 31, 2026, Steffen Eiden wrote:
> > > > diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig
> > > > index 8d3ee17a1bcb..9c69ea16031e 100644
> > > > --- a/arch/s390/kvm/Kconfig
> > > > +++ b/arch/s390/kvm/Kconfig
> > > > @@ -53,4 +53,33 @@ config KVM_S390_UCONTROL
> > > >  
> > > >  	  If unsure, say N.
> > > >  
> > > > +config KVM_S390_ARM64
> > > > +	def_tristate y
> > > > +	prompt "KVM support for hardware accelerated arm64 guests"
> > > > +	depends on HAS_IOMEM
> > > > +	depends on KVM
> > > 
> > > Is this actually necessary?  I.e. does kvm.ko need to be *loaded* in order for
> > > kvm-arm64.ko to be loaded?
> > > 
> > > If kvm-arm64.ko does indeed have a hard dependency on kvm.ko, then I think it
> > > makes sense to not have redundant "select" statements below.  As an outsider,
> > > it's super confusing because the KVM_S390_ARM64 are incomplete, e.g. are lacking
> > > things like VIRT_XFER_TO_GUEST_WORK (at least, I assume those are lacking), and
> > > makes it hard to see what is actually unique to kvm-arm64.ko.
> > > 
> > > If kvm-arm64.ko doesn't have a dependency on kvm.ko, e.g. to initialize hardware
> > > or something, then this "depends on" should go away.
> > 
> > 
> > It is a bit more complicated unfortunately. KVM_S390_ARM64 depends on
> > KVM as there is code around in the kernel & drivers (arch and common)
> > which depends on CONFIG_KVM we need as well. I did not want to leak arch
> > local configs to common code if I can avoid that.
> > I could change it to select KVM ? Do you have another idea on how to
> > solve this issue?
> 
> I would do something similar to what KVM x86 does.
> 
> > The two modules are completely independent at compile and runtime. So
> > kvm does not have to be loaded for kvm-arm64 to work.
> > 
> > VIRT_XFER_TO_GUEST_WORK is only lacking for now. I will add it later.
> > Currently the kvm-arm64 module is incomplete anyways but I did not want
> > to send a 60+patches series and rather stage the introduction over
> > multiple series.
> > 
> > I will remove the duplicated config selections. Thanks for pointing it
> > out. In previous series I had an explicit KVM_S390 config. Both KVM_S390
> > and KVM_ARM64 selected KVM. But this created too much churn around the
> > whole tech-stack 
> 
> LOL, what exactly are you expecting to happen?  You're trying to squeeze support
> in for a completely different architecture, of course there's going to be churn.
> 
> This absolutely needs to be as precisely and correct as possible, otherwise it'll
> be painfully difficult to maintain,  And to some extent, just for others to review.
> E.g. as is, it's at all not clear to me which of the IS_ENABLED(CONFIG_KVM) checks
> in arch/s390 apply to both flavors of virtualization, versus which are specific to
> "native" s390 virtualization.
> 
> I realize this is outside of my immediate scope, but getting this "right" isn't
> just an s390 thing, because these details bleed into common KVM, and even affect
> other architectures, e.g. when trying to make "treewide" KVM changes.

I want to find the 'right' way as well - any ideas are welcome.

> 
> 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 :))
Suddenly the KVM config changed its behaviour (effectively becoming a noop)

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.

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 :) 

	Steffen
> 
> > (default config change, s390 is the odd one out for the KVM config meaning, ...).
> 
> Nah, x86 is the odd one, where CONFIG_KVM=m doesn't even guarantee kvm.ko gets
> built :-)
> 
> E.g. something like this, which probably doesn't compile and isn't the desired
> end state, as several of the Kconfig selections need to be reworked into #defines
> provided by header files, but AFAICT it does what I want/intend.
> 
> config KVM
> 	def_tristate m if (KVM_S390_NATIVE = m || KVM_S390_ARM64 = m)
> 	select HAVE_KVM_CPU_RELAX_INTERCEPT
> 	select KVM_COMMON
> 	select HAVE_KVM_IRQCHIP
> 	select HAVE_KVM_IRQ_ROUTING
> 	select KVM_VFIO
> 	select VIRT_XFER_TO_GUEST_WORK
> 
> config KVM_S390_NATIVE
> 	def_tristate y
> 	prompt "Kernel-based Virtual Machine (KVM) support"
> 	select KVM if (y && KVM_S390_ARM64 != m)
> 	select KVM_ASYNC_PF
> 	select KVM_ASYNC_PF_SYNC
> 	select HAVE_KVM_NO_POLL
> 	select KVM_MMU_LOCKLESS_AGING
> 	select KVM_GENERIC_PRE_FAULT_MEMORY
> 	select HAVE_KVM_INVALID_WAKEUPS
> 	help
> 	  Support hosting paravirtualized guest machines using the SIE
> 	  virtualization capability on the mainframe. This should work
> 	  on any 64bit machine.
> 
> 	  This module provides access to the hardware capabilities through
> 	  a character device node named /dev/kvm.
> 
> 	  To compile this as a module, choose M here: the module
> 	  will be called kvm.
> 
> 	  If unsure, say N.
> 
> config KVM_S390_UCONTROL
> 	bool "Userspace controlled virtual machines"
> 	depends on KVM
> 	help
> 	  Allow CAP_SYS_ADMIN users to create KVM virtual machines that are
> 	  controlled by userspace.
> 
> 	  If unsure, say N.
> 
> config KVM_S390_ARM64
> 	def_tristate y
> 	prompt "KVM support for hardware accelerated arm64 guests"
> 	depends on HAS_IOMEM
> 	select KVM if (y && KVM_S390_NATIVE != m)
> 	select GUEST_PERF_EVENTS if PERF_EVENTS
> 	select HAVE_KVM_VCPU_RUN_PID_CHANGE
> 	select HAVE_KVM_IRQ_BYPASS
> 	select KVM_MMIO
> 	select SCHED_INFO
> 	select XARRAY_MULTI
> 	help
> 	  Enable support for hosting virtualized, hardware-accelerated arm64
> 	  virtual machines on s390 systems using the Start ARM Execution (SAE)
> 	  instruction. This requires hardware models that support the Arm
> 	  execution facility (AEF).
> 
> 	  The module provides a character device named /dev/kvm-arm64 to expose
> 	  the hardware capabilities.
> 
> 	  To compile this driver as a module, choose M here. The module will
> 	  be called kvm-arm64.
> 
> 	  If unsure, say N.