[PATCH v7 03/23] KVM: Allow KVM implementations to switch off MMIO independent of Kconfig
Sean Christopherson
seanjc at google.com
Wed Sep 2 08:50:41 PDT 2026
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 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.
Actually, I have a better idea. I'll explain more in the subthread about tracepoints.
More information about the linux-arm-kernel
mailing list