[PATCH v7 03/23] KVM: Allow KVM implementations to switch off MMIO independent of Kconfig

[Sean Christopherson]

On Wed, Sep 02, 2026, Steffen Eiden wrote:
> On Wed, Sep 02, 2026 at 09:30:17AM +0100, Marc Zyngier wrote:
> > On Wed, 02 Sep 2026 01:38:53 +0100,
> > Sean Christopherson <seanjc at google.com> wrote:
> > > 
> > > On Mon, Aug 31, 2026, Steffen Eiden wrote:
> > > > Only defining KVM_MMIO is not flexible enough for multi-KVM systems
> > > > where one KVM implements MMIO but others do not. Solve this by
> > > > additionally testing for the non-existence of KVM_NO_MMIO before
> > > > including MMIO code to KVM.
> > > 
> > > Ewwwww.  IIUC, s390 ends up with two KVM modules, i.e. there really are two different
> > > KVMs being built.  Rather than have a KVM_MMIO and NO_KVM_MMIO, I vote very
> > > strongly to drop CONFIG_KVM_MMIO entirely and replace it with __KVM_HAVE_ARCH_MMIO,
> > > a la __KVM_HAVE_ARCH_VM_FREE and others.  Tracking two separate macros is going
> > > to be annoying to maintain, and will definitely be confusing for non-s390 people.
> > > 
> > > It'll mean linking in an emtpy coalesced_mmio.o on s390 when building without arm64
> > > support, but I'm guessing that won't be at all common for s390 builds.
> > > 
> > 
> > I ended-up doing something very similar locally, because I couldn't
> > really make head or tail of the logic while being in holiday mode
> > (which doesn't help). However, I kept the negative logic, so that we
> > don't need to add anything to any architecture but S390 (they are the
> > odd one out here).
> negative makes sense. 

Ya, an opt-out for s390 works for me.

> IIRC KVM/power does select KVM_MMIO most of the times but not always.
> I'll check that.

Huh, indeed.  KVM_BOOK3S_64_HV=y && KVM_BOOK3S_64_PR=n ends up with KVM_MMIO=n.
Though I'm not surprised given the multitude of variants PPC has.