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

[Sean Christopherson]

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.

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.

> (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.