From: sashiko-bot@kernel.org
To: "Steffen Eiden" <seiden@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
linux-s390@vger.kernel.org, kvmarm@lists.linux.dev,
"Marc Zyngier" <maz@kernel.org>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
kvm@vger.kernel.org, "Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v4 08/27] KVM: arm64: Prepare sharing arm64 code with s390
Date: Mon, 06 Jul 2026 09:21:46 +0000 [thread overview]
Message-ID: <20260706092146.A69BC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706085229.979525-9-seiden@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The patch misuses C preprocessor `#ifdef` directives to exclude tracepoints, resulting in catastrophic syntax errors because it leaves statements in the global scope.
- [Low] Critical ARM64 functions and definitions are wrapped in `#ifdef ARM64_S390_COMMON`, stripping them from standard ARM64 builds and causing undefined reference errors because their callers remain unconditionally compiled.
--
commit 651f0f9137d42f2814e4612c746de86e829e6666
Author: Steffen Eiden <seiden@linux.ibm.com>
KVM: arm64: Prepare sharing arm64 code with s390
This commit marks functions that s390 can use to implement arm on s390 as
shared functions, without introducing functional changes.
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 50adfff75be82..c992308b2dceb 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1580,6 +1580,7 @@ static unsigned long system_supported_vcpu_features(void)
> return features;
> }
>
> +#ifdef ARM64_S390_COMMON
> static int kvm_vcpu_init_check_features(struct kvm_vcpu *vcpu,
> const struct kvm_vcpu_init *init)
> {
[Severity: Low]
Will this cause undefined reference errors on standard ARM64 builds?
The caller of kvm_vcpu_init_check_features() remains unconditionally compiled,
so the symbol will be missing when ARM64_S390_COMMON is not defined.
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index b01d6622b8720..5a202cfd27bcb 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -543,6 +543,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> return -EINVAL;
> }
>
> +#ifdef ARM64_S390_COMMON
> static int copy_core_reg_indices(const struct kvm_vcpu *vcpu,
> u64 __user *uindices)
> {
[Severity: Low]
Does this missing symbol cause a link failure for kvm_arm_copy_reg_indices()?
The function is compiled out here, but the caller isn't.
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 54aedf93c78b6..d511af145ee6a 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -213,6 +213,7 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +#ifdef ARM64_S390_COMMON
> static int kvm_handle_unknown_ec(struct kvm_vcpu *vcpu)
> {
[Severity: Low]
Will this lead to an undefined reference?
kvm_handle_unknown_ec() is conditionally removed here, but it remains
referenced in the unconditionally compiled arm_exit_handlers array.
[ ... ]
> @@ -404,6 +407,7 @@ static exit_handle_fn arm_exit_handlers[] = {
> [ESR_ELx_EC_GCS] = kvm_handle_gcs,
> };
>
> +#ifdef ARM64_S390_COMMON
> static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
> {
[Severity: Low]
Is it intentional to compile out kvm_get_exit_handler() and
handle_trap_exceptions()?
The handle_exit() caller relies on them unconditionally, which may cause a
build failure.
> diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
> index e2285ed8c91de..876d56dd5b640 100644
> --- a/arch/arm64/kvm/mmio.c
> +++ b/arch/arm64/kvm/mmio.c
[ ... ]
> @@ -135,8 +136,11 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
> if (!kvm_vcpu_dabt_issf(vcpu))
> data = data & 0xffffffff;
>
> +#endif /* ARM64_S390_COMMON */
> trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
> &data);
> + //TODO tracing
> +#ifdef ARM64_S390_COMMON
> data = vcpu_data_host_to_guest(vcpu, data, len);
> vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
> }
[Severity: Low]
Does this inverted preprocessor logic break the build on standard ARM64?
Since kvm_handle_mmio_return() starts inside an ifdef ARM64_S390_COMMON block,
placing an endif here exposes the trace_kvm_mmio() call to the global scope
when the flag is not set, resulting in invalid C syntax.
[ ... ]
> @@ -171,8 +175,11 @@ int io_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa)
> * though, so directly deliver an exception to the guest.
> */
> if (!kvm_vcpu_dabt_isvalid(vcpu)) {
> +#endif /* ARM64_S390_COMMON */
> trace_kvm_mmio_nisv(*vcpu_pc(vcpu), esr,
> kvm_vcpu_get_hfar(vcpu), fault_ipa);
> + //TODO tracing
> +#ifdef ARM64_S390_COMMON
>
> if (vcpu_is_protected(vcpu))
> return kvm_inject_sea_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
[Severity: Low]
Similar to the issue above, does this leave trace_kvm_mmio_nisv() in the
global scope and cause syntax errors when ARM64_S390_COMMON is undefined?
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index b963fd975aaca..faab6f03f3655 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -34,6 +34,7 @@
> static u32 __ro_after_init kvm_ipa_limit;
> unsigned int __ro_after_init kvm_host_sve_max_vl;
>
> +#ifdef ARM64_S390_COMMON
> /*
> * ARMv8 Reset Values
> */
> @@ -46,6 +47,8 @@ unsigned int __ro_after_init kvm_host_sve_max_vl;
> #define VCPU_RESET_PSTATE_SVC (PSR_AA32_MODE_SVC | PSR_AA32_A_BIT | \
> PSR_AA32_I_BIT | PSR_AA32_F_BIT)
>
> +#endif /* ARM64_S390_COMMON */
[Severity: Low]
Could stripping out these reset value macros cause compilation to fail?
They appear to be used in unconditional kvm_reset_vcpu() initialization logic.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706085229.979525-1-seiden@linux.ibm.com?part=8
next prev parent reply other threads:[~2026-07-06 9:21 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 8:52 [PATCH v4 00/27] KVM: s390: Introduce arm64 KVM Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 01/27] VFIO: take reference to the KVM module Steffen Eiden
2026-07-06 9:12 ` sashiko-bot
2026-07-06 19:53 ` Jason Gunthorpe
2026-07-06 21:12 ` Sean Christopherson
2026-07-06 8:52 ` [PATCH v4 02/27] KVM, vfio: remove symbol_get(kvm_get_kvm_safe) from vfio Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 03/27] KVM, vfio: remove symbol_get(kvm_put_kvm) " Steffen Eiden
2026-07-06 9:25 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 04/27] KVM: Make device name configurable Steffen Eiden
2026-07-06 9:14 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 05/27] KVM: Remove KVM_MMIO as config option Steffen Eiden
2026-07-06 20:53 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 06/27] arm64: Use proper include variant Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 07/27] arm64: Prepare sharing arm64 headers with s390 Steffen Eiden
2026-07-06 21:22 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 08/27] KVM: arm64: Prepare sharing arm64 code " Steffen Eiden
2026-07-06 9:21 ` sashiko-bot [this message]
2026-07-06 21:28 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 09/27] KVM: arm64: Access elements of vcpu_gp_regs individually Steffen Eiden
2026-07-06 17:44 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 10/27] KVM: arm64: Refactor core-reset into a separate function Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 11/27] s390: Use arm64 headers Steffen Eiden
2026-07-06 9:31 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 12/27] KVM: s390: Use arm64 code Steffen Eiden
2026-07-06 9:26 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 13/27] KVM: s390: Prepare KVM/s390 for a second KVM module Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 14/27] KVM: s390: Move s390 kvm code into a subdirectory Steffen Eiden
2026-07-06 9:35 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 15/27] KVM: S390: Prepare gmap for a second KVM implementation Steffen Eiden
2026-07-06 9:36 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 16/27] KVM: s390: gmap: Refactor storage key and CMMA code into separate files Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 17/27] KVM: s390: Refactor prefix handling into a separate file Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 18/27] KVM: s390: Prepare kvm-s390 for a second kvm module Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 19/27] s390: Introduce Start Arm Execution instruction Steffen Eiden
2026-07-06 11:17 ` Janosch Frank
2026-07-06 11:30 ` Christian Borntraeger
2026-07-06 11:58 ` Steffen Eiden
2026-07-06 11:53 ` Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 20/27] KVM: s390: arm64: Introduce host definitions Steffen Eiden
2026-07-06 8:52 ` [PATCH v4 21/27] s390/hwcaps: Report SAE support as hwcap Steffen Eiden
2026-07-06 11:50 ` Janosch Frank
2026-07-06 8:52 ` [PATCH v4 22/27] KVM: s390: Add basic arm64 kvm module Steffen Eiden
2026-07-06 9:51 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 23/27] KVM: s390: arm64: Implement required functions Steffen Eiden
2026-07-06 9:55 ` sashiko-bot
2026-07-06 12:15 ` Janosch Frank
2026-07-06 20:35 ` Marc Zyngier
2026-07-06 8:52 ` [PATCH v4 24/27] KVM: s390: arm64: Implement vm/vcpu create destroy Steffen Eiden
2026-07-06 10:04 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 25/27] KVM: s390: arm64: Implement vCPU IOCTLs Steffen Eiden
2026-07-06 10:16 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 26/27] KVM: s390: arm64: Implement basic page fault handler Steffen Eiden
2026-07-06 10:03 ` sashiko-bot
2026-07-06 8:52 ` [PATCH v4 27/27] KVM: s390: arm64: Enable KVM_ARM64 config and Kbuild Steffen Eiden
2026-07-06 10:07 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260706092146.A69BC1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-s390@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seiden@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox