Re: [PATCH v3 27/27] KVM: s390: arm64: Enable KVM_ARM64 config and Kbuild

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The Makefile uses GNU Binutils incompatible flags `$(NM) -jU` and `$(OBJCOPY) -O default`, causing immediate build failures.
- [High] Compiling both `kvm-s390` and `kvm-arm64` causes fatal linker multiple-definition errors when built-in, or duplicate-export failures when loaded as modules.
--

commit 8f8fd4d3ea8855f34fafa2691472eea31e58dd4d
Author: Steffen Eiden <seiden@linux.ibm.com>
Subject: KVM: s390: arm64: Enable KVM_ARM64 config and Kbuild

This commit adds the Kbuild/Makefile configurations to build a second
KVM module on s390 that implements the arm64-KVM API. It mangles internal
symbols in kvm-arm64 when compiled as built-in to prevent symbol conflicts
with kvm-s390.

> diff --git a/arch/s390/kvm/arm64/Makefile b/arch/s390/kvm/arm64/Makefile
> new file mode 100644
> index 0000000000000..d0aac34b8d2ff
> --- /dev/null
> +++ b/arch/s390/kvm/arm64/Makefile

[ ... ]

> +ifeq ($(CONFIG_KVM_ARM64),m)
> +
> +kvm-arm64-y = $(kvm-arm64-obj)
> +
> +else ifeq ($(CONFIG_KVM_ARM64),y)

[Severity: High]
Does this bypass namespacing entirely when built as a module?

If localization is skipped, it seems both kvm-s390.ko and kvm-arm64.ko
will attempt to export identical KVM core symbols (such as kvm_init).
Will the kernel module loader refuse to load the second module due to
duplicate exports?

[ ... ]

> +quiet_cmd_nm_filter = NMFLTR  $@
> +	cmd_nm_filter = \
> +$(NM) -jU $< | awk '							\

[Severity: High]
Can these nm flags cause build failures on standard GCC/binutils s390x setups?

The -j (just symbol names) and -U flags appear to be LLVM extensions that
are not supported by standard GNU nm, which might result in an invalid option
error during standard kernel builds.

> +{	if (match($$0, /^__export_symbol_(.*)$$/, exp_sym)) {		\
> +		exp_syms[exp_sym[1]] = 1;				\
> +	} else {							\

[Severity: High]
By filtering out exported symbols from the localization list here, do the
exported functions remain globally visible?

If both KVM implementations are compiled into vmlinux, this looks like it
will cause fatal multiple definition linker errors since they both compile
their own copy of KVM core files.

[ ... ]

> +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 default --localize-symbols=$(obj)/kvm_symbol_list

[Severity: High]
Is "-O default" supported by standard GNU objcopy?

Standard GNU objcopy does not recognize "default" as a valid BFD output
target (such as elf64-s390) and fails with an "invalid bfd target" error.
Could the -O flag be omitted entirely to retain the input format?

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

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