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

[Sean Christopherson <seanjc@google.com>]

On Wed, Sep 02, 2026, Sean Christopherson wrote:
> 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@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.

Actually, I have a better idea.  I'll explain more in the subthread about tracepoints.