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

On Thu, Sep 3, 2026 at 5:54 PM Sean Christopherson [off-list ref] wrote:

On Thu, Sep 03, 2026, Paolo Bonzini wrote:

quoted

On 9/3/26 16:45, Sean Christopherson wrote:

quoted

quoted

quoted

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.

Ugh, defining CONFIG symbols in Makefiles sucks.

Sure, but IMO wrapping entire files in an #ifdef that comes from an arch header
sucks more.  And technically, these aren't CONFIG symbols.

True it wouldn't be -DCONFIG_ (fortunately). But even if technically
correct is the best kind of correct...

quoted

I don't want KVM to be the. one that does things differently *once more*.

Too late :-D

arch/arm64/kvm/hyp/nvhe/Makefile:ccflags-y := -D__KVM_NVHE_HYPERVISOR__ -D__DISABLE_EXPORTS -D__DISABLE_TRACE_MMIO__
arch/arm64/kvm/hyp/vhe/Makefile:ccflags-y := -D__KVM_VHE_HYPERVISOR__

Sure, VHE/nVHE is fair game because the nVHE case is in the same boat
as vDSO, arch/*/boot, and so on.

Looking at a grep for (cflags|CFLAGS).*\-D most are -DDEBUG,
-DDISABLE_BRANCH_PROFILING, -DDEFAULT_SYMBOL_NAMESPACE, etc. and in
most cases they seem like a bad idea. Don't do it for KVM please;
requiring -D for all architectures and for random pieces of config,
when you can put it in asm/kvm_host.h, is just as bad if not worse.

Paolo

And I think there's value in deliberately being different, because CONFIGs are
kernel-wide things, whereas the thingies in question are KVM-local macros.  I.e.
IMO, having the behavior stand out is a good thing.

quoted

I'd prefer to stub out the contents of the .c files instead.