Re: [PATCH v7 23/23] KVM: s390: arm64: Add KVM_S390_ARM64 Kconfig and Makefile

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Duplicate tracepoint registrations due to unmodified TRACE_SYSTEM in `virt/kvm/kvm_main.c`.
- [Low] The kvm-arm64 module will fail to build in modpost under all configurations (built-in or module) due to EXPORT_SYMBOL conflicts when compiling KVM core files twice.
--

commit faac05d8e4c537c5a5862961cb0c8e0746920675
Author: Steffen Eiden <seiden@linux.ibm.com>

KVM: s390: arm64: Add KVM_S390_ARM64 Kconfig and Makefile

This commit adds Kbuild and Makefile configurations to build a second KVM
module on s390 implementing the arm64-KVM API. To prevent symbol conflicts
with kvm-s390, internal symbols in kvm-arm64 are mangled if compiled as
built-in. It also overrides KBUILD_MODNAME to fix module parameter handling.

> diff --git a/arch/s390/kvm/arm64/Makefile b/arch/s390/kvm/arm64/Makefile
> new file mode 100644
> index 0000000000000..ae614a62f7b5f
> --- /dev/null
> +++ b/arch/s390/kvm/arm64/Makefile
[ ... ]
> +kvm-arm64-obj := \
> +	arm.o \
> +	guest.o \
> +	handle_exit.o \
> +	inject_fault.o \
> +	mmio.o \
> +	mmu.o \
> +	reset.o \
> +
> +kvm-arm64-obj += $(patsubst %.o,%-arm64.o,$(kvm-y))

[Severity: Medium]
Does compiling KVM core files a second time cause duplicate tracepoint
registrations?

When virt/kvm/kvm_main.c is compiled again for the kvm-arm64 module, it
instantiates the tracepoint metadata for CREATE_TRACE_POINTS. The linker
will aggregate the .ftrace_events and __tracepoints_ptrs sections, causing
the trace subsystem to attempt registering identical sets of tracepoints
under the same system and name. This will fail with -EEXIST at boot and
leave the tracepoints broken for the new module.

> +kvm-arm64-obj += $(patsubst %.o,%-arm64.o,$(gmap-y))
> +
> +targets += $(kvm-arm64-obj)
> +
> +$(obj)/%-arm64.o: $(src)/%.c FORCE
> +	@mkdir -p $(dir $@)
> +	$(call if_changed_rule,cc_o_c)
> +
> +ifeq ($(CONFIG_KVM_S390_ARM64),m)
> +
> +kvm-arm64-y = $(kvm-arm64-obj)

[Severity: Low]
Will this fail to build in modpost when compiled as a module?

When CONFIG_KVM_S390_ARM64=m, Kbuild processes the EXPORT_SYMBOL macros
natively without symbol mangling. Since kvm-arm64.ko and kvm.ko will both
natively export identical KVM core symbols (such as kvm_init), modpost will
fail with duplicate export errors.

> +
> +else ifeq ($(CONFIG_KVM_S390_ARM64),y)
[ ... ]
> +define rule_oc_o_o
> +	$(call cmd_and_savecmd,objcopy)
> +	$(call cmd,gen_objtooldep)
> +	$(call cmd,gen_symversions_o)
> +endef
> +
> +OBJCOPYFLAGS_kvm-namespaced.o := -O $(LD_BFD) --localize-symbols=$(obj)/kvm_symbol_list

[Severity: Low]
Will this localization step cause modpost to fail on built-in code?

When compiled with CONFIG_KVM_S390_ARM64=y, objcopy --localize-symbols
localizes all defined symbols. However, modpost strictly rejects exporting
local symbols via __ksymtab entries, which results in errors like
fatal: local symbol 'kvm_init' was exported.

> +$(obj)/kvm-namespaced.o: $(obj)/kvm-unnamespaced.o $(obj)/kvm_symbol_list FORCE
> +	$(call if_changed_rule,oc_o_o)
> +
> +kvm-arm64-y = kvm-namespaced.o
> +
> +targets += kvm-unnamespaced.o kvm_symbol_list kvm-namespaced.o
> +
> +endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831144802.834315-1-seiden@linux.ibm.com?part=23