Re: [PATCH v7 02/23] KVM: Make device name configurable

[Sean Christopherson <seanjc@google.com>]

On Thu, Sep 03, 2026, Sean Christopherson wrote:
> On Thu, Sep 03, 2026, Sean Christopherson wrote:
> > On Thu, Sep 03, 2026, Steffen Eiden wrote:
> > > On Wed, Sep 02, 2026 at 09:14:21AM -0700, Sean Christopherson wrote:
> > > > And taking things a few steps further, we can solve the MMIO issue in a more
> > > > elegant way, and eliminate the runtime string building in this patch (after looking
> > > > more closely, that code needs to be jettisoned no matter what, there's simply no
> > > > reason to specify the names at runtime since they're separate compilation units).
> > > > 
> > > > Rather than splatter #defines throughout header files, deal with the bulk of the
> > > > pain in Makefile.kvm.  By feeding conditionals into Makefile.kvm, the s390+arm64
> > > > build can easily omit coalesced_mmio.o and async_pf.o, define __KVM_HAVE_ARCH_MMIO
> > > > programatically without having to change other architectures, and solve the naming
> > > > stuff.
> > > 
> > > Yes, this is a great idea. Thank you. I second you, this looks more clean
> > > and stable than the stuff we came up with :) 
> > 
> > Looking more at arch/s390/kvm/Kconfig and virt/kvm/Kconfig, we might need/want to
> > to build out infrastructure to handle this sort of thing in a more generic fashion?
> > 
> > Which probably isn't that much infrastructure?  It's more just changing how arch
> > code communicates with common KVM?  I.e. instead of providing boolean configs in
> > virt/kvm/Kconfig, formalize communicating HAVE-type macros through the Makefile.
> > That might even be a net positive in the long run, as it will make it easier to
> > provide defaults for the common cases.
> > 
> > I say that because unless there's magic I'm unaware of these Kconfigs also needs
> > to be configured per-KVM, not per-kernel:
> > 
> >   - KVM_MMU_LOCKLESS_AGING, otherwise aging on arm64 will unintentionally be done
> >     outside of mmu_lock.
> > 
> >   - KVM_GENERIC_PRE_FAULT_MEMORY, so that arm64 doesn't need to provide a stub
> >     for something it doesn't support
> > 
> >   - HAVE_KVM_MSI, because presumably it's needed for arm64 support.
> > 
> >   - HAVE_KVM_READONLY_MEM, same story as HAVE_KVM_MSI.
> 
> And in the opposite direction, HAVE_KVM_VCPU_RUN_PID_CHANGE also falls into this
> category.  That one is probably better handled as a #define in header files?

Continuing the conversation with myself, add in HAVE_KVM_NO_POLL and
HAVE_KVM_INVALID_WAKEUPS (which reminds me, valid_wakeup should really be moved
into s390's kvm_vcpu_arch).

> > Which isn't _that_ many knobs, but add in KVM_MMIO, KVM_ASYNC_PF, and
> > KVM_ASYNC_PF_SYNC, and it's enough that I think we should think about the big
> > picture and not play whack-a-mole.
> > 
> > Actually, thinking about this more, what I've proposed here, plus the pattern of
> > #define-ing macros in arch-specific kvm_host.h files, should suffice.  For things
> > like __KVM_HAVE_ARCH_VM_FREE, it absolutely makes sense to #define the macro in
> > kvm_host.h since it's very directly tied to an arch callback.  Whereas with KVM_MIO
> > and KVM_ASYNC_PF, because they enable compilation of C files, it makes sense to
> > define them in Makefiles.
> > 
> > So I think the "gap" is purely that the four knobs listed above need handling
> > (and arguably KVM_MMU_LOCKLESS_AGING is ok as-proposed).  But I do think we should
> > try our best to be more thoughtful than we usually are when deciding how to enable
> > common code, because obviously s390+arm64 is adding wrinkles no one has had to deal
> > with before.
> >